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