View Issue Details [ Jump to Notes ] [ Print ]
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.
TagsNo tags attached.
Attached Files

 Relationships
related to 0014751closedBrad King Generalize LINK_ONLY 
related to 0013799closedKitware Robot Optionally disable build order dependency target_link_libraries 

  Notes
(0035020)
NAKAMURA Takumi (reporter)
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 (manager)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2014-02-02 22:06 NAKAMURA Takumi New Issue
2014-02-02 22:11 NAKAMURA Takumi Note Added: 0035020
2014-02-03 09:27 Brad King Note Added: 0035021
2014-02-03 09:27 Brad King Status new => backlog
2014-02-03 09:27 Brad King Summary target_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:51 Brad King Note Added: 0035023
2014-02-04 08:55 NAKAMURA Takumi Note Added: 0035035
2014-02-13 10:22 Brad King Relationship added related to 0014751
2014-02-13 10:27 Brad King Note Added: 0035101
2014-03-24 08:21 Brad King Relationship added related to 0013799
2015-06-26 14:38 Parker Coates Note Added: 0038993
2016-06-10 14:29 Kitware Robot Note Added: 0042473
2016-06-10 14:29 Kitware Robot Status backlog => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team