Notes
(0010501) Brad King (manager) 2008-02-14 15:51	I knew someone would be upset by this, but it is necessary. Duplicate target names in the Xcode and VS IDE generators have unpredictable behavior. We cannot continue to silently support this case. In order to help projects that only care about the Makefile generators, I can create a global property "ALLOW_DUPLICATE_CUSTOM_TARGETS" that allows the behavior. Non-makefile generators will immediately error out when this property is set, but then Makefile-only projects can be fixed with one line: set_property(GLOBAL PROPERTY ALLOW_DUPLICATE_CUSTOM_TARGETS 1) FYI, with CMake 2.4 when you build the "doxy" target in a subdirectory I bet it still builds the doxy target from all directories.

(0010502) Brad King (manager) 2008-02-14 15:52	BTW, you can easily create this "doxy" case without duplicate custom targets: # CMakeLists.txt add_custom_target(doxy) add_subdirectory(A) add_subdirectory(B) # A/CMakeLists.txt add_custom_target(doxy_A) add_dependencies(doxy doxy_A) # B/CMakeLists.txt add_custom_target(doxy_B) add_dependencies(doxy doxy_B) This also allows users to build the doxy target in one subdirectory without running it in all directories.

(0010503) Brad King (manager) 2008-02-14 16:43	I've committed changes implementing the ALLOW_DUPLICATE_CUSTOM_TARGETS feature. I also made the error even more descriptive. /cvsroot/CMake/CMake/Source/cmAddCustomTargetCommand.cxx,v <-- cmAddCustomTargetCommand.cxx new revision: 1.30; previous revision: 1.29 /cvsroot/CMake/CMake/Source/cmGlobalGenerator.cxx,v <-- cmGlobalGenerator.cxx new revision: 1.226; previous revision: 1.225 /cvsroot/CMake/CMake/Source/cmGlobalGenerator.h,v <-- cmGlobalGenerator.h new revision: 1.107; previous revision: 1.106 /cvsroot/CMake/CMake/Source/cmGlobalUnixMakefileGenerator3.h,v <-- cmGlobalUnixMakefileGenerator3.h new revision: 1.55; previous revision: 1.54 /cvsroot/CMake/CMake/Source/cmMakefile.cxx,v <-- cmMakefile.cxx new revision: 1.437; previous revision: 1.436 /cvsroot/CMake/CMake/Source/cmMakefile.h,v <-- cmMakefile.h new revision: 1.225; previous revision: 1.224 /cvsroot/CMake/CMake/Source/cmake.cxx,v <-- cmake.cxx new revision: 1.360; previous revision: 1.359

(0010504) Alex Neundorf (developer) 2008-02-14 16:48	You are fast ! I was still typing a note, so I reopen the bug for now to be able to add that note: I tested here with 2.4.6, if I build doxy in sub1 then only doxy in sub is built. The idea with the different names is complicated. I used this for running doxygen, the target names was "docs". So I knew I could go in any directory and build "docs", I didn't need to check what the name in this directory is. This target was created inside a macro like add_doc_target() or something like this. So the logic in that macro would have to be changed so that it creates a unique name in every directory. Then I would have to figure out that name. So it would be really a by far not so nice solution. I know it wasn't officially supported, and I think it may also have worked differently with cmake 2.0. Couldn't this be somehow made into an official feature ? Would it be possible for the xcode and msvc generators to collect the custom targets with the same name into one target, which executes all commands and depends on all depends of the separate targets ? I would prefer this over an additional property/variable which modifies cmake behaviour slightly, there have been quite a few added lately. Alex

(0010505) Brad King (manager) 2008-02-14 17:14	Combining custom targets across directories will be a HUGE can of worms with yet further unpredictable behavior. What we really need is a notion of a "local target" that runs the same rule in every directory with that directory as the working directory. The rule would not be allowed to have any input or output files...just a command line to run unconditionally. On IDE generators the target would appear only once and always run in the top level. Currently the "install", "test", and "clean" targets work like this. It would have to become a first-class feature. I'd also want to convert the install, test, and clean targets to be defined this way in the first place. They could be created at the beginning of the configure step and referencable by users.

(0010506) Brad King (manager) 2008-02-14 17:19	There is no way I'm getting a whole new kind of target in before 2.6. For now projects can do things like if("${CMAKE_GENERATORS}" MATCHES Make) set_property(GLOBAL PROPERTY ALLOW_DUPLICATE_CUSTOM_TARGETS 1) set(USE_SUBDIR_TARGETS) endif("${CMAKE_GENERATORS}" MATCHES Make) add_custom_target(docs ...) # A/CMakeLists.txt if(USE_SUBDIR_TARGETS) add_custom_target(docs ...) endif(USE_SUBDIR_TARGETS)

(0010507) Alex Neundorf (developer) 2008-02-14 17:43	Sounds good :-) Converting the clean, install etc. targets to "real" targets would be a good thing, this is actually another use of the multiple-targets-with-the-same-name "feature". I added targets "veryclean" in subdirs, which cleaned some special things and then called "make clean" (using the appropriate cmake variables) to do the normal cleaning and there have been several questions regarding this on the mailing list. Alex

(0010508) Alex Neundorf (developer) 2008-02-14 17:45	As discussed, having these "local" targets would be a nice thing in the long term. Alex

(0026521) Brad King (manager) 2011-05-17 15:54	Moving to backlog. I think the approach mentioned in 0006348:0010505 will work but I have no time to work on this.

(0040515) Bruce Adams (reporter) 2016-02-19 12:13	Asking about this on stackoverflow led me here. http://stackoverflow.com/questions/35489093/cmake-special-targets-like-all-and-test-having-the-same-name-in-multiple-pl [^] It is possible to implement a add_local_target() workaround macro like mine as in the question. My suggestion is to make something like this official until there is an opportunity to implement a genuine add_local_target() at which time policy CMP0002 could perhaps be eliminated.

(0041408) Kitware Robot (administrator) 2016-06-10 14:27	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2008-02-14 15:16	Alex Neundorf	New Issue
2008-02-14 15:16	Alex Neundorf	File Added: multipletargets.tar.gz
2008-02-14 15:19	Bill Hoffman	Status	new => assigned
2008-02-14 15:19	Bill Hoffman	Assigned To	=> Brad King
2008-02-14 15:51	Brad King	Note Added: 0010501
2008-02-14 15:52	Brad King	Note Added: 0010502
2008-02-14 16:43	Brad King	Status	assigned => closed
2008-02-14 16:43	Brad King	Note Added: 0010503
2008-02-14 16:43	Brad King	Resolution	open => fixed
2008-02-14 16:48	Alex Neundorf	Status	closed => feedback
2008-02-14 16:48	Alex Neundorf	Resolution	fixed => reopened
2008-02-14 16:48	Alex Neundorf	Note Added: 0010504
2008-02-14 17:14	Brad King	Note Added: 0010505
2008-02-14 17:19	Brad King	Note Added: 0010506
2008-02-14 17:43	Alex Neundorf	Note Added: 0010507
2008-02-14 17:45	Alex Neundorf	Note Added: 0010508
2008-02-14 17:45	Alex Neundorf	Status	feedback => assigned
2008-04-03 15:02	Alex Neundorf	Summary	fix in cmake cvs removes nice feature => custom global targets (targets which when built from the root build all targets with the same name in subdirs)
2009-01-29 14:35	Brad King	Relationship added	related to 0008438
2011-05-17 15:54	Brad King	Note Added: 0026521
2011-05-17 15:54	Brad King	Assigned To	Brad King =>
2011-05-17 15:54	Brad King	Status	assigned => backlog
2012-02-13 09:49	Brad King	Relationship added	related to 0012960
2012-02-14 10:40	Brad King	Relationship added	related to 0012961
2016-02-19 12:13	Bruce Adams	Note Added: 0040515
2016-06-10 14:27	Kitware Robot	Note Added: 0041408
2016-06-10 14:27	Kitware Robot	Status	backlog => resolved
2016-06-10 14:27	Kitware Robot	Resolution	reopened => moved
2016-06-10 14:27	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:30	Kitware Robot	Status	resolved => closed