In article <aanlkti=lvcys_bnuygnaffotsbsov857hzpjqhoma...@mail.gmail.com>, Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> wrote:
> On Fri, Aug 20, 2010 at 1:07 PM, Tobias C Rittweiler > <t...@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 _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel