Re: Idea: Automatically correct timestamps

[dmitrii . pasechnik]

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-make