[asdf-devel] ASDF traverse changed behavior?

james anderson james.anderson at setf.de
Thu Mar 18 13:55:09 UTC 2010


good afternoon;

On 2010-03-18, at 00:03 , Juan Jose Garcia-Ripoll wrote:

> On Wed, Mar 17, 2010 at 11:54 PM, Juan Jose Garcia-Ripoll  
> <juanjose.garciaripoll at googlemail.com> wrote:
> Oh, there is nothing with TRAVERSE's output _right now_.
>
> Let me clarify this again:
>
> - The fact that TRAVERSE now adds the same operation for all  
> components was new. That was my source of confusion. Before this  
> did not happen with LIB-OP and the like. Maybe a straightforrwad  
> solution is just writing
>
>    (defun perform ((o bundle-op) (c component)) nil)
>
> so that all components which are not modules get a default PERFORM  
> that does nothing. Is this safe?
>
> - The order and format of TRAVERSE's output is important. Details  
> like ensuring that the list includes the operated systems and that  
> a system's components appear before the system that owns them, is  
> also important, for this allows us to use TRAVERSE for identifying  
> what files make up a module, using a variant of
>
>    (let ((*forcing* t)) (traverse (make-instance 'load-op) some- 
> system))
>
> which lists all components and all systems that should be loaded,  
> sorted in some appropriate order. We rely critically on this,  
> because otherwise I do not know a way to traverse a set of systems  
> "portably" without redoing all of ASDF's logic.

if asdf were to adopt an 11.1.2.1.2-rule, asdf-ecl.lisp would require  
a change.

it would not be supported for an extension to extend 'asdf:load-op  
such that load-op itself specialized an operation-done-p :around  
method which forced complete traversal results. it would be be  
necessary to specialize the load-op class as, for example, collect- 
op, and specialize operation-done-p on that class. in which case its  
own primary method could always return nil and an :around method  
would not be necessary.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100318/80c3eba3/attachment.html>


More information about the asdf-devel mailing list