MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015256CMakeCMakepublic2014-11-18 18:142016-06-10 14:31
ReporterStephen Kelly 
Assigned ToBen Boeckel 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0015256: Ninja handling of CMake depends and output files is not correct
DescriptionGiven this test code:

 cmake_minimum_required(VERSION 2.8)
 project(cmaketest)

 configure_file(
   "${CMAKE_CURRENT_SOURCE_DIR}/input_file.txt"
   "${CMAKE_CURRENT_BINARY_DIR}/confi_file.txt"
 )

If cmake is run, then input_file.txt is touched, then ninja is run, then ninja correctly re-runs cmake, but also reports that no work need be done:

 $ ninja
 [1/1] Re-running CMake...
 -- Configuring done
 -- Generating done
 -- Build files have been written to: /home/stephen/dev/src/playground/cmake/build
 ninja: no work to do.

If confi_file.txt is then deleted, and ninja is run, ninja does not re-run cmake to re-create the output file.

The same 'no work to do' message can be seen by creating a try_compile:

 try_compile(RES
   "${CMAKE_CURRENT_BINARY_DIR}/testbin"
   "${CMAKE_CURRENT_SOURCE_DIR}/tc_input.cpp"
 )
 message("RES: ${RES}")

Run cmake, and change the tc_input.cpp.

 this->Makefile->AddCMakeDependFile(this->Input.c_str());

and

 this->Makefile->AddCMakeOutputFile(outputFileName.c_str());

are called at the appropriate places, but the appropriate Ninja content is apparently not created.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0014963closed Brad King Add explicit specification of custom command side effect outputs 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-11-18 18:14Stephen KellyNew Issue
2014-11-19 10:23Brad KingRelationship addedrelated to 0014963
2014-11-19 10:25Brad KingNote Added: 0037233
2014-11-19 10:25Brad KingTarget Version => CMake 3.2
2014-11-19 10:25Brad KingDescription Updatedbug_revision_view_page.php?rev_id=1624#r1624
2014-12-01 14:34Brad KingNote Added: 0037340
2014-12-01 14:37Brad KingNote Added: 0037341
2015-01-20 14:57Ben BoeckelNote Added: 0037758
2015-01-20 15:29Ben BoeckelNote Added: 0037759
2015-01-21 13:20Ben BoeckelNote Added: 0037762
2015-01-21 13:20Ben BoeckelAssigned To => Ben Boeckel
2015-01-21 13:20Ben BoeckelStatusnew => feedback
2015-01-23 09:35Brad KingNote Added: 0037787
2015-01-26 16:36Ben BoeckelNote Added: 0037823
2015-01-26 16:43Ben BoeckelNote Added: 0037824
2015-02-04 15:35Brad KingNote Added: 0037915
2015-02-04 15:35Brad KingStatusfeedback => acknowledged
2015-02-04 15:35Brad KingTarget VersionCMake 3.2 =>
2016-06-10 14:29Kitware RobotNote Added: 0042671
2016-06-10 14:29Kitware RobotStatusacknowledged => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0037233)
Brad King   
2014-11-19 10:25   
I haven't looked at this in detail but I suspect that new byproducts API added for 0014963 may be of use here. The generated files should be listed as byproducts of the cmake-rerun rule. IIRC the Makefile generator does this with its CMAKE_MAKEFILE_PRODUCTS variable in CMakeFiles/Makefile.cmake.
(0037340)
Brad King   
2014-12-01 14:34   
The changes linked in 0014963:0037230 that add the custom command byproduct APIs are now in 'master'.
(0037341)
Brad King   
2014-12-01 14:37   
The RERUN_CMAKE rules.ninja entry may simply need a 'restat = 1'.
(0037758)
Ben Boeckel   
2015-01-20 14:57   
"restat = 1" doesn't solve this problem.
(0037759)
Ben Boeckel   
2015-01-20 15:29   
Filling in outputs of RERUN_CMAKE makes Ninja complain that there are multiple rules generate files such as `CMakeFiles/3.1.20150120-g9b4d43-dirty/CMakeCCompiler.cmake` and friends and that the build may be broken. But only on an initial configure. Should I just filter outputs in CMAKE_PLATFORM_INFO_DIR out of the output list?
(0037762)
Ben Boeckel   
2015-01-21 13:20   
Pushed to stage and next (with tests) as 'ninja-generate-outputs'. Tests can likely be adapted for other generators as well (particularly make, but probably Visual Studio as well).
(0037787)
Brad King   
2015-01-23 09:35   
Re 0015256:0037762: I had to revert that because the tests revealed a problem with listing things like configure_file outputs as RERUN_CMAKE rule outputs. These files are actually byproducts, so they are not always expected to be newer than the inputs like CMakeCache.txt. The Makefile generator works this way by saving them as CMAKE_MAKEFILE_PRODUCTS and re-running CMake only if they do not exist:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalUnixMakefileGenerator3.cxx;hb=v3.1.1#l371 [^]
 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmake.cxx;hb=v3.1.1#l2036 [^]
(0037823)
Ben Boeckel   
2015-01-26 16:36   
So there are two ways to fix this with only CMake code:

  1) add a flag per-generator which says whether the generate step can change cache variables (and not write CMakeCache.txt if so); or
  2) have a post-generate-cache-writing method on the generators which Ninja uses to touch build.ninja and rules.ninja.

Either will fix the problem which is actually caused by the cache file being written to after build.ninja. I'm leaning towards 2 as the better solution (since it is Ninja-local and doesn't require due diligence about the Ninja and Make generators not writing to cache variables), but 1 also avoids excess work.
(0037824)
Ben Boeckel   
2015-01-26 16:43   
Scratch that; CMakeCache.txt needs to be older than *any* configured file.
(0037915)
Brad King   
2015-02-04 15:35   
I think this will require a new feature in Ninja to do correctly:

 https://github.com/martine/ninja/issues/906 [^]
(0042671)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.