MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015614CMakeCCMakepublic2015-06-12 16:032016-01-04 11:51
ReporterFlorianM 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product VersionCMake 3.2.2 
Target VersionFixed in Version 
Summary0015614: add_custom_target/command: Can't give Target the same name as one of the Outputs
DescriptionLet's say you want to transfer the following makefile into a CMake equivalent:

foo_in: foo.c
    $(CC) $< -o $@

foo_out: foo_in
    post_process $< > $@

And you don't want to add the second step as a post-build step. You still want to be able to build foo_in or foo_out separately.
Steps To ReproduceI'm using the "MSYS Makefiles" generator with the following test script:

---

cmake_minimum_required(VERSION 2.8)
project(MakeTargetTest C)

file(WRITE foo.c "#include <windows.h>\nint main() {}")
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/post_process "echo Process something")

add_executable(foo_in foo.c)
set_target_properties(foo_in PROPERTIES SUFFIX "")

add_custom_command(
    OUTPUT foo_out
    COMMAND post_process foo_in > foo_out
    DEPENDS foo_in
)
add_custom_target(foo_out DEPENDS foo_out)

---

$ make foo_out
Built target foo_out

---

[build.make]
...
CMakeFiles/foo_out:

foo_out: CMakeFiles/foo_out
foo_out: CMakeFiles/foo_out.dir/build.make
.PHONY : foo_out

---

If I rename the custom target to something like "foo_out_test" it works correctly:

$ make foo_out_test
Scanning dependencies of target foo_in
[ 50%] Building C object CMakeFiles/foo_in.dir/foo.c.obj
Linking C executable foo_in.
[ 50%] Built target foo_in
[100%] Generating foo_out
[100%] Built target foo_out_test

---

[build.make]
...
CMakeFiles/foo_out_test: foo_out

foo_out: foo_in.
    $(CMAKE_COMMAND) -E cmake_progress_report CMakeFiles $(CMAKE_PROGRESS_1)
    @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold "Generating foo_out"
    post_process foo_in > foo_out

foo_out_test: CMakeFiles/foo_out_test
foo_out_test: foo_out
foo_out_test: CMakeFiles/foo_out_test.dir/build.make
.PHONY : foo_out_test
Additional InformationI understand that the Makefile generator could get confused by dependency that could be a file and a target dependency, but why should this be possible for executables and not for custom commands? And why could I not at least get a warning or error by CMake during generation (since the rule generated is just empty, see "Steps to Reproduce")?

I can see 3 possible solutions:

1. The generator detects that there is a file and a target with the same name and does add a suffix or prefix to its internal build rules for that file.

2. The add_custom_target() command is extended to allow to define its "final" output which is then handled the same way a and add_executable() command output file.

3. Add an GENERIC (linker) language. So you could use files with any extensions with add_executable() that are directly given to a definable "linker".
TagsCMake, dependency, makefile, mingw
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-06-12 16:03FlorianMNew Issue
2015-06-12 16:07FlorianMNote Added: 0038917
2015-06-12 16:09FlorianMTag Attached: CMake
2015-06-12 16:09FlorianMTag Attached: dependency
2015-06-12 16:09FlorianMTag Attached: makefile
2015-06-12 16:09FlorianMTag Attached: mingw
2015-06-15 08:46Brad KingNote Added: 0038923
2015-06-15 08:47Brad KingStatusnew => resolved
2015-06-15 08:47Brad KingResolutionopen => won't fix
2016-01-04 11:51Robert MaynardNote Added: 0040068
2016-01-04 11:51Robert MaynardStatusresolved => closed

Notes
(0038917)
FlorianM   
2015-06-12 16:07   
Wanted to add the link to the source of the discussion: http://stackoverflow.com/questions/30719275/add-custom-command-is-not-generating-a-target [^]
(0038923)
Brad King   
2015-06-15 08:46   
CMake is not intended to produce specific content in a Makefile. Top-level target names created by add_custom_target are always logical (i.e. phony) names. It is simply not allowed to have a file of the same name.
(0040068)
Robert Maynard   
2016-01-04 11:51   
Closing resolved issues that have not been updated in more than 4 months.