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. > 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. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
