On 10/22/10 Oct 22 -7:11 AM, Nikodemus Siivola wrote:
On 22 October 2010 05:19, Faré fahree@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