| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0014727 | CMake | CMake | public | 2014-02-02 22:57 | 2016-06-10 14:31 | ||||
| Reporter | NAKAMURA Takumi | ||||||||
| Assigned To | Kitware Robot | ||||||||
| Priority | normal | Severity | feature | Reproducibility | always | ||||
| Status | closed | Resolution | moved | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0014727: libraries list in target_link_libraries() may be optimized | ||||||||
| Description | See "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 Reproduce | add_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() | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0035027) Brad King (manager) 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 (manager) 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 (manager) 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 (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. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2014-02-02 22:57 | NAKAMURA Takumi | New Issue | |
| 2014-02-03 14:11 | Brad King | Note Added: 0035027 | |
| 2014-02-03 14:14 | Brad King | Note Added: 0035028 | |
| 2014-02-03 14:18 | Brad King | Note Added: 0035029 | |
| 2016-06-10 14:29 | Kitware Robot | Note Added: 0042474 | |
| 2016-06-10 14:29 | Kitware Robot | Status | new => 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 |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |