[cmake-developers] Filesystem timestamp checks

[Ruslan Baratov]

On 19-Oct-15 19:30, Brad King wrote:
> On 10/15/2015 03:58 PM, Ruslan Baratov wrote:
>> 3. Apply changes to CMakeLists.txt "immediately", CMakeLists.txt modification time 105
>> 4. Run rebuild: `cmake --build _builds`. Since CMakeLists.txt (105) is not "newer"
>> then Makefile (105) there will be no regenerate command run and Makefile remains the same
>>
>> Error can be easily reproduced on Apple HFS file system with unit = 1s (I hit this problem doing changes even manually) but in general that's the "feature" of native make tool + file system date resolution. Here is the similar test for Linux with ext4:
>> Test: https://github.com/forexample/date-resolution-test
>> Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483
> This is a fundamental limitation of buildsystems that use file timestamps.
> Your example shows that even plain "make" has this problem.  One simply
> must use a workflow that does not involve changing files "immediately".
> It's not that bad.  When manually entering commands it is very hard to
> type that fast.  When scripting commmands the script can delay where
> needed.
I've already heard all this arguments and can only reply mine again :)
* I've hit this while doing manual changes for Xcode project on Apple's 
HFS with 1s resolution
* I don't want to patch every script. To be precise I prefer to "Fix 
something in one place so it works 100% and forget about it" then "Every 
time I start creating script I should remember that..."

>> There are a lot of scenarios where such problems can occurs, e.g. installing files (reproducible on OSX and Linux):
>> * https://cmake.org/pipermail/cmake-developers/2015-October/026692.html
> This is a separate issue because it is about CMake truncating timestamps
> rather than the filesystem doing it.
Well yes, I was not very accurate with this statement, but in general 
it's very similar (if CMake truncation precision == file system date 
resolution then we have same situation) and "sleeping-guard" will fix it 
too.

As I've mentioned I have a wrapper already so I've applied the "sleep" 
functionality there. It fix all issues of 1-3 test case, so this is 
closed for me now.

Thanks, Ruslo