MantisBT - CMake
View Issue Details

ID	Project	Category	View Status	Date Submitted	Last Update
0013889	CMake	CMake	public	2013-02-04 06:00	2016-06-10 14:31

Reporter	Micha Hergarden
Assigned To	Kitware Robot
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	moved
Platform	x86_64	OS	Linux	OS Version	Ubuntu 12.04
Product Version	CMake 2.8.10.2
Target Version		Fixed in Version

Summary	0013889: Ninja: Multiple add_custom_command for the same output file lead to multiple rules being generated for the same file
Description	The cmake ninja generator adds multiple build rules for the same file, when there are multiple add_custom_command supplied in subdirectories. When ninja is run with the generated build.ninja file this leads to the following warning: ninja: warning: multiple rules generate /tmp/test.c. build will not be correct; continuing anyway I am using the latest ninja from the git repository: https://github.com/martine/ninja.git [^] commit 05736568b9a26599865dd7452e62f70ecdbc9e41
Steps To Reproduce	1. Create a CMakeLists.txt file which adds two subdirectories, e.g.: cmake_minimum_required(VERSION 2.8) ADD_SUBDIRECTORY(tst1) ADD_SUBDIRECTORY(tst2) 2. Create two CMakeLists.txt files for the subdirectories, both of which add a custom command for the same output file, and an executable using that file, e.g.: ADD_CUSTOM_COMMAND(OUTPUT /tmp/test.c COMMAND cmake ARGS -E copy /home/test/test.c /tmp/test.c) ADD_EXECUTABLE(test1 /tmp/test.c) 3. Run cmake -G Ninja You can now examine the build.ninja file to see the multiple build rules 4. Run ninja You will now see the ninja warning.
Additional Information
Tags	linux, ninja
Relationships
Attached Files	testproject.zip (3,321,724) 2014-01-28 02:26 https://public.kitware.com/Bug/file/5053/testproject.zip

Issue History
Date Modified	Username	Field	Change
2013-02-04 06:00	Micha Hergarden	New Issue
2013-02-05 07:04	Micha Hergarden	Tag Attached: linux
2013-02-05 07:04	Micha Hergarden	Tag Attached: ninja
2013-02-09 06:52	Peter Kuemmel	Summary	Multiple add_custom_command for the same output file lead to multiple rules being generated for the same file => Ninja: Multiple add_custom_command for the same output file lead to multiple rules being generated for the same file
2013-03-09 06:29	Peter Kuemmel	Note Added: 0032556
2013-03-09 06:29	Peter Kuemmel	Status	new => backlog
2014-01-27 10:35	Andreas Mohr	Note Added: 0034997
2014-01-27 13:57	Micha Hergarden	Note Added: 0035006
2014-01-27 15:42	Andreas Mohr	Note Added: 0035008
2014-01-28 02:26	Micha Hergarden	File Added: testproject.zip
2014-01-28 02:55	Micha Hergarden	Note Added: 0035009
2014-01-28 03:20	Micha Hergarden	Note Added: 0035010
2016-06-10 14:28	Kitware Robot	Note Added: 0042216
2016-06-10 14:28	Kitware Robot	Status	backlog => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:28	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Notes

I'm having issues recognizing where exactly the parallel handling is taking place.
So, I currently assume your setup to be something like this:

Super project, which does a configure_file() and then populates an ExternalProject_Add() section with various buildwrapper-using lines (for BUILD_COMMAND etc.).

And you've got various sub directories which then are responsible for instantiating one autoconf-/automake-based project each.

OK, anyway, let's analyze your original test case again:
Given parallel execution it's not deterministic when exactly generation of the output file name (test.c) will happen. And that might just be in the middle of test.c having been generated and now being used for the resulting build step (depender). --> Re-written file --> build breakage, of an ongoing build making use of the first-time generated file.
That, AFAIWT, is exactly why Ninja is complaining.
So, for your contrived test case here, I'd think the unfriendly warning is quite understandable.

For your configure_file() case, I'm a bit astonished:
you say that it's the configure_.in_ file that it is complaining about.
Yet that file is a single *source*-side file, then multiplied into various differing(!?) output locations, via repeated configure_file() execution.
I'm astonished why this would be a problem. Especially since I'd assume the configure_file() call to be configure-time execution, i.e. within the main layer (or are we talking build-time-based sub project here already as well??), where Ninja build-time handling would not even enter the picture yet.

Are you sure that the configure-time configure_file() is the problem, or rather some ensuing build-time use of the source/destination file? (try deactivating build-time use of these to see whether the problem vanishes).
I've had multiple "Ninja issues" already, and every - single - time - I ended up realizing having made some bl00dy build hierarchy/chain precision mistake which the make-based build would not even care about in the least.