[asdf-devel] Feature-conditional components

Robert Goldman rpgoldman at sift.info
Fri Oct 22 13:23:28 UTC 2010


On 10/22/10 Oct 22 -7:11 AM, Nikodemus Siivola wrote:
> On 22 October 2010 05:19, Faré <fahree at gmail.com> wrote:
> 
>> 2- the feature feature was never working before I fixed and cerror'ed
>> it, and only does conditional *dependency* on another component, that
>> has to independently exist or conditionally exist, for which we have
>> no non-ugly mechanism.
> 
>> 3- the :if-component-dep-fails mechanism may or may not be working
>> well enough to do that right now, but man it's ugly, non-intuitive,
>> non-documented, and gross even if it were documented.
> 
> Note: I have two different use cases.
> 
> One is a DEFSYSTEM -level :DEPENDS-on ((FEATURE :SBCL :SB-THREAD)) or
> similar to indicate what *FEATURES* the system assumes, so that tools
> like Quicklisp could use this information to good effect.
> 
> It should be checked during attempts to OPERATE LOAD-OP on system,
> with an error if the feature is not present, and it should be
> available through system introspection.

Question:

in the above, are you assuming implicit conjunction, so that this is
intended to be synonymous with

:depends-on ((FEATURE :SBCL) (FEATURE :SB-THREAD))

?

Do we need to support /disjunction/ as well?  E.g.,

:depends-on ((OR (FEATURE :SBCL :SB-THREAD)
                 (FEATURE :ALLEGRO :SOME-ALLEGRO-THREADING-THING)))

or even implication?  Let's assume, for example, that allegro has
threading always, but SBCL not so:

:depends-on ((IMPLIES (FEATURE :SBCL) (FEATURE :SB-THREAD)))

Will this cause problems for the defsystem parser?  Features are symbols
and must be parsed as such, rather than down-cased strings like
component names.  It won't be rocket science to get that right, but we
should keep it in mind.

Another question:  should we push this into an ASDF 2.1?  That way
people can do something like

(defsystem ....
   :depends-on  (#+ASDF2.1 (feature :sbcl :sb-thread)
                 ...other dependencies...)

since this is really a pretty substantial change to the API, and
programmers need to be able to detect whether the ASDF is able to handle it.

or possibly add

:asdf-feature-dependencies

to *features* when loading an ASDF that can handle these.

I hope this doesn't seem like fussiness, but I'd rather get this
functionality right than have to do it over, possibly messing with
people who've started using it.

And maybe this design discussion should be put in a launchpad bug at
some point (perhaps digested by someone) so that there's something
spec-like to code to.

Best,
r




More information about the asdf-devel mailing list