MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014726CMakeCMakepublic2014-02-02 22:062016-06-10 14:31
ReporterNAKAMURA Takumi 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 2.8.12.1 
Target VersionFixed in Version 
Summary0014726: target_link_libraries may have option not to add dependencies, for archive target.
Description  add_library(foo_lib ...)
  target_link_libraries(foo_lib bar_lib)

I understand it implies add_dependencies(foo_lib bar_lib).

In practice, foo_lib doesn't always require that bar_lib were up-to-date.
In other words, foo_lib and bar_lib might be built in parallel.
This issue makes parallel build too serialized and slow.

Even if lib(s) were split with objlib, archiver(ar cr) is serialized.
(When I tried, both objlib(s) can be built in parallel.)

Of course,

  add_library(foobar_so SHARED ...)
  target_link_libraries(foobar_so foo_lib)

I think it'd be reasonable to imply add_dependencies(foobar_so foo_lib bar_lib) for foobar_so.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0014751closed Brad King Generalize LINK_ONLY 
related to 0013799closed Kitware Robot Optionally disable build order dependency target_link_libraries 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-02-02 22:06NAKAMURA TakumiNew Issue
2014-02-02 22:11NAKAMURA TakumiNote Added: 0035020
2014-02-03 09:27Brad KingNote Added: 0035021
2014-02-03 09:27Brad KingStatusnew => backlog
2014-02-03 09:27Brad KingSummarytarget_link_library may have option not to add dependencies, for archive target. => target_link_libraries may have option not to add dependencies, for archive target.
2014-02-03 09:51Brad KingNote Added: 0035023
2014-02-04 08:55NAKAMURA TakumiNote Added: 0035035
2014-02-13 10:22Brad KingRelationship addedrelated to 0014751
2014-02-13 10:27Brad KingNote Added: 0035101
2014-03-24 08:21Brad KingRelationship addedrelated to 0013799
2015-06-26 14:38Parker CoatesNote Added: 0038993
2016-06-10 14:29Kitware RobotNote Added: 0042473
2016-06-10 14:29Kitware RobotStatusbacklog => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0035020)
NAKAMURA Takumi   
2014-02-02 22:11   
Excuse me, wrong summary line, s/target_link_library/target_link_libraries/
I won't find the way to edit it.
(0035021)
Brad King   
2014-02-03 09:27   
Among the historical reasons for adding dependencies is that the dependency (foo_lib) may have custom commands or other side effects that generate header files or other sources that are consumed by the dependent (bar_lib). This is a conservative approach, but it does not rule out having an option to skip the dependency.
(0035023)
Brad King   
2014-02-03 09:51   
Actually, with CMake 2.8.12 one can do this:

 cmake_minimum_required(VERSION 2.8.12)
 project(Issue14726 C)
 add_library(foo_lib STATIC foo.c)
 add_library(bar_lib STATIC bar.c)
 target_link_libraries(bar_lib INTERFACE foo_lib)
 add_executable(zot_exe zot.c)
 target_link_libraries(zot_exe bar_lib)
(0035035)
NAKAMURA Takumi   
2014-02-04 08:55   
Brad, thanks, tweaked cmakefiles are working as expected. (in llvm and clang)

I took;

  - STATIC -> INTERFACE
  - SHARED -> PRIVATE
  - others -> open w/o any keys.

Then, my has become whether I could suggest 2.8.12 to the community.
I'll ask there.
(0035101)
Brad King   
2014-02-13 10:27   
Another approach that may work back through 2.8.8 is to use OBJECT libraries to compile all the objects and then reference them as sources of the actual libraries which can then have link dependencies.

I think the approach discussed in the cmake-developers mailing list thread that led to 0014751 will be the best approach in the future:

 target_link_libraries(bar_lib INTERFACE $<LINK_ONLY:foo_lib>)

This says that consumers of bar_lib need to link to foo_lib but that bar_lib itself does not care about foo_lib being ready.

The $<LINK_ONLY> generator expression is currently not documented for public use so this is not currently an officially supported solution.
(0038993)
Parker Coates   
2015-06-26 14:38   
I'm a bit confused about the current state of things. Let's say that "apple" is a static library depending on an external third party library, "cucumber" and includes headers from cucumber in its own public headers. "orange" is a static library that depends on apple.

If I do the following, everything works, but there's an unnecessary build order dependency between orange and apple:


add_library(apple STATIC apple.cpp)
target_include_directories(apple PUBLIC /include/cucumber)
add_library(orange STATIC orange.cpp)
target_link_library(orange apple)


If instead I do the following, orange fails to build because it can't find cucumbers headers:


add_library(apple STATIC apple.cpp)
target_include_directories(apple PUBLIC /include/cucumber)
add_library(orange STATIC orange.cpp)
target_link_library(orange INTERFACE apple)


Is there currently any way to get all the transitive goodies from apple into orange without introducing a build order dependency? I expected the INTERFACE parameter of target_link_library to do that, but it seems to only handle transitive linking.
(0042473)
Kitware Robot   
2016-06-10 14:29   
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.