asdf doesn't recompile when .asd file has changed

[Faré]

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)

[Faré (fahree)]

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.

[Faré (fahree)]

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.

[Robert P. Goldman (rpgoldman)]

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...

[Faré (fahree)]

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!

[Faré (fahree)]

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.

[Faré (fahree)]

Fix released in 2.27