[asdf-devel] [cclan-list] How to depend on a system optionally?
rpgoldman at sift.info
Mon Jul 20 23:18:42 UTC 2009
james anderson wrote:
> On 2009-07-21, at 00:35 , Robert Goldman wrote:
>> james anderson wrote:
>>> On 2009-07-20, at 21:10 , Robert Goldman wrote:
>>>> james anderson wrote:
>>>>> On 2009-05-18, at 14:55 , Nikodemus Siivola wrote:
>>>>>> 2009/5/18 Robert Goldman <rpgoldman at sift.info>:
>>>>>>> Tobias C. Rittweiler wrote:
>>>>>>>> I've read several times that it's a head ache to configure
>>>>>>>> dependencies with ASDF.
>>>>>>>> How true is that? Could we perhaps provide another clause
>>>>>>>> :OPTIONALLY-DEPEND-ON in DEFSYSTEM which would load a system
>>>>>>>> only if
>>>>>> Doesn't :WEAKLY-DEPENDS-ON do what you want?
>>>>> there is at least one more kind of dependency between two
>>>> Did this discussion ever go anywhere?
>>>> James, would it be possible for you to resend this email with the
>>>> given as a text attachment, rather than as inline text? I don't
>>>> about the rest of the list, but my client (Thunderbird) turned your
>>>> tables into complete and utter gibberish.
>>> [i suspect it was because i neglected to disable line-wrapping
>>> before i
>>> sent the message.]
>>> to summarize:
>>> in addition to simple and weak dependency, there is at least one more
>>> kind of dependency between two components: "contingency".
>>> in order to manage a system for multiple runtimes, each of which
>>> entails it's own foreign libraries, i have found it useful to add a
>>> constraint called "contingent-on". this may-or-may-not be what you
>>> intend with "optionally-depend-on". i have found it useful to express
>>> the constraints:
>>> "if a feature|system 'X' is present, then system|component 'Y' is
>>> required, and depends on 'X'. if 'X' is not present, do nothing."
>>> i attach an html file which describes, as a table, the relation
>>> system model state and operations.
>> I suppose you could kludge this into place, in much the way
>> weakly-depends-on was kludged. Just check the dependency eagerly (at
>> read time), and if the contingency isn't satisfied, prune the
> i wrote it into the walker. if the contingency is not satisfied, then
> the component does not exist
>> Note that I have an icky feeling about both of these extensions to
>> At the system level, they behave reasonably, but at the module or
>> level, I think they have weird semantics.
> my recollection is that is has the same semantics at all levels. at
> least, i don't recall treating any case differently. if you are
> skeptical, i could pull the instances out of the system files.
>> 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. 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 part
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.
>> Unfortunately, :weakly-depend-on can be parsed off an arbitrary
>> component, not just a system. Oh. Looking at the source, I see that
>> 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
More information about the asdf-devel