On 4/18/10 Apr 18 -10:18 AM, Juan Jose Garcia-Ripoll wrote: > On Sun, Apr 18, 2010 at 4:56 PM, Robert Goldman <[email protected] > <mailto:[email protected]>> wrote: > > So: what is the intended effect of :ASDF-DEPENDENCIES and > :ASDF-OPTIONAL-DEPENDENCIES? At what point in the processing of the > DEFSYSTEM are they processed? How do they interact with the processing > of other DEFSYSTEM initargs? The answers to these questions should not > be left to reading the code. > > > This depends on the level of implementation we achieve. > > Ideally the situation could be such that the loading of dependencies > could be delayed until the system is actually used. In other words, load > the system definition using the base class, record components, > dependencies, etc, Only when the system is actually loaded, compute the > dependencies which are present and can be used and change the class > using the extensions which are really available.
I was thinking one might do a two-phase process in which the :asdf-dependencies (and proposed :asdf-optional-dependencies) would be loaded first. Then the remaining defsystem initargs would be processed. Any reason not to do that? > > In practice it might not be that simple. There are situations right now > in which it might have been useful to load the dependency _before_ even > reading the system definition. Yes, I think that is probably the simplest solution. These situations require further fixes: > > - Right now people are using symbols in other packages. This seems quite undesirable. You can't even /read/ such symbols reliably. Currently this works because the forms that load the asdf dependencies are lexically before the DEFSYSTEM form. But putting the asdf-dependencies there would make this impossible. We would need to find a solution much less cumbersome than the current (funcall (intern <function name> <extension package>) ...) or similar constructs which I find myself typing more often than I'd like in PERFORM methods... _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
