bug-make
[Top][All Lists]
Advanced

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

Idea: Automatically correct timestamps


From: David A. Wheeler
Subject: Idea: Automatically correct timestamps
Date: Sun, 09 Jun 2019 18:24:31 -0400 (EDT)

I'd like to propose that "make" automatically correct timestamps by default.
Details below.

Problem:
Distributed systems are cheap now, enabling "make" to gets lots done
in a short amount of wall clock.
Unfortunately, it's impossible to keep clocks exactly aligned in a distributed 
system.
Network Time Protocol does great things, and it can keep clocks "close"
in normal cases, but it kinna change the laws of physics.
For example, if b depends on c, and b is created after c, it's possible
for the timestamp of b to be *before* the timestamp of c.

This is problem because make depends on the timestamp values,
especially on later runs.  The result is that make can do
the "wrong thing" because it gives itself bad data.

People have asked for a database that uses hashes like md5, but if
this is the problem they're trying to fix, there's a *much* simpler solution:
make can simply ensure that the "database" it uses (the file metadata of 
timestamps)
stays accurate.

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).
The timestamp should be changed by no more than MAKETIMEADJUSTMAX seconds,
default 60, to prevent horribly-bad timestamps causing cascading nonsense.
Setting MAKETIMEADJUSTMAX=0 would disable this behavior
If MAKEMUSTTIMEADJUST is not empty (true), then if adjusting time fails
(either because it'd be adjusted too far or the time adjustment fails)
then executing the rule fails. MAKEMUSTTIMEADJUST is not the default,
so that Makefiles that do weird quirky things continue with their weird quirky 
behavior.
These are variables, so you could define (for example) target-specific values.

This is totally POSIX-compliant, because POSIX presumes that a timestamp of
an event will be later than any prior events. This functionality
ensures that the POSIX assumption holds true in many more cases.

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.
In particular, this would work well with my separate .MUSTCREATE proposal.
The proposal here ensures that timestamps work better when you create files,
and .MUSTCREATE ensures that the files get created.
The result is that instead of using a shared database, make continues
to use the filesystem as its database... but now make ensures that
the database has reasonable values.

Here's some proposed pseudo-code that would be run when a processing
a rule completes:

if {MAKETIMEADJUST>0) {
  prereq_time = max(time of all non-.PHONY prerequisites that caused rule to 
run)
  for each non-.PHONY target of the rule that just finished running {
    target_time = time(target)
    if target_time <= prereq_time {
      // target_time is before at least one of its prerequisites, try to 
correct.
      if (prereq_time - target_time) <= MAKETIMEADJUST {
        set target_time to be prereq_time
        if setting fails AND MAKEMUSTTIMEADJUST is true {
          fail "target {target} has a time before its prerequisite {list} but 
its time cannot be adjusted"
        }
      } else {
        if MAKEMUSTTIMEADJUST is true {
          fail "target {target} has a time before its prerequisite {list} more 
than {MAKETIMEADJUST} seconds"
        }
      }
    }
  }
}

--- David A. Wheeler



reply via email to

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