(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

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