View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014747CMakeCMakepublic2014-02-10 13:112015-01-05 08:39
ReporterDaniel Levin 
Assigned To 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product VersionCMake 2.8.12.2 
Target VersionFixed in Version 
Summary0014747: Target dependencies do not trigget build on Ninja
DescriptionTarget dependencies output do not trigger build of target itself using Ninja generator. See attached archive for example.

Imaging next script:

add_custom_target(A DEPENDS somefile)
add_dependencies(A B)

Expected behavior: dependency checking of target A should be triggered AFTER target B was built. If file 'somefile' depends on output of target B, build of target A should be started. Works using make generator, does not work using ninja generator.
Steps To ReproduceCreate make build for attached project. Run make from command line continuously. If RandomTouch target has output (random=1) it does trigger Test target build, as expected. If RandomTouch target has no output (random=0) Test target not built, as expected.

Create ninja build and do the same. Test target build is running depending on PREVIOUS invocation of ninja command, not CURRENT. Because dependency scan of target Test is done before RandomTouch target finished running and make any output.
TagsNo tags attached.
Attached Filestgz file icon cmake-pre-build.tgz [^] (10,240 bytes) 2014-02-10 13:11

 Relationships
related to 0014728closedBen Boeckel [CMake/Ninja] add_dependencies() to objlib's user is ignored. 
related to 0014963closedBrad King Add explicit specification of custom command side effect outputs 
related to 0014771closedKitware Robot Ninja generator does not always honor SYMBOLIC rules with no command 

  Notes
(0035085)
Brad King (manager)
2014-02-10 13:41

This looks similar to issue 0014728 where the inter-target ordering dependencies, which are implemented on individual rules of each target, are perhaps missing from some of the individual rules.
(0035087)
Daniel Levin (reporter)
2014-02-10 14:08

In my case dependency is there and always running normally before target. But resulting output from that dependency has no influence on target command itself, as it expected to be.

I would want to understand whether make generator behavior is actually correct and ninja generator behavior should replicate it.

It not what is the correct way to implement prebuild step that must be run always before target, affecting target DAC? Typical scenario: I want to create custom dependency check as a prebuild step.
(0035088)
Brad King (manager)
2014-02-10 14:18

Re 0014747:0035087: Your expectation and the Makefile generator behavior are correct. CMake intends to bring all rules in a given logical target up to date before considering any rules in dependent logical targets. This is a bug in the Ninja generator.
(0035819)
Ben Boeckel (developer)
2014-05-05 18:15

Hmm. I tried poking this and even poking the build.ninja by hand I was unable to get Ninja to Do The Right Thing(TM).

It looks like the problem is that the add_custom_target isn't declaring that the file "foo" is an output file and so marks it as phony. I don't know why Make is working in this case since it has no rule to build "foo" in the generated files. Can anyone confirm that it works with non-GNU make?

I was able to get things to work with:

add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/foo" "${CMAKE_CURRENT_BINARY_DIR}/foo.noexist"
        COMMAND echo "touching..."
        COMMAND ${CMAKE_COMMAND} -D FILE="${CMAKE_CURRENT_BINARY_DIR}/foo" -P "${CMAKE_CURRENT_SOURCE_DIR}/random-touch.cmake"
        COMMAND echo "touching... DONE"
)
add_custom_target(RandomTouch
        DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/foo"
)

The problem now is that Make *always* rebuilds bar because it doesn't check whether foo was actually modified or not as a part of the custom command.

I think this is probably hitting the corner where CMake has no concept of a custom_command which is both a part of a target *and* generates output and Ninja and Make just have different ways of interpreting dangling rules. So CMake *can* do this, but it probably needs something like:

add_custom_target(RandomTouch COMMAND ... OUTPUT foo)

or

add_custom_target(RandomTouch)
add_custom_command(OUTPUT foo TARGET RandomTouch COMMAND ...)
(0035821)
Ben Boeckel (developer)
2014-05-05 18:37

I ran it with bmake (NetBSD's make) and the attached tarball worked, so it's not just GNU make that works.
(0035830)
Ben Boeckel (developer)
2014-05-06 16:00

Since I can't get Ninja to do the right thing even with a hand-written build.ninja file, I've opened a bug against ninja: <https://github.com/martine/ninja/issues/760>. [^]
(0036295)
Brad King (manager)
2014-07-01 09:32

I'm resolving this as a duplicate of issue 0014963 which describes the larger problem. Either 0014963 needs to be resolved on the CMake side, or the Ninja issue linked in 0014747:0035830 needs to be resolved on the Ninja side. That will resolve this issue.
(0037576)
Robert Maynard (manager)
2015-01-05 08:39

Closing resolved issues that have not been updated in more than 4 months

 Issue History
Date Modified Username Field Change
2014-02-10 13:11 Daniel Levin New Issue
2014-02-10 13:11 Daniel Levin File Added: cmake-pre-build.tgz
2014-02-10 13:40 Brad King Relationship added related to 0014728
2014-02-10 13:41 Brad King Note Added: 0035085
2014-02-10 14:08 Daniel Levin Note Added: 0035087
2014-02-10 14:18 Brad King Note Added: 0035088
2014-02-25 09:50 Brad King Relationship added related to 0014771
2014-05-05 18:15 Ben Boeckel Note Added: 0035819
2014-05-05 18:37 Ben Boeckel Note Added: 0035821
2014-05-06 16:00 Ben Boeckel Note Added: 0035830
2014-05-06 16:00 Ben Boeckel Assigned To => Ben Boeckel
2014-05-06 16:00 Ben Boeckel Status new => assigned
2014-06-11 08:35 Brad King Relationship added related to 0014963
2014-07-01 09:32 Brad King Note Added: 0036295
2014-07-01 09:32 Brad King Assigned To Ben Boeckel =>
2014-07-01 09:32 Brad King Status assigned => resolved
2014-07-01 09:32 Brad King Resolution open => duplicate
2015-01-05 08:39 Robert Maynard Note Added: 0037576
2015-01-05 08:39 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team