MantisBT - CMake
View Issue Details
0013363CMakeCMakepublic2012-06-30 06:502013-10-07 10:03
Orçun Gökbulut 
Stephen Kelly 
normalfeaturealways
closedfixed 
AllAllAll
CMake 2.8.8 
CMake 2.8.11 
0013363: target_link_libraries does not sets target's include and link paths according to li
When target_link_libraries used with a cmake static library target as a link library, CMake does not combine linked static library targets include and linker directory paths to target's include and linker directory paths.

Suppose that there is a directory like this;
+ Project
| + Sub Project
| | +-Dependencies
| | |-Library.h
| | |-Library.lib
| |-CMakeLists.txt
| |-SubProject.cpp
|-Main.cpp
|-CMakeLists.txt

Content of SubProject/CMakeLists.txt;
  link_directories(Dependencies)
  include_directories(Dependencies)
  add_library(SubProject SubProject.cpp)
  target_link_library(SubProject Library.lib)

Content of /CMakeLists.txt
  add_executable(Main)
  target_link_libraries(Main SubProject)

This setup causes linker and include problems in visual studio becouse linker or compiler can not find Library.lib or Library.h while compiling Main target.

In order to work around this problem we have to move link_directories and include_directories SubProject/CMakeLists.txt to /CMakeLists.txt.
This work around causes problems in big projects which uses different libraries on different project configurations. In this kind of project, when a new sub project/module added to the project it's library and include directories should be added to /CMakeLists.txt.
If a sub project's/module's dependent library has some constrains like platform dependency (like external library is a windows library and does not work on linux but we have a linux alternative which is implamented on an other sub project/module) we have to use many if clauses on include_directories and library_directory.
In summary, missing of this feature prevents more moduler and non-centered project structures becouse we have to modify or maintain when a new module with non-shared library dependency added to project instead of just a simple add_subdirectory command.
Create a project structure like this one;
+ Project
| + Sub Project
| | +-Dependencies
| | |-Library.h
| | |-Library.lib
| |-CMakeLists.txt
| |-SubProject.cpp
|-Main.cpp
|-CMakeLists.txt

Content of SubProject/CMakeLists.txt;
  link_directories(Dependencies)
  include_directories(Dependencies)
  add_library(SubProject SubProject.cpp)
  target_link_library(SubProject Library.lib)

Content of /CMakeLists.txt
  add_executable(Main)
  target_link_libraries(Main SubProject)

Compiler can not find Library.lib when linking target named 'Main'.
No tags attached.
Issue History
2012-06-30 06:50Orçun GökbulutNew Issue
2012-07-01 08:35Brad KingNote Added: 0029867
2012-07-01 08:35Brad KingStatusnew => backlog
2012-08-27 07:07Stephen KellyAssigned To => Stephen Kelly
2012-08-27 07:07Stephen KellyStatusbacklog => assigned
2013-03-13 11:49Stephen KellyNote Added: 0032603
2013-03-13 11:49Stephen KellyStatusassigned => resolved
2013-03-13 11:49Stephen KellyFixed in Version => CMake 2.8.11
2013-03-13 11:49Stephen KellyResolutionopen => fixed
2013-10-07 10:03Robert MaynardNote Added: 0033996
2013-10-07 10:03Robert MaynardStatusresolved => closed

Notes
(0029867)
Brad King   
2012-07-01 08:35   
A general name for this feature is "usage requirements", as in automatic propagation of all requirements of clients to use a library. CMake handles link dependencies automatically, but not preprocessor definitions and search paths or other features. There is discussion here:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615 [^]
http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements [^]
(0032603)
Stephen Kelly   
2013-03-13 11:49   
CMake 2.8.11 has API to allow what this feature request is requesting. Targets can have INTERFACE_INCLUDE_DIRECTORIES for example.

Having something similar for linker directory paths shouldn't really be needed. CMake typically uses full paths for libraries.
(0033996)
Robert Maynard   
2013-10-07 10:03   
Closing resolved issues that have not been updated in more than 4 months.