[mcclim-devel] another CLC fix: clim-listener

[rpgoldman at real-time.com]

>>>>> "CF" == Clemens Fruhwirth <clemens at endorphin.org> writes:

    CF> Another CLC fix: *load-truename* is assumed to point to the
    CF> source directory that also contains the icons/ directory. In
    CF> CLC, this isn't the case as all fasl are loaded from
    CF> /var/cache/common-lisp-controller/.

    CF> I changed Apps/Listener/package.lisp to also probe in
    CF> #.*compile-file-truename*, that most likely point to a
    CF> #directory
    CF> containing the icons too.

    CF> The problem is that I used cl-fad for directory probing. I
    CF> personally don't mind to have mcclim use cl-fad, as I have it
    CF> installed anyway and it's pretty lightweight, but on the other
    CF> hand that might not be true for the mcclim project as a whole,
    CF> especially as it needs only a single function.

This suggests a knot of other issues:

1.  Having external dependencies is somewhat undesirable in general,
    but mostly because we don't have clean ways of managing coherent
    states across multiple systems.  E.g., what happens if cl-fad or
    the spatial-trees systems gets out of synch with McCLIM?

    As I understand ASDF, you can specify that you need >= a
    particular dependency system, but you can't specify = or <=.

    Probably with a little care this can be overcome.

    More difficult (but possibly conjectural) what happens if
    *another* system you want loads cl-fad or spatial-trees and the
    version that other system needs is not congruent with McCLIM's
    requirements?  I know I always get a little nervous when
    asdf-install loads its private copy of cl-ppcre...

    Would it be possible to make an internal version of these systems?
    E.g., would it be possible to load them into alternative packages,
    so that they can coexist with a different version?  E.g., stuff
    them into clim.cl-fad?  That might be the CL equivalent of
    statically linking against libraries...

2.  CL-FAD seems desirable more generally as a component of McCLIM,
    because McCLIM needs file-managing gadgets, and these probably
    need more capable ways of getting at the file system than CL
    provides in its stock form.