asdf doesn't recompile when .asd file has changed

Bug #627173 reported by Faré
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ASDF
Fix Released
Low
Faré

Bug Description

When you modify the .asd file of a system, this doesn't cause the recompilation of files. It possibly should. That would be the conservative thing to do. On the other hand, say, make targets do NOT depend on the Makefile itself - probably because when
compiling C projects, there is precious little C dependency information in the Makefile itself, and there of plenty of reasons to modify the Makefile without affecting C compiler output (moreover, make allows you to depend on the makefile if you insist, and doesn't have a mechanism to undeclare dependencies that it could use if it were there by default). It might make sense to do the conservative thing in ASDF.

The bug has always existed, and was known for a long time, but Peter Siebel sent me a message with an example tarball and a README that makes it easy to manually reproduce the bug.

(Note that xcvb has plans to do these things right, by saving the per-file dependency information)

Revision history for this message
Faré (fahree) wrote :

Message from gigamonkey:

See the README in the attached .tgz file for the details. I tested
this on SBCL 1.0.41 with whatever version of ASDF it has.

Revision history for this message
Faré (fahree) wrote :

Note that this bug will probably NOT be fixed in ASDF 2.1. At least, not by me.

It should be possible to check the .asd file timestamp in operation-done-p (cached per operation for performance reason?), as identified using component-system. That would be adding more gunk to the code, though.

A complete, clean, solution would involve refactoring of the operation-done-p protocol. But for big hacks, I'd rather hack on XCVB than ASDF. Labelling it an ASDF 3 issue.

Changed in asdf:
importance: Undecided → Low
milestone: none → version3
status: New → Confirmed
Revision history for this message
Robert P. Goldman (rpgoldman) wrote : Re: [Bug 627173] Re: asdf doesn't recompile when .asd file has changed

On 8/30/10 Aug 30 -8:29 PM, Faré wrote:
> Note that this bug will probably NOT be fixed in ASDF 2.1. At least, not
> by me.
>
> It should be possible to check the .asd file timestamp in operation-
> done-p (cached per operation for performance reason?), as identified
> using component-system. That would be adding more gunk to the code,
> though.
>
> A complete, clean, solution would involve refactoring of the operation-
> done-p protocol. But for big hacks, I'd rather hack on XCVB than ASDF.
> Labelling it an ASDF 3 issue.

I think that's right. The problem is that systems don't really
participate in the OPERATION-DONE-P protocol --- there's a
special-purpose way of deciding whether modules (and systems are
modules) are forced.

I believe that this is one of a number of tasks that would be simplified
or solved if this aspect of the protocol were redesigned.

That sounds like an ASDF 3 task to me...

Revision history for this message
Faré (fahree) wrote :

I believe this has actually been fixed, albeit unwittingly, by the system resetting work I did back before 2.019 (2.018.16 and 2.018.19 back in November 2011): re-defining the system resets most of its slots (all except for those in proto-system), which resets the component-operation-times slots and causes all sub-components to be compiled again next time.

Marking as fixed!

Changed in asdf:
assignee: nobody → Faré (fahree)
milestone: version3 → version2.1
status: Confirmed → Fix Released
Revision history for this message
Faré (fahree) wrote :

Actually, this is only fully fixed as of 2.26.21, whereby systems will now be recompiled if the .fasl's are older than the .asd.

Changed in asdf:
status: Fix Released → Fix Committed
Revision history for this message
Faré (fahree) wrote :

Fix released in 2.27

Changed in asdf:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.