[asdf-devel] [cclan-list] How to depend on a system optionally?

[Robert Goldman]

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  
>>>>>>>> optional
>>>>>>>> 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
>>>>>>>> available?
>>>>>> Doesn't :WEAKLY-DEPENDS-ON do what you want?
>>>>> there is at least one more kind of dependency between two  
>>>>> components:
>>>>> "contingency".
>>>> ...
>>>>
>>>> Did this discussion ever go anywhere?
>>>>
>>>> James, would it be possible for you to resend this email with the  
>>>> tables
>>>> given as a text attachment, rather than as inline text?  I don't  
>>>> know
>>>> 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  
>>> between
>>> 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  
>> component.
> 
> 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  
>> ASDF.
>>  At the system level, they behave reasonably, but at the module or  
>> file
>> 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  
>> you
>> realize that the feature would be interpreted at the time the  
>> defsystem
>> 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.


Best,
r