MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013139CMakeCMakepublic2012-04-16 18:202012-09-03 16:01
Reportermwoehlke 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
Platformx86_64OSFedoraOS Version17
Product Version 
Target VersionCMake 2.8.8Fixed in VersionCMake 2.8.8 
Summary0013139: ninja does not rebuild external projects
DescriptionExternal projects are not rebuilt when their sources change when using the ninja generator (using CMake 2.8.8-rc2). It appears that even when removing the build stamp to force a build, ninja is not re-run for the external project.

When using the Unix Makefiles generator, all is well.
Steps To Reproduce- Set up an external project using the following snippet:

ExternalProject_Add(foo
  DEPENDS ${BUILD_FOO_DEPENDENCY}
  SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/foo
  BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/foo
  INSTALL_DIR ${CMAKE_INSTALL_PREFIX}
)
ExternalProject_Add_Step(foo forcebuild
  COMMAND ${CMAKE_COMMAND}
    -E remove ${CMAKE_CURRENT_BUILD_DIR}/foo-prefix/src/foo-stamp/foo-build
  DEPENDEES configure
  DEPENDERS build
  ALWAYS 1
)

- Generate two build trees; one with ninja, and one with makefiles.
- Build both build trees.
- Touch a source file in the subproject
- Rebuild both build trees.

The makefiles build tree rebuilds the external project 'foo'.

The ninja build tree reports:

[1/1] Performing forcebuild step for 'foo'

...and does not rebuild 'foo'.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-04-16 18:20mwoehlkeNew Issue
2012-04-17 14:38David ColeNote Added: 0029203
2012-04-18 13:08mwoehlkeNote Added: 0029217
2012-04-18 13:39Brad KingNote Added: 0029221
2012-04-18 13:56mwoehlkeNote Added: 0029222
2012-04-18 14:16Brad KingStatusnew => resolved
2012-04-18 14:16Brad KingResolutionopen => no change required
2012-04-18 14:16Brad KingAssigned To => Brad King
2012-04-18 14:33David ColeFixed in Version => CMake 2.8.8
2012-04-18 14:33David ColeTarget Version => CMake 2.8.8
2012-09-03 16:01David ColeNote Added: 0030856
2012-09-03 16:01David ColeStatusresolved => closed

Notes
(0029203)
David Cole   
2012-04-17 14:38   
I suspect the code starting at this line:

  http://public.kitware.com/gitweb?p=cmake.git;a=blob;f=Modules/ExternalProject.cmake;h=b6fe19004682a6e394d63e984e9f5289699abeb9;hb=233b5cbaf70b9791df06e7e96737214e40780595#l1455 [^]

If you edit your copy of ExternalProject.cmake, and comment out the two lines that read:

  set(complete_outputs
         ${complete_outputs} ${stamp_dir}${cfgdir}/${name}-done)

Does that fix the issue?

If not, it's most likely something more subtle in the ninja generator code itself.
(0029217)
mwoehlke   
2012-04-18 13:08   
No change that I could see.
(0029221)
Brad King   
2012-04-18 13:39   
I can reproduce this. There is a typo in the example. The line

 -E remove ${CMAKE_CURRENT_BUILD_DIR}/foo-prefix/src/foo-stamp/foo-build

should be

 -E remove ${CMAKE_CURRENT_BINARY_DIR}/foo-prefix/src/foo-stamp/foo-build

Note s/BUILD_DIR/BINARY_DIR/. After fixing the typo it works fine under both Makefile and Ninja generators.

With the typo the remove command is not actually doing anything. It only works by accident under Makefile generators because they always rebuild things that depend on symbolic (phony) targets anyway. Ninja is evaluating each rule on its own after its dependencies are up to date. Since the file is not really removed it decides the build step does not need to re-run.
(0029222)
mwoehlke   
2012-04-18 13:56   
Ah, thanks. I'll fix that in my project :-).

(To confirm, that does fix the problem on my end. The change to ExternalProject.cmake does not appear necessary.)
(0030856)
David Cole   
2012-09-03 16:01   
Closing resolved issues that have not been updated in more than 4 months.