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

[james anderson]

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.

> 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

>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> simple dependency intends this behaviour:
>> 	component status	effect
>> expression	component a	component/feature b
>> a (:depends-on (:b))	present	present	(operate b), (operate a)
>> a (:depends-on (:b))	present	absent	error
>> a (:depends-on (:b))	absent	present	error
>> a (:depends-on (:b))	absent	absent	error
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> given the code in parse-component-form, :weakly-depends-on would  
>> appear
>> to effect this behaviour:
>> 	component status	effect
>> expression	component a	component/feature b
>> a (:weakly-depends-on (:b))	present	present	(operate b), (operate a)
>> a (:weakly-depends-on (:b))	present	absent	(operate a)
>> a (:weakly-depends-on (:b))	absent	present	error
>> a (:weakly-depends-on (:b))	absent	absent	error
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> there are cases, where it is useful to cause a third behaviour:
>> 	component status	effect
>> expression	component a	component/feature b
>> a (:contingent-on (:b))	present	present	(operate b), (operate a)
>> a (:contingent-on (:b))	present	absent
>> a (:contingent-on (:b))	absent	present	error
>> a (:contingent-on (:b))	absent	absent	error
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> perhaps there are others. this one is useful when building a system
>> where the components are contingent on the runtime and/or o/s.
>>
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> asdf-devel mailing list
>> asdf-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>