In article <AANLkTi=LvcyS_BnUYgNafFoTSbsOv857hzpjQhomAP6h@mail.gmail.com>, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com> wrote:
On Fri, Aug 20, 2010 at 1:07 PM, Tobias C Rittweiler <tcr@freebits.de>wrote:
The parts you left out did not talk about reader conditionalization in ASD(F) files. So I'm confused by what you mean exactly.
Sorry, I understood the reader macros were intended to appear in the ASDF itself. I obviously misread your email, but I needed a third reading to grasp it all -- please tell me whether the following description is right :-)
Goal: Library B has some facilities that make sense when library A is present. The goal is to make these facilities compiled and loaded whenever possible.
Solutions offered:
1) Let the library B :weakly-depends-on A and use the fact that library A introduces a new feature. The code in library B is then populated with #+/#- depending on that feature.
2) One of the components in the system definition includes all the code that depends on A and is loaded only when that :feature is active
3) One of the components in the system definition isolates all dependency on A and this component :weakly-depends-on
4) Make two separate system definitions, one with and one without code for A
Yes that seems to be it. Thanks for the summary. However, I don't understand how #2 is supposed to achieve the goal. In #2, the A-dependent code is loaded if :A is in *FEATURES*, right? But that only works if A happened to be loaded before. So there must be some kind of :WEAKLY-DEPENDS-ON be involved, too, in which case #2 becomes mostly a variation of #1.
I believe 1 and 2 have problems because as you say the feature might be present in the core. #3 is better because the code that depends on A is only loaded when ASDF knows that A is present and loadable -- no dependency on non-standard features. Method #3, if working (which Fare seems not to be sure about) is also the substitute for reader macros in ASDF files.
I agree #3 sounds like a step forward. At least in the ASDF currently shipped with SBCL, there's a bug in the code that handles weakly-depends-on. See patch attached. Despite the patch I couldn't really test the issue, and got annoyed by ASDF recompiling SBCL contribs on :FORCE T which will result in failure. Reminded me that I'm supposed to do something else. -T. Index: contrib/asdf/asdf.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/contrib/asdf/asdf.lisp,v retrieving revision 1.32 diff -u -r1.32 asdf.lisp --- contrib/asdf/asdf.lisp 26 Jun 2010 05:03:58 -0000 1.32 +++ contrib/asdf/asdf.lisp 21 Aug 2010 08:05:43 -0000 @@ -2221,7 +2221,7 @@ (or (find-component parent name) (make-instance (class-for-type parent type))))) (when weakly-depends-on - (appendf depends-on (remove-if (complement #'find-system) weakly-depends-on))) + (appendf depends-on (remove-if (complement #'(lambda (s) (find-system s nil))) weakly-depends-on))) (when *serial-depends-on* (push *serial-depends-on* depends-on)) (apply #'reinitialize-instance ret