On Sun, Jun 09, 2019 at 10:11:32PM -0400, Paul Smith wrote: > 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.
No, it's definitely not the case. Probably it gets less frequently reported as disks get cheaper, and multi-user systems less used for development than in the olden days. Building big projects on an NFS, be it a "classcal" NFS or a supposedly high-performant solution from a commercial vendor (IBM makes something like this), as people tend to do nowadays on HPC systems, is still problematic. In particular large projects using autotools are affected, for they have particular ways of doing things that were appropriate 20-30 years ago, but not nowadays. A typical error message from configure would say: checking whether build environment is sane... configure: error: newly created file is older than distributed files! Check your system clock We recommend doing builds on a local disk instead, but it's not always feasible for one or another reason. HTH Dima > > 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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make