View Issue Details Jump to Notes ] Print ]
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.
TagsNo tags attached.
Attached Files

 Relationships
related to 0014963closedBrad King Add explicit specification of custom command side effect outputs 

  Notes
(0037233)
Brad King (manager)
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 (manager)
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 (manager)
2014-12-01 14:37

The RERUN_CMAKE rules.ninja entry may simply need a 'restat = 1'.
(0037758)
Ben Boeckel (developer)
2015-01-20 14:57

"restat = 1" doesn't solve this problem.
(0037759)
Ben Boeckel (developer)
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 (developer)
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 (manager)
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 (developer)
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 (developer)
2015-01-26 16:43

Scratch that; CMakeCache.txt needs to be older than *any* configured file.
(0037915)
Brad King (manager)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2014-11-18 18:14 Stephen Kelly New Issue
2014-11-19 10:23 Brad King Relationship added related to 0014963
2014-11-19 10:25 Brad King Note Added: 0037233
2014-11-19 10:25 Brad King Target Version => CMake 3.2
2014-11-19 10:25 Brad King Description Updated
2014-12-01 14:34 Brad King Note Added: 0037340
2014-12-01 14:37 Brad King Note Added: 0037341
2015-01-20 14:57 Ben Boeckel Note Added: 0037758
2015-01-20 15:29 Ben Boeckel Note Added: 0037759
2015-01-21 13:20 Ben Boeckel Note Added: 0037762
2015-01-21 13:20 Ben Boeckel Assigned To => Ben Boeckel
2015-01-21 13:20 Ben Boeckel Status new => feedback
2015-01-23 09:35 Brad King Note Added: 0037787
2015-01-26 16:36 Ben Boeckel Note Added: 0037823
2015-01-26 16:43 Ben Boeckel Note Added: 0037824
2015-02-04 15:35 Brad King Note Added: 0037915
2015-02-04 15:35 Brad King Status feedback => acknowledged
2015-02-04 15:35 Brad King Target Version CMake 3.2 =>
2016-06-10 14:29 Kitware Robot Note Added: 0042671
2016-06-10 14:29 Kitware Robot Status acknowledged => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team