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@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