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 <rpgold...@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@common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel > _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
