On 2009-07-21, at 00:58 , Robert Goldman wrote: > Gary King wrote: >> I share Robert's queasiness and also think that we want ASDF to >> support >> these sorts of dependencies (simple, weak, contingent, etc... (?)). >> >> I'm going to update the manual with James's table (thanks James!) >> in the >> hopes of giving us a place to hang our collective hats. >> >> > > [...] > > Follow-on suggestion: we need to think about what happens when a > component has all possible combinations of :depends-on, > :weakly-depends-on, and :contingent-on. Does something that would not > be loaded because of :contingent-on avoid a crash that would come > from a > violated :depends-on?
hmmm... depends on what you mean by a "crash". it probably does not make sense to define a relation like (:file "a" (:contingent-on :osx)) (:file "b" (:depends-on "a")) as that reads as if that "a" will always be present, which is likely to cause confusion if the statements are not _real_ close neighbors in the system description. what does make sense is (:module "x" (:components ((:module :ffi (:components ((:file "a-ffi" (:contingent-on "osx" :ccl)) (:file "a-inter" (:contingent-on "a- ffi")) (:file "b-ffi" (:contingent-on "linux" :sbcl)) (:file "b-inter" (:contingent-on "b- ffi"))))) (:file "x-ops" (:depends-on :ffi))) > > Extra bonus follow-on: are these expected to be meaningful when the > depended-on item is a system (clearly yes), a feature (seems > handy), an > arbitrary component (what would this mean?)? i have used contingent dependencies for all of them. eg. if a graphics system is to be built somewhere where clx makes sense, then there is a system dependency between the graphics package and clx. in addition, there is a file-level dependency between the clx-based implementation of rendering operators and clx's presence. one _can_ express everything in terms of #+, but not as clearly. _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel