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. -- Regards, zacque
