good afternoon;
reading traverse is not my idea of a good time, but when i persevere, i do not arrive at the same conclusion. in addition, when i specialize a method for operation-done-p for compile-op and module to iterate over the constituents and collect the results, the matlispbug system behaves as my reading of traverse would imply: it compiles the f77/ffi code once only.
the first time through it compiles everything. the second time through it first asks each constituent individually, in turn, if it is done (this is the traverse recursion in its module- ops clause) and then asks each one again as a consequence of asking the module (this is the operation-done-p for the module itself in the when clause). if the results are consistently "done", the dependents do not recompile.
?
nb. if the method is specialized on (operation component), things do not turn out well, but that looks like it may be unrelated to the general issue and instead an interaction with the particular way the system's specialized components implements compilation.
On 2010-04-11, at 15:48 , Robert P. Goldman wrote:
Unfortunately, I don't believe this is possible. This is YA problem arising from the fact that asdf has no object that stands for the module with it's components. Operation-done-p on a module doesn't mean the op is done on this module & components, only on the suffix of the module after it's components.
E.g., if you have a module m & component c, for op o, you will see first (perform o c) Then (perform o m) In the plan, so operation-done-p does not prevent doing o on c, only on the m object itself.
Traverse does a postorder traversal on the system tree.
I could not figure out how to fix this while maintaining any semblance of backward compatibility.
On Apr 11, 2010, at 8:09, james anderson james.anderson@setf.de wrote:
good afternoon;
if one invoked load-system with the factors traced which contribute to done-ness, it reads as if operation-done-p needs to be specialized for modules to delegate to the constituents. of the asdf/test/*module*.asd examples, there is one which has a similar structure. it is not obvious clear why the matlisp .asd behaves differently.
On 2010-04-11, at 13:28 , Mario S. Mommer wrote:
Hello,
Faré fahree@gmail.com writes:
Ahem. I admit this is a part of ASDF I am not familiar with.
What does traverse return? Can you trace every exported defgeneric in ASDF and attach to a launchpad bug traces of what happens in either ASDF 1 or ASDF 2?
I can try. For now I made a much smaller .asd, whith a defsystem that looks like this:
(defsystem :matlispbug :components ((:unix-dso "alien code" :pathname "" :dso-name "libmatlisp" :components ((:alien-module "CPOLY" :pathname "lib-src/cpoly/" :components ((:fortran-source-file "cpoly"))))) (:file "packages") (:module "foreign-interface" :pathname "src/" :depends-on ("packages" "alien code") :components ((:file "f77-mangling") (:file "ffi-sbcl")))))
and that shows the behavior of interest. That is, with the new asdf, the module "foreign-interface" gets compiled every time I load the system, whereas under the old asdf that does not happen. From staring at the source of the .asd, I haven't been able to see what is wrong.
I have uploaded a tarball with an abridged (to reduce size) version of matlisp to common-lisp.net, in case anyone wants to try:
http://common-lisp.net/~mmommer/matlispasdfissue.tar.gz
The shortened .asd is called matlispbug.asd.
To readers in the future: I will remove the file as soon as this issue is resolved, and then this link will be broken.
Regards, and thanks,
Mario.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel