(0000876)
Bill Hoffman (manager)
2004-04-15 11:40

This is the result of bad input to cmake, I am not sure what the fix is as there is not solution proposed here, I am moving the priority to low.

(0000877)
Bill Hoffman (manager)
2004-04-15 11:46

keep a list of all files written, and if one of those shows up in the list of depends, then print a warning and suggest configure file be used which does a copy on different.

(0000905)
System Admin (reporter)
2004-04-18 14:42

Fixed...

(0011613)
Brad King (manager)
2008-04-30 11:49

Since all the dependers are written during the Generate step they must be newer than all dependees that were written before or during the Configure step. Therefore this should not be a real problem.

However, the CMakeLists.txt file code

  SET(FOO ${CMAKE_CURRENT_BINARY_DIR}/foo.cmake)
  FILE(WRITE ${FOO} "MESSAGE(STATUS \"foo\")")
  CONFIGURE_FILE(${FOO} ${CMAKE_CURRENT_BINARY_DIR}/bar.cmake)

reproduces the problem with CMake 1.8 on the HP. The reason is that the file system has only 1 second resolution and the HP "make" tool considers a depender->dependee pair to be out of date if both files have the same time! If a configure/generate step occurs in less than 1 second then the depender and dependee get the same time and the make tool re-runs CMake every time.

(0011614)
Brad King (manager)
2008-04-30 11:57

The fix Andy did first appeared in CMake 2.0, but the above code still produces the problem because the check was only done if there was at least one target!

In CMake 2.2 and CMake 2.4 the check is still there (and only done if there is a target), but the problem does not occur because we no longer use the make tool to decide whether to re-run CMake. The check is done by the cmake_check_build_system step which actually requires the timestamps of the files to be different, so the 1 second resolution problem does not occur.

In CMake 2.6.0 rc9 the check has been fixed to complain even in directories with no targest (see issue 0006923).

(0011615)
Brad King (manager)
2008-04-30 13:17

After further investigation I've discovered that in CMake 2.0 and below there were actually two separate make rules affected by the "CMAKE_MAKEFILE_SOURCES":

default_target: /home/kitware/TBug6923/b/cmake.check_cache
        $(MAKE) $(MAKESILENT) cmake.depends
        .... rest of build

cmake.check_cache: $(CMAKE_MAKEFILE_SOURCES)
        @echo "Building CMakeCache.txt because ..."
        $(CMAKE_COMMAND) -H$(CMAKE_SOURCE_DIR) -B$(CMAKE_BINARY_DIR)

cmake.depends: $(CMAKE_MAKEFILE_SOURCES)
        @echo "Building dependencies. cmake.depends..."
        $(CMAKE_COMMAND) -S$(CMAKE_CURRENT_SOURCE) -O$(CMAKE_CURRENT_BINARY) -H$(CMAKE_SOURCE_DIR) -B$(CMAKE_BINARY_DIR)

It was the 'local generate' in cmake.depends that caused the file(WRITE) command to make the file newer than the files generated by the global generate. This does not happen with GNU make because the 'cmake.depends' file is included to the make tool drives it first.

(0011616)
Brad King (manager)
2008-04-30 13:40

This bug no longer exists even without the check because the local generate step causing the problem was removed in CMake 2.2 and above.

Issue History
Date Modified	Username	Field	Change
2008-04-30 11:49	Brad King	Assigned To	System Admin => Brad King
2008-04-30 11:49	Brad King	Status	closed => feedback
2008-04-30 11:49	Brad King	Resolution	fixed => reopened
2008-04-30 11:49	Brad King	Note Added: 0011613
2008-04-30 11:57	Brad King	Note Added: 0011614
2008-04-30 13:17	Brad King	Note Added: 0011615
2008-04-30 13:40	Brad King	Status	feedback => closed
2008-04-30 13:40	Brad King	Note Added: 0011616
2008-04-30 13:40	Brad King	Resolution	reopened => fixed
2008-04-30 13:40	Brad King	Relationship added	related to 0006923

Notes
(0000876) Bill Hoffman (manager) 2004-04-15 11:40	This is the result of bad input to cmake, I am not sure what the fix is as there is not solution proposed here, I am moving the priority to low.

(0000877) Bill Hoffman (manager) 2004-04-15 11:46	keep a list of all files written, and if one of those shows up in the list of depends, then print a warning and suggest configure file be used which does a copy on different.

(0000905) System Admin (reporter) 2004-04-18 14:42	Fixed...

(0011613) Brad King (manager) 2008-04-30 11:49	Since all the dependers are written during the Generate step they must be newer than all dependees that were written before or during the Configure step. Therefore this should not be a real problem. However, the CMakeLists.txt file code SET(FOO ${CMAKE_CURRENT_BINARY_DIR}/foo.cmake) FILE(WRITE ${FOO} "MESSAGE(STATUS \"foo\")") CONFIGURE_FILE(${FOO} ${CMAKE_CURRENT_BINARY_DIR}/bar.cmake) reproduces the problem with CMake 1.8 on the HP. The reason is that the file system has only 1 second resolution and the HP "make" tool considers a depender->dependee pair to be out of date if both files have the same time! If a configure/generate step occurs in less than 1 second then the depender and dependee get the same time and the make tool re-runs CMake every time.

(0011614) Brad King (manager) 2008-04-30 11:57	The fix Andy did first appeared in CMake 2.0, but the above code still produces the problem because the check was only done if there was at least one target! In CMake 2.2 and CMake 2.4 the check is still there (and only done if there is a target), but the problem does not occur because we no longer use the make tool to decide whether to re-run CMake. The check is done by the cmake_check_build_system step which actually requires the timestamps of the files to be different, so the 1 second resolution problem does not occur. In CMake 2.6.0 rc9 the check has been fixed to complain even in directories with no targest (see issue 0006923).

(0011615) Brad King (manager) 2008-04-30 13:17	After further investigation I've discovered that in CMake 2.0 and below there were actually two separate make rules affected by the "CMAKE_MAKEFILE_SOURCES": default_target: /home/kitware/TBug6923/b/cmake.check_cache $(MAKE) $(MAKESILENT) cmake.depends .... rest of build cmake.check_cache: $(CMAKE_MAKEFILE_SOURCES) @echo "Building CMakeCache.txt because ..." $(CMAKE_COMMAND) -H$(CMAKE_SOURCE_DIR) -B$(CMAKE_BINARY_DIR) cmake.depends: $(CMAKE_MAKEFILE_SOURCES) @echo "Building dependencies. cmake.depends..." $(CMAKE_COMMAND) -S$(CMAKE_CURRENT_SOURCE) -O$(CMAKE_CURRENT_BINARY) -H$(CMAKE_SOURCE_DIR) -B$(CMAKE_BINARY_DIR) It was the 'local generate' in cmake.depends that caused the file(WRITE) command to make the file newer than the files generated by the global generate. This does not happen with GNU make because the 'cmake.depends' file is included to the make tool drives it first.

(0011616) Brad King (manager) 2008-04-30 13:40	This bug no longer exists even without the check because the local generate step causing the problem was removed in CMake 2.2 and above.