On Sun, 2019-06-09 at 18:24 -0400, David A. Wheeler wrote: > Proposed solution: > By default, make should check the timestamp of the non-.PHONY target(s) > produced after > executing a rule, and ensure that their timestamps are at least equal to the > timestamps to the files that caused execution of the rule in the first place > (if the target is created at all).
I don't think this can work, as-is. It's a common paradigm in make (including POSIX make) where there is a rule that could cause a very expensive operation to be started, to instead make a cheap test and if it determines the expensive operation is not needed it will not update the target at all. You will have to continue to run that cheap test every time, until you finally allow the target to be rebuilt, but it can still save a lot of work. Even automake uses a "move_if_changed" type of thing, to avoid re- running configure when it's not necessary. This problem could be addressed by adding a clause that if the timestamp of the target was not modified at all, it should be left alone. It's hard to come up with a justifiable purpose for a target's mod time to be changed, but to something less than one of its prerequisites. Although doubtless someone has done it, on purpose, somewhere for some reason. > In many cases I suspect this would eliminate calls for using md5 > hashes and special state; I suspect many of those requests are really > trying to deal with problems of clock slew that this proposal > resolves. Hm. Maybe people have just given up reporting this problem but honestly I can't remember the last time I had anyone ask questions here or on StackOverflow that are related to clock skew. I sort of thought it was a solved problem. Most of the requests I see these days that would require a "last state database" wouldn't be helped by md5 checks: mainly they're asking for things like rebuilding targets automatically when compiler options have changed etc. Things like that can be done today with a lot of fancy trickery but people would rather it "just worked". _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make