Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


On Tue, Feb 24, 2015 at 12:34 PM, Norbert Thiebaud <nthiebaud@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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.