[asdf-devel] Optional dependencies

[Tobias C Rittweiler]

In article 
<AANLkTi=LvcyS_BnUYgNafFoTSbsOv857hzpjQhomAP6h at mail.gmail.com>,
 Juan Jose Garcia-Ripoll 
 <juanjose.garciaripoll at googlemail.com> wrote:

> On Fri, Aug 20, 2010 at 1:07 PM, Tobias C Rittweiler 
> <tcr at 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