[asdf-devel] [cclan-list] How to depend on a system optionally?
james.anderson at setf.de
Mon Jul 20 23:35:50 UTC 2009
On 2009-07-21, at 01:18 , Robert Goldman wrote:
> james anderson wrote:
>> On 2009-07-21, at 00:35 , Robert Goldman wrote:
>>> What would it mean, for
>>> example, to be :contingent-on or :weakly-depend on a :file?
>> if the file is present, then the contingent component is included in
>> the system and dependent on that file.
>> no different than a simple dependency. the only difference are in the
>> effective behaviour of operate.
>> in my case it makes it possible to do things like include a ffi
>> interface iff dependent on runtime conditionalization and include a
>> particular aspect of the higher level interface iff the particular
>> ffi interface is there.
> I don't believe that is correct.
in that weakly-depends-on does not do this, or this is not a
"correct" thing to do?
i do not use weakly-depends-on. i implemented :contingent-on.
> If you look at the source,
> weakly-depends-on is not handled as a first class citizen, the way
> :depends-on is. :depends-on is squirreled away in a slot, and then
> manipulated at the time we carry out an ASDF operation. The WEAKLY
> of :weakly-depends-on, on the other hand (1) only works when the
> dependency is on a system, not a feature or a file and (2) is resolved
> when the defsystem is "parsed". I.e., there's no way you can load a
> system that has weakly-depends on, THEN define another system on which
> it weakly depends, and have the first system do anything reasonable.
> The :weakly-depends-on is gone by the time the second system is
> introduced to your lisp image.
weakly depends on may well not be well implemented. i do not use it.
>>> Unfortunately, :weakly-depend-on can be parsed off an arbitrary
>>> component, not just a system. Oh. Looking at the source, I see
>>> weakly-depends on only works on a system name. This means that
>>> (defsystem foobar
>>> :weakly-depends-on ((feature "foo"))
>>> is not permitted, which seems wrong. That is, it seems wrong until
>>> realize that the feature would be interpreted at the time the
>>> form is READ, not at the time you try to operate on the system.
>>> The more I think about this, the more queasy it makes me feel...
>> it's an argument to re-implement it correctly - that is with a
>> uniform semantics
> Yes, I agree. This should be redone properly.
> In the meantime, I am inclined to think I should rewrite my
> weakly-depends-on documentation to explain the irregularities that are
> hidden there.
More information about the asdf-devel