kolan
/
CMake
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
CMake/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt

93 lines
2.5 KiB
CMake
Raw Normal View History

target_link_libraries: Add LINK_(PUBLIC|PRIVATE) options Makes it possible to specify the link dependencies and link interfaces in one command without repetition.
2011-10-07 04:41:37 +04:00
cmake_minimum_required(VERSION 2.8)
project(target_link_libraries)
file(WRITE
"${CMAKE_CURRENT_BINARY_DIR}/main.cxx"
"int main() { return 0; }
"
)
add_executable(
target_link_libraries
"${CMAKE_CURRENT_BINARY_DIR}/main.cxx"
)
macro(ASSERT_PROPERTY _target _property _value)
get_target_property(_out ${_target} ${_property})
if (NOT _out)
set(_out "")
endif()
if (NOT "${_out}" STREQUAL "${_value}")
message(SEND_ERROR "Target ${_target} does not have property ${_property} with value ${_value}. Actual value: ${_out}")
endif()
endmacro()
include(GenerateExportHeader)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
add_library(depA SHARED depA.cpp)
generate_export_header(depA)
Allow target_link_libraries with IMPORTED targets. This makes it possible to use: target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar) where foo is an IMPORTED target. Other tll() signatures are not allowed.
2012-11-26 15:30:00 +04:00
add_library(importedlib UNKNOWN IMPORTED)
target_link_libraries(importedlib LINK_INTERFACE_LIBRARIES depA)
target_link_libraries: Add LINK_(PUBLIC|PRIVATE) options Makes it possible to specify the link dependencies and link interfaces in one command without repetition.
2011-10-07 04:41:37 +04:00
add_library(depB SHARED depB.cpp)
generate_export_header(depB)
target_link_libraries(depB LINK_PRIVATE depA)
Add LINK_LIBRARIES property for direct target link dependencies Previously we kept direct link dependencies in OriginalLinkLibraries. The property exposes the information in the CMake language through the get/set_property commands. We preserve the OriginalLinkLibraries value internally to support old APIs like that for CMP0003's OLD behavior, but the property is now authoritative. This follows up from commit d5cf644a (Split link information processing into two steps, 2012-11-01). This will be used later to populate the link interface properties when exporting targets, and will later allow use of generator expressions when linking to libraries with target_link_libraries. Also make targets depend on the (config-specific) union of dependencies. CMake now allows linking to dependencies or not depending on the config. However, generated build systems are not all capable of processing config-specific dependencies, so the targets depend on the union of dependencies for all configs.
2012-12-06 15:14:03 +04:00
add_library(libgenex SHARED libgenex.cpp)
generate_export_header(libgenex)
set_property(TARGET depB APPEND PROPERTY
LINK_LIBRARIES $<1:libgenex>
)
target_link_libraries: Add LINK_(PUBLIC|PRIVATE) options Makes it possible to specify the link dependencies and link interfaces in one command without repetition.
2011-10-07 04:41:37 +04:00
add_library(depC SHARED depC.cpp)
generate_export_header(depC)
target_link_libraries(depC LINK_PUBLIC depA)
assert_property(depA LINK_INTERFACE_LIBRARIES "")
assert_property(depB LINK_INTERFACE_LIBRARIES "")
assert_property(depC LINK_INTERFACE_LIBRARIES "depA")
add_executable(targetA targetA.cpp)
target_link_libraries(targetA LINK_INTERFACE_LIBRARIES depA depB)
assert_property(targetA LINK_INTERFACE_LIBRARIES "depA;depB")
set_target_properties(targetA PROPERTIES LINK_INTERFACE_LIBRARIES "")
assert_property(targetA LINK_INTERFACE_LIBRARIES "")
Add CMAKE_BUILD_INTERFACE_INCLUDES build-variable. This makes set(CMAKE_BUILD_INTERFACE_INCLUDES ON) add the equivalent of set_property(TARGET tgt APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR};${CMAKE_CURRENT_BINARY_DIR}> ) to every target. If the headers are in CMAKE_CURRENT_SOURCE_DIR, and the generated headers are in CMAKE_CURRENT_BINARY_DIR, this is a convenient way to build a target bar, which depends on foo, just by using target_link_libraries() and adding the INTERFACE_INCLUDE_DIRECTORIES to the INCLUDE_DIRECTORIES of the target being linked. There will be more-convenient porcelain API to consume the property in the future.
2012-11-25 04:15:44 +04:00
add_subdirectory(subdir)
target_link_libraries(targetA subdirlib)
set_property(TARGET targetA APPEND PROPERTY
INCLUDE_DIRECTORIES
$<TARGET_PROPERTY:subdirlib,INTERFACE_INCLUDE_DIRECTORIES>
)
target_link_libraries: Add LINK_(PUBLIC|PRIVATE) options Makes it possible to specify the link dependencies and link interfaces in one command without repetition.
2011-10-07 04:41:37 +04:00
target_link_libraries(targetA depB depC)
assert_property(targetA LINK_INTERFACE_LIBRARIES "")
Make targets depend on the link interface of their dependees.
2012-12-26 13:58:21 +04:00
# Exclude depIfaceOnly from ALL so that it will only be built if something
# depends on it. As it is in the link interface of depB, targetA
# will depend on it. That dependency is what is being tested here.
add_library(depIfaceOnly SHARED EXCLUDE_FROM_ALL depIfaceOnly.cpp)
generate_export_header(depIfaceOnly)
set_property(TARGET depB APPEND PROPERTY LINK_INTERFACE_LIBRARIES depIfaceOnly)
Allow generator expressions in LINK_INTERFACE_LIBRARIES. The Config and IMPORTED_ variants may also contain generator expressions. If 'the implementation is the interface', then the result of evaluating the expressions at generate time is used to populate the IMPORTED_LINK_INTERFACE_LIBRARIES property. 1) In the case of non-static libraries, this is fine because the user still has the option to populate the LINK_INTERFACE_LIBRARIES with generator expressions if that is what is wanted. 2) In the case of static libraries, this prevents a footgun, enforcing that the interface and the implementation are really the same. Otherwise, the LINK_LIBRARIES could contain a generator expression which is evaluated with a different context at build time, and when used as an imported target. That would mean that the result of evaluating the INTERFACE_LINK_LIBRARIES property for a static library would not necessarily be the 'link implementation'. For example: add_library(libone STATIC libone.cpp) add_library(libtwo STATIC libtwo.cpp) add_library(libthree STATIC libthree.cpp) target_link_libraries(libtwo $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>) target_link_libraries(libthree libtwo) If the LINK_LIBRARIES content was simply copied to the IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but executables linking to libthree will not link to libone. 3) As the 'implementation is the interface' concept is to be deprecated in the future anyway, this should be fine.
2013-01-04 16:36:18 +04:00
add_library(depD SHARED depD.cpp)
generate_export_header(depD)
set_property(TARGET depD APPEND PROPERTY
LINK_INTERFACE_LIBRARIES
$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,EXECUTABLE>:depA>
)
add_executable(targetB targetB.cpp)
target_link_libraries(targetB depD)