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