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@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.
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. What would it mean, for example, to be :contingent-on or :weakly-depend on a :file? 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...
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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel