[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idea: Automatically correct timestamps

From: Paul Smith
Subject: Re: Idea: Automatically correct timestamps
Date: Sun, 09 Jun 2019 22:11:32 -0400
User-agent: Evolution 3.32.1-2

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

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

Although doubtless someone has done it, on purpose, somewhere for some

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]