On 4/18/10 Apr 18 -9:50 AM, Robert Goldman wrote:
On 4/17/10 Apr 17 -4:08 PM, Juan Jose Garcia-Ripoll wrote:
It is a two-lines change that allows a defsystem form depend on a package that provides additional functionality, such as new system classes, new system options, new methods, etc.
:ASDF-DEPENDENCIES ({system-name}*)
Suggest you also add :optional-dependencies
This would be for things like test libraries. ASDF would make a best effort attempt to load these systems, but should be entitled to assume that they are optional and that it should be able to process the defsystem correctly without them, if losing some functions.
E.g., we have an asdf extension for our test library, ASDF-NST. It would be nice if we could list that as an optional-dependency. Our systems load correctly if you /don't/ have NST, but would behave better in the presence of ASDF-NST.
About 30 seconds additional thought suggests that optional-dependencies is, well, suboptimal! Suggest that this should be something more like :optional-asdf-dependencies Another point: I'd like to suggest that a prerequisate for introducing this new initarg should be a specification of its behavior in something other than CL code: in somewhat formal natural language that can be adapted for the manual. One of the things ASDF /desperately/ needs is a specification of its protocols. This is not a problem created by the addition of such new features, but it is /exacerbated/ by adding new features. So: what is the intended effect of :ASDF-DEPENDENCIES and :ASDF-OPTIONAL-DEPENDENCIES? At what point in the processing of the DEFSYSTEM are they processed? How do they interact with the processing of other DEFSYSTEM initargs? The answers to these questions should not be left to reading the code. Best, R