"CF" == Clemens Fruhwirth clemens@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.