Make.exe for Cygwin

[Ashod Nakashian]

On Tue, Feb 24, 2015 at 12:34 PM, Norbert Thiebaud <nthiebaud at gmail.com> wrote:
> The high resolution file time stamps of many modern file systems
> lessen the chance of make incorrectly concluding that a file is up to
> date. Unfortunately, some hosts do not provide a way to set a high
> resolution file time stamp, so commands like ‘cp -p’ that explicitly
> set a file’s time stamp must discard its sub-second part. If a file is
> created by such a command, you should list it as a prerequisite of
> .LOW_RESOLUTION_TIME so that make does not mistakenly conclude that
> the file is out of date. For example:
>

It seems that this is very much accurate for Linux, but not Windows[*].

The issue I uncovered has to do with fact that without
FILE_TIMESTAMP_HI_RES stat gives 1s precision. So there is simply no
way to apply the .LOW_RESOLUTION_TIME logic above. NTFS has sub-second
precision time stamps, but unless make is able to read them, they are
as good as useless.

My patch is to delay updating files for which mtime == now only #if
!FILE_TIMESTAMP_HI_RES, because failing to do that will result in the
subsequent stat call to return mtime == mtime_before_update, which
will mean update simply failed. This wrong conclusion results in
failing the build. Of course make will also be wrong about files that
are out dated within a second (source is newer than target by a
fraction of the same second). I haven't tried to fix this, but the fix
would be to implement/use a high-res stat function. Alternatively,
make should always assume files with same mtime as their source are
out of date, just to be safe (I don't know if that's the case or not).

Notice that the update failure issue is only apparent when the target
is updated twice within a second, so it's not a very common scenario.
But we know it affects LO at least when generating VS IDE files (it's
easily reproducible as the vs2013-ide-integration target fails
randomly).

Even if .LOW_RESOLUTION_TIME helps in this case (which I don't think
it can,) it would be needed for _all_ targets, as the low resolution
time stamp is not due to some command such as 'cp -p' rather it's due
to make unable to get the full precision of files' mtime.


[*] Visual Studio doesn't implement stat with >1 second precision and
the GNU binary we officially use doesn't either (confirmed by the fact
that it suffers the same issue). I don't know how it's built, but if
msys has a high-res stat implementation then we need to at least build
make with FILE_TIMESTAMP_HI_RES.