[asdf-devel] :in-order-to

[james anderson]

On 2010-04-16, at 10:33 , Juan Jose Garcia-Ripoll wrote:

> On Fri, Apr 16, 2010 at 12:01 AM, james anderson  
> <james.anderson at setf.de> wrote:
> you will need to elaborate on why this matters. the primary  
> dependencies are all in a list which is bound to the in-order-to slot.
> the :in-order-to initarg is just circumstantially involved in this.  
> most of the initialization value is collected from the other  
> dependency initargs.
>
> Yes, but everything is transformed into an in-order to internally  
> when parsing the system definition. The result is a duplicated list  
> of dependencies :in-order-to load-op and :in-order-to compile-op.

the presence of a single list is independent of the particular  
annotations.
yes, it was a bad idea to hardwire the implication between load and  
compile operations.

>
> The additional problem is that right now we have a dichotomy  
> between load and load-src-op and apart from the cases in which :in- 
> order-to is used for testing, the other cases just write  
> dependencies for one of the operations and not for the other.
>
> The third problem is that the in-order to mechanism does not  
> provide any kind of inheritance and if I tried to write a fix for  
> load-src-op that creates the hierarchy
>
> operation
> +- compile-op
> +- load-op
>     +- compile-and-load-op
>     +- load-source-op
>
> this does not work.
>
> your remarks suggest that you fail to appreciate how broken i  
> believe traverse to be.[1]
>
> Your remarks fail to appreciate how good and useful I believe a  
> properly written traverse could be.

if you write that, i infer, you did not look at the reference.[1] i  
call it again to you attention, for your reference. you may disagree,  
that it embodies the best approach. you man conclude that it is also  
an inadequate implementation. but, you should at least engage the  
argument which that re-implementation represents rather than suggest  
that there is none.[2] it was a couple of months ago, but i believe  
it demonstrates an alternative asdf model and an alternative traverse  
implementation which address all of the items in your list. both  
better suited to the current and future development environments than  
the current one. among other things, it demonstrates that the two  
phase process which is central to traverse - plan collection followed  
by plan execution, is not necessary, and is not necessarily the  
correct process for a contemporary build system.

---

[1] : http://github.com/lisp/de.setf.asdf.x
[2] : http://github.com/lisp/de.setf.asdf.x/blob/master/README.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100416/9aa6218d/attachment.html>