You are not logged in

While the hosts should all use NTP to stay in sync, my experience has been that make is far too sensitive for NTP in practice. We sometimes get messages to the effect of "make: Warning: File `bar' has modification time 0.0035 s in the future" and discussions to this effect has been had before through the years but never been addressed.

While I really don't know if NTP is expected to reach this level of synchronicity between hosts, this small drift seems to be a level I can live with.

The one possibility to take care of this is .LOW_TIME_RESOLUTION, but the main problem is that it would require me to change makefiles to use it. Most of the time I really don't have that ooportunity. Actually, even if I did, this mechanism seems flawed, as this aspect of a target isn't checked in the section of remake.c where clock skew is warned for - so even if this target is set, I still get clock skew messages.

I explored various ways to address this - e.g. forcing the .LOW_TIME_RESOLUTION for all targets (but this didn't fly very well because of the above), making the FILE_TIMESTAMP_HI_RES define become a runtime rather than a compile time thing (but this proved far too complex with lots of opportunities of creating subtle regressions).

In the end I settled for a short, sweet and very simple way: add a flag to let the user indicate that clock skew warnings should be shut up, either altogether (plain use of --ignore-clock-skew), or, more reasonable, by indicating a level of clock skew that is acceptable (e.g. --ignore-clock-skew=100 would allow timestamps up to 100 millisecs in the future to be ignored). Without using the flag, everything is as before so it's fully back compatible.