Hi phoebe,

[[PGP Signed Part:Undecided]] I'll still get the warnings (even with one new warning: "No dependency propagating scheme specified..."):

Perhaps it was imprecise of me to say that defining a method on COMPONENT-DEPENDS-ON will prevent the deprecation warning. Causing the default method to be invoked on an OPERATION that is not a direction-OPERATION is deprecated; defining a more specific method which does CALL-NEXT-METHOD still invokes the deprecated behavior.

What I meant was subclassing ASDF:OPERATION only

You can subclass OPERATION without a direction-OPERATION, but you have to completely override COMPONENT-DEPENDS-ON with your own behavior, never invoking the built-in method. I strongly recommend against doing this.

So, all operations are by default downward and sideway unless they are subclass of (OR DOWNWARD-OPERATION UPWARD-OPERATION SIDEWAY-OPERATION SELFWARD-OPERATION NON-PROPAGATING-OPERATION)

Er... I'm not comfortable with saying that. In ASDF 2, all operations behaved in a way that is now called being downward and sideway. ASDF 3 treats operations which don't specify their dependency relationship in a way compatible with ASDF 2 to give maintainers a chance to update old extensions. The beautiful dream is that, one day, the compatibility behavior will be replaced with a hard error. Please do not treat the compatibility behavior as a part of ASDF 3's interface.

From our exchange, I think its safe to summarise into this table:

"Table of ASDF operation classes to subclass and the corresponding methods to define on your custom class."

| | OPERATION | <direction>-OPERATION | *-op | |----------------------+------------+--------------------------+------| | perform | X | X | X | | component-depends-on | X (note 1) | | | | input-files | X | (Depending on your need) | | | output-files | X | (Depending on your need) | |

Note 1: You have to completely override COMPONENT-DEPENDS-ON for your custom class without invoking (CALL-NEXT-METHOD).

As a new ASDF extension writer, I think having a table like this helps a lot to easily getting started.

Is it a linear chain or a "network chain" of operations?

The latter. When you define a subclass of SELFWARD-OPERATION, you specify what other operation(s) it is selfward to by overriding the :INITFORM of the slot SELFWARD-OPERATION. The value you provide may be either a single operation designator, or a list of operation designators. For example, (LOAD-OP COMPONENT) depends on both (COMPILE-OP COMPONENT) and (PREPARE-OP COMPONENT), so its SELFWARD-OPERATION slot is defined:

(selfward-operation :initform '(prepare-op compile-op) :allocation :class)

can be done in parallel,

But how can I express the operation dependencies such that ASDF knows PRINT-OP depends on ECHO-OP?

(defclass print-op (asdf:selfward-operation) ((asdf:selfward-operation :initform 'echo-op :allocation :class)))

Thanks! I have tried it out and it works. Still need some time to understand its behaviour though.

ASDF as it exists now is not capable of running anything in parallel. Faré has an experimental project to do this, called POIU, but I can't speak for its status. Until very recently, SBCL was incapable of compiling files in parallel, and still today, lots of code does not-thread-safe stuff at load-time, so I'm not convinced it's practically possible to make ASDF parallel via shared-memory threaded concurrency. I believe POIU compiles each component in a separate process, then loads them sequentially.

I see, that's good to know. At least it's an implementation limitation and not a design limitation I guess.