[asdf-devel] new asdf does not like matlisp.asd

Robert P. Goldman rpgoldman at sift.info
Sun Apr 11 13:48:50 UTC 2010


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 at 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 at 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 at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>
>
> _______________________________________________
> asdf-devel mailing list
> asdf-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel




More information about the asdf-devel mailing list