Notes
(0031924) Brad King (manager) 2012-12-19 08:25	FYI, the reason we have these dependencies by default is because the build rules for a library may have custom commands to generate headers or sources that are then used by a target that links to it. This applies even to non-linking targets like static libraries. Furthermore there is no separation of target-level ordering dependencies between compilation and link steps within a single target. Therefore any target that links (shared libs and exes) must have an order dependency on its link dependencies. Of course if a project author wants to take responsibility I see no reason not to have an option to skip such dependencies, at least for static libraries. One approach is to add a target property to override the target-level ordering dependencies. This way one could make a static library depend either on nothing or on a subset of its implementation dependencies: add_library(mylib STATIC ...) target_link_libraries(mylib dep1 dep2 dep3) set_property(TARGET mylib PROPERTY COMPILE_DEPENDS dep2) # dep2 generates a header we need Of course one could set the property to "" to erase all dependencies.

(0032965) Reid Kleckner (reporter) 2013-04-30 14:59	I'd like to second this, and also point at some stack overflow questions asking about the same thing: http://stackoverflow.com/questions/9746426/cmake-adds-unnecessary-dependencies-between-o-and-a-files [^] As we start to pile on cores, this extra COMPILE_DEPENDS edge starts to limit parallelism. Specifically, I'm trying to build LLVM, which is internally composed of layers of libraries. For each layer, I basically compile all files in parallel and then bottleneck on the stragglers. This is kind of silly. IMO if a target has a compile dependency on a header, they should name it explicitly. But obviously going forward cmake will have to do something backwards compatible.

(0033817) Alexey Khoroshilov (reporter) 2013-09-13 08:37 edited on: 2013-09-13 08:40	After adding target_include_directories to 2.8.11, it is now very easy to export and import include paths and compile definitions across subprojects automatically. But this strong compile-dependency behavior for static libraries prevents us from using this approach widely (compile time increases dramaticaly). Implementation of COMPILE_DEPENDS property would be really nice for that case. Any chances that the priority of this feature will be increased? target_include_directories gives really nice abilities to work with static subprojects.

(0035477) bitshifter (reporter) 2014-03-23 02:54	I'm also affected by this bug/feature. I'd like to use transitive dependency linking but it practically doubles my build time by serialising parts of my build. We noticed that it seemed a bit generator dependant. There appeared to be a build order dependency imposed in visual studio 2012 and ninja generators, but it looked like makefile builds didn't have any build order dependencies.

(0035478) Brad King (manager) 2014-03-24 08:21	See the note at 0014726:0035023 about a way to achieve this with 2.8.12.

(0035642) bitshifter (reporter) 2014-04-06 20:44	Thanks, that did the trick.

(0041021) vanderhu (reporter) 2016-05-04 06:08 edited on: 2016-05-04 06:11	Actually I would to revive the discussion on this topic as actually it seems to be possible to apply to avoid this strict order dependency for static libraries with a minimal change in cmComputeTargetDepends.cxx which will cover the scenario outlined above, by doing: add_library(mylib STATIC ...) target_link_libraries(mylib dep1 dep2 dep3) add_dependencies(mylib dep2) # dep2 generates a header we need The change is to ignore the STATIC_LIBRARY type in the final compute depends, but only accept it in case the link is strong. Would this be reasonable to get it accepted within CMake? Have a patch ready for this.

(0041023) Brad King (manager) 2016-05-04 08:39	Re 0013799:0041021: Using target_link_libraries has always been enough to get an ordering dependency and many projects depend on this. We cannot change that for any target type. What can be done without changing semantics is for the Ninja generator to detect when the transitive closure of a dependency doesn't have any custom commands and in that case drop ordering dependencies on it from the compilation rules and custom commands. Only the full dependency of the link step on the dependency's library file is needed. Work on this would be better discussed on the developer mailing list.

(0042173) Kitware Robot (administrator) 2016-06-10 14:28	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
2012-12-16 09:00	Christian Rorvik	New Issue
2012-12-19 08:25	Brad King	Note Added: 0031924
2013-04-30 14:59	Reid Kleckner	Note Added: 0032965
2013-09-13 08:37	Alexey Khoroshilov	Note Added: 0033817
2013-09-13 08:40	Alexey Khoroshilov	Note Edited: 0033817
2014-03-23 02:54	bitshifter	Note Added: 0035477
2014-03-24 08:21	Brad King	Relationship added	related to 0014726
2014-03-24 08:21	Brad King	Note Added: 0035478
2014-03-24 08:22	Brad King	Relationship added	related to 0014751
2014-04-06 20:44	bitshifter	Note Added: 0035642
2015-05-05 18:06	Ben Boeckel	Relationship added	related to 0015555
2016-05-04 06:08	vanderhu	Note Added: 0041021
2016-05-04 06:09	vanderhu	Note Edited: 0041021
2016-05-04 06:11	vanderhu	Note Edited: 0041021
2016-05-04 06:11	vanderhu	Note Edited: 0041021
2016-05-04 08:39	Brad King	Note Added: 0041023
2016-06-10 14:28	Kitware Robot	Note Added: 0042173
2016-06-10 14:28	Kitware Robot	Status	new => 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