MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014727CMakeCMakepublic2014-02-02 22:572016-06-10 14:31
ReporterNAKAMURA Takumi 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0014727: libraries list in target_link_libraries() may be optimized
DescriptionSee "suboptimal" cases.

The document says,
"Repeated calls for the same <target> append items in the order called."
I understand they are expected behaviors.

That said, I wish add_executable() (and add_library(MODULE|SHARED)) may have an option to optimize link order.

FYI, redundant target_link_libraries() for add_library() doesn't cause suboptimal link order in most cases. See the case in baz.


Consider cases;

  1) To add user-customized target_link_libraries() after a certain macro that contains add_executable() and its target_link_libraries().

  2) I'd like to write, in target_link_libraries(),
    not "tuned" list of libraries,
    but "actually used in SOURCES" list of libraries.
    I am planning to write "auto dependencies scanner and generator"


FYI, one of my issues is in LLVM.
For example clang/tools/clang-format/CMakeLists.txt
https://github.com/chapuni/clang/blob/master/tools/clang-format/CMakeLists.txt [^]

add_executable(clang-format) emits optimal list of libraries only when;

  target_link_libraries(clang-format clangFormat)

In this case, clanbBasic, clangLex, clangRewriteCore, clangTooling, and LLVMSupport are *actually referenced* from ClangFormat.cpp.
Steps To Reproduceadd_library(foo foo.c)
add_library(bar bar.c)
target_link_libraries(bar foo)
add_library(baz baz.c)
target_link_libraries(baz foo)
target_link_libraries(baz bar)
target_link_libraries(baz foo bar)
add_executable(foobar foobar.c)
if(0)
  # suboptimal -- libfoo.a libbaz.a libbar.a libfoo.a
  target_link_libraries(foobar foo baz)
elseif(0)
  # suboptimal -- libfoo.a libbaz.a libbar.a libfoo.a
  target_link_libraries(foobar foo)
  target_link_libraries(foobar baz)
elseif(0)
  # suboptimal -- libbaz.a libbaz.a libbaz.a libbar.a libfoo.a
  target_link_libraries(foobar baz)
  target_link_libraries(foobar baz baz)
else()
  # optimal -- libbaz.a libbar.a libfoo.a
  target_link_libraries(foobar baz)
endif()
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-02-02 22:57NAKAMURA TakumiNew Issue
2014-02-03 14:11Brad KingNote Added: 0035027
2014-02-03 14:14Brad KingNote Added: 0035028
2014-02-03 14:18Brad KingNote Added: 0035029
2016-06-10 14:29Kitware RobotNote Added: 0042474
2016-06-10 14:29Kitware RobotStatusnew => 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
(0035027)
Brad King   
2014-02-03 14:11   
If the final line lists things in the optimal order:

 target_link_libraries(foobar baz bar foo)

CMake recognizes that all dependencies among the libraries are satisfied and does not add anything.
(0035028)
Brad King   
2014-02-03 14:14   
Re 0014727:0035027: In other words, if all target_link_libraries list direct dependencies in a consistent order and without duplication then CMake should generate an optimal link line. Any items beyond that means CMake thinks you're telling it more is needed.

FYI, the full link dependency analysis method is documented in comments here:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmComputeLinkDepends.cxx;hb=v2.8.12.2 [^]
(0035029)
Brad King   
2014-02-03 14:18   
W.r.t. my patches to LLVM to propagate library dependencies:

 http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/173517 [^]

currently extra linking may occur because explicit_map_components_to_libraries is still doing its own dependency analysis *and* CMake is propagating dependencies. I have a follow up series that drops handling of dependencies by explicit_map_components_to_libraries but didn't want to dump too much at once to the llvm-commits list.
(0042474)
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.