2009-07-11 18:10:51 +04:00
|
|
|
cmake_minimum_required (VERSION 2.7.20090711)
|
|
|
|
project(Export C CXX)
|
2008-01-28 16:40:21 +03:00
|
|
|
|
2008-09-05 01:34:25 +04:00
|
|
|
# Pretend that RelWithDebInfo should link to debug libraries to test
|
|
|
|
# the DEBUG_CONFIGURATIONS property.
|
|
|
|
set_property(GLOBAL PROPERTY DEBUG_CONFIGURATIONS Debug RelWithDebInfo)
|
|
|
|
|
2008-01-28 21:37:59 +03:00
|
|
|
add_library(testExe1lib STATIC testExe1lib.c) # not exported
|
2008-01-28 16:40:21 +03:00
|
|
|
add_executable(testExe1 testExe1.c)
|
2008-01-28 21:37:59 +03:00
|
|
|
target_link_libraries(testExe1 testExe1lib)
|
2008-02-06 22:20:36 +03:00
|
|
|
set_property(TARGET testExe1 PROPERTY VERSION 4)
|
2008-01-28 16:40:21 +03:00
|
|
|
|
2008-01-31 01:26:09 +03:00
|
|
|
add_library(testExe2libImp SHARED testExe2libImp.c)
|
2008-02-01 17:57:47 +03:00
|
|
|
set_property(TARGET testExe2libImp PROPERTY LIBRARY_OUTPUT_DIRECTORY impl)
|
2008-01-31 01:26:09 +03:00
|
|
|
add_library(testExe2lib SHARED testExe2lib.c)
|
|
|
|
target_link_libraries(testExe2lib testExe2libImp)
|
|
|
|
set_property(TARGET testExe2lib PROPERTY LINK_INTERFACE_LIBRARIES "")
|
2008-01-28 16:40:21 +03:00
|
|
|
add_executable(testExe2 testExe2.c)
|
|
|
|
set_property(TARGET testExe2 PROPERTY ENABLE_EXPORTS 1)
|
2008-01-31 01:26:09 +03:00
|
|
|
set_property(TARGET testExe2 PROPERTY LINK_INTERFACE_LIBRARIES testExe2lib)
|
2008-01-28 16:40:21 +03:00
|
|
|
|
|
|
|
add_library(testLib1 STATIC testLib1.c)
|
|
|
|
add_library(testLib2 STATIC testLib2.c)
|
|
|
|
target_link_libraries(testLib2 testLib1)
|
|
|
|
|
2011-12-14 20:28:42 +04:00
|
|
|
# Test library with empty link interface. Link it to an implementation
|
|
|
|
# dependency that itself links to dependencies publicly.
|
|
|
|
add_library(testLib3ImpDep SHARED testLib3ImpDep.c)
|
|
|
|
set_property(TARGET testLib3ImpDep PROPERTY LIBRARY_OUTPUT_DIRECTORY impl/dep)
|
2008-01-31 01:26:09 +03:00
|
|
|
add_library(testLib3Imp SHARED testLib3Imp.c)
|
2008-02-01 17:57:47 +03:00
|
|
|
set_property(TARGET testLib3Imp PROPERTY LIBRARY_OUTPUT_DIRECTORY impl)
|
2011-12-14 20:28:42 +04:00
|
|
|
target_link_libraries(testLib3Imp testLib3ImpDep)
|
2008-01-28 16:40:21 +03:00
|
|
|
add_library(testLib3 SHARED testLib3.c)
|
2008-01-31 01:26:09 +03:00
|
|
|
target_link_libraries(testLib3 testLib3Imp)
|
|
|
|
set_property(TARGET testLib3 PROPERTY LINK_INTERFACE_LIBRARIES "")
|
2008-02-06 22:20:36 +03:00
|
|
|
set_property(TARGET testLib3 PROPERTY VERSION 1.2)
|
|
|
|
set_property(TARGET testLib3 PROPERTY SOVERSION 3)
|
2008-01-28 16:40:21 +03:00
|
|
|
|
2009-05-01 17:45:43 +04:00
|
|
|
# Test <ARCHIVE|LIBRARY|RUNTIME>_OUTPUT_NAME[_<CONFIG>] properties.
|
|
|
|
set_property(TARGET testLib3 PROPERTY RUNTIME_OUTPUT_NAME_DEBUG testLib3dll-d)
|
|
|
|
set_property(TARGET testLib3 PROPERTY RUNTIME_OUTPUT_NAME_RELEASE testLib3dll-r)
|
|
|
|
set_property(TARGET testLib3 PROPERTY RUNTIME_OUTPUT_NAME testLib3dll)
|
|
|
|
set_property(TARGET testLib3 PROPERTY LIBRARY_OUTPUT_NAME_DEBUG testLib3lib-d)
|
|
|
|
set_property(TARGET testLib3 PROPERTY LIBRARY_OUTPUT_NAME_RELEASE testLib3lib-r)
|
|
|
|
set_property(TARGET testLib3 PROPERTY LIBRARY_OUTPUT_NAME testLib3lib)
|
|
|
|
set_property(TARGET testLib3 PROPERTY ARCHIVE_OUTPUT_NAME testLib3import)
|
|
|
|
|
2008-01-28 21:06:17 +03:00
|
|
|
add_library(testLib4 SHARED testLib4.c)
|
|
|
|
set_property(TARGET testLib4 PROPERTY FRAMEWORK 1)
|
|
|
|
|
2009-04-09 00:29:04 +04:00
|
|
|
add_library(testLib5 SHARED testLib5.c)
|
|
|
|
|
2009-07-13 17:20:36 +04:00
|
|
|
add_library(testLib6 STATIC testLib6.cxx testLib6c.c)
|
2009-07-11 18:10:51 +04:00
|
|
|
|
2008-08-13 01:27:48 +04:00
|
|
|
# Work-around: Visual Studio 6 does not support per-target object files.
|
|
|
|
set(VS6)
|
|
|
|
if("${CMAKE_GENERATOR}" MATCHES "Visual Studio 6")
|
|
|
|
set(VS6 1)
|
2012-08-13 21:50:14 +04:00
|
|
|
endif()
|
2008-08-13 01:27:48 +04:00
|
|
|
|
2008-08-12 00:23:10 +04:00
|
|
|
# Test using the target_link_libraries command to set the
|
|
|
|
# LINK_INTERFACE_LIBRARIES* properties. We construct two libraries
|
|
|
|
# providing the same two symbols. In each library one of the symbols
|
|
|
|
# will work and the other one will fail to link. The import part of
|
|
|
|
# this test will try to use the symbol corresponding to the
|
|
|
|
# configuration in which it is built. If the proper library is not
|
|
|
|
# used via the link interface the import test will fail to link.
|
|
|
|
add_library(testLib4lib STATIC testLib4lib.c)
|
2008-08-13 01:27:48 +04:00
|
|
|
add_library(testLib4libdbg STATIC testLib4libopt.c testLib4libdbg${VS6}.c)
|
|
|
|
add_library(testLib4libopt STATIC testLib4libdbg.c testLib4libopt${VS6}.c)
|
2008-08-12 00:23:10 +04:00
|
|
|
set_property(TARGET testLib4libdbg PROPERTY COMPILE_DEFINITIONS LIB_DBG)
|
|
|
|
set_property(TARGET testLib4libopt PROPERTY COMPILE_DEFINITIONS LIB_OPT)
|
|
|
|
target_link_libraries(testLib4
|
2008-08-18 18:11:29 +04:00
|
|
|
LINK_INTERFACE_LIBRARIES
|
|
|
|
testLib4lib debug testLib4libdbg optimized testLib4libopt
|
2008-08-12 00:23:10 +04:00
|
|
|
)
|
|
|
|
|
2008-01-28 22:46:16 +03:00
|
|
|
add_executable(testExe3 testExe3.c)
|
|
|
|
set_property(TARGET testExe3 PROPERTY MACOSX_BUNDLE 1)
|
|
|
|
|
2009-09-01 18:38:36 +04:00
|
|
|
# Test cyclic dependencies.
|
|
|
|
add_library(testLibCycleA STATIC
|
|
|
|
testLibCycleA1.c testLibCycleA2.c testLibCycleA3.c)
|
|
|
|
add_library(testLibCycleB STATIC
|
|
|
|
testLibCycleB1.c testLibCycleB2.c testLibCycleB3.c)
|
|
|
|
target_link_libraries(testLibCycleA testLibCycleB)
|
|
|
|
target_link_libraries(testLibCycleB testLibCycleA)
|
|
|
|
set_property(TARGET testLibCycleA PROPERTY LINK_INTERFACE_MULTIPLICITY 3)
|
|
|
|
|
2012-09-23 21:19:55 +04:00
|
|
|
# Test exporting dependent libraries into different exports
|
|
|
|
add_library(testLibRequired testLibRequired.c)
|
|
|
|
add_library(testLibDepends testLibDepends.c)
|
2012-11-05 15:43:28 +04:00
|
|
|
target_link_libraries(testLibDepends LINK_PUBLIC testLibRequired)
|
2012-09-23 21:19:55 +04:00
|
|
|
|
2012-09-23 15:45:17 +04:00
|
|
|
macro(add_include_lib _libName)
|
|
|
|
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/${_libName}.c" "// no content\n")
|
|
|
|
add_library(${_libName} "${CMAKE_CURRENT_BINARY_DIR}/${_libName}.c")
|
|
|
|
file(MAKE_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/${_libName}")
|
|
|
|
set_property(TARGET ${_libName} APPEND PROPERTY
|
2013-01-27 12:43:44 +04:00
|
|
|
INTERFACE_INCLUDE_DIRECTORIES
|
|
|
|
"$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/${_libName}>"
|
|
|
|
"$<INSTALL_INTERFACE:$<INSTALL_PREFIX>/include/${_libName}>"
|
|
|
|
)
|
2012-09-23 15:45:17 +04:00
|
|
|
if (NOT "${ARGV1}" STREQUAL "NO_HEADER")
|
|
|
|
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/${_libName}/${_libName}.h" "// no content\n")
|
2013-01-27 12:43:44 +04:00
|
|
|
install(FILES
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/${_libName}/${_libName}.h"
|
|
|
|
DESTINATION include/${_libName}
|
|
|
|
)
|
2012-09-23 15:45:17 +04:00
|
|
|
endif()
|
|
|
|
endmacro()
|
|
|
|
|
|
|
|
add_include_lib(testLibIncludeRequired1)
|
|
|
|
add_include_lib(testLibIncludeRequired2)
|
|
|
|
add_include_lib(testLibIncludeRequired3 NO_HEADER)
|
|
|
|
# Generate testLibIncludeRequired4 in the testLibIncludeRequired3 directory
|
|
|
|
# with an error. If the includes from testLibIncludeRequired3 appear first,
|
|
|
|
# the error will be hit.
|
|
|
|
# Below, the '3' library appears before the '4' library
|
|
|
|
# but we are testing that the INSTALL_INTERFACE causes it not to be used
|
|
|
|
# at build time.
|
|
|
|
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/testLibIncludeRequired3/testLibIncludeRequired4.h" "#error Should not be included\n")
|
2013-01-27 12:43:44 +04:00
|
|
|
install(FILES
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/testLibIncludeRequired3/testLibIncludeRequired4.h"
|
|
|
|
DESTINATION include/testLibIncludeRequired3
|
|
|
|
)
|
2012-09-23 15:45:17 +04:00
|
|
|
add_include_lib(testLibIncludeRequired4)
|
|
|
|
add_include_lib(testLibIncludeRequired5 NO_HEADER)
|
|
|
|
# Generate testLibIncludeRequired6 in the testLibIncludeRequired5 directory
|
|
|
|
# with an error. If the includes from testLibIncludeRequired5 appear first,
|
|
|
|
# the error will be hit.
|
|
|
|
# Below, the '5' library appears before the '6' library
|
|
|
|
# but we are testing that when the installed IMPORTED target is used, from
|
|
|
|
# the Import side of this unit test, the '6' include from the '5' directory
|
|
|
|
# will not be used because it is in the BUILD_INTERFACE only.
|
|
|
|
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/testLibIncludeRequired5/testLibIncludeRequired6.h" "#error Should not be included\n")
|
2013-01-27 12:43:44 +04:00
|
|
|
install(FILES
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/testLibIncludeRequired5/testLibIncludeRequired6.h"
|
|
|
|
DESTINATION include/testLibIncludeRequired5
|
|
|
|
)
|
2012-09-23 15:45:17 +04:00
|
|
|
add_include_lib(testLibIncludeRequired6)
|
|
|
|
|
|
|
|
set_property(TARGET testLibRequired APPEND PROPERTY
|
|
|
|
INTERFACE_INCLUDE_DIRECTORIES
|
|
|
|
$<TARGET_PROPERTY:testLibIncludeRequired1,INTERFACE_INCLUDE_DIRECTORIES>
|
|
|
|
$<TARGET_PROPERTY:$<1:$<TARGET_NAME:testLibIncludeRequired2>>,INTERFACE_INCLUDE_DIRECTORIES>
|
|
|
|
$<INSTALL_INTERFACE:$<TARGET_PROPERTY:testLibIncludeRequired3,INTERFACE_INCLUDE_DIRECTORIES>>
|
|
|
|
$<BUILD_INTERFACE:$<TARGET_PROPERTY:testLibIncludeRequired4,INTERFACE_INCLUDE_DIRECTORIES>>
|
|
|
|
$<BUILD_INTERFACE:$<TARGET_PROPERTY:testLibIncludeRequired5,INTERFACE_INCLUDE_DIRECTORIES>>
|
|
|
|
$<INSTALL_INTERFACE:$<TARGET_PROPERTY:testLibIncludeRequired6,INTERFACE_INCLUDE_DIRECTORIES>>
|
2013-03-15 00:40:21 +04:00
|
|
|
# The BUILD_INTERFACE entry from above is duplicated below. This is to test that
|
|
|
|
# the INSTALL_INTERFACE entry bound by a BUILD_INTERFACE entry on either side is
|
|
|
|
# preprocessed correctly on install(EXPORT).
|
|
|
|
$<BUILD_INTERFACE:$<TARGET_PROPERTY:testLibIncludeRequired5,INTERFACE_INCLUDE_DIRECTORIES>>
|
2013-01-26 14:04:12 +04:00
|
|
|
# Test that the below is non-fatal
|
2013-02-25 18:26:37 +04:00
|
|
|
$<$<STREQUAL:one,two>:$<TARGET_PROPERTY:not_a_target,INTERFACE_INCLUDE_DIRECTORIES>>
|
2012-09-23 15:45:17 +04:00
|
|
|
)
|
|
|
|
|
|
|
|
set_property(TARGET testLibRequired APPEND PROPERTY
|
|
|
|
INTERFACE_COMPILE_DEFINITIONS
|
|
|
|
testLibRequired_IFACE_DEFINE
|
|
|
|
$<BUILD_INTERFACE:BuildOnly_DEFINE>
|
|
|
|
$<INSTALL_INTERFACE:InstallOnly_DEFINE>
|
|
|
|
)
|
|
|
|
|
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
|
|
|
include(GenerateExportHeader)
|
|
|
|
|
2013-05-17 12:12:02 +04:00
|
|
|
add_subdirectory(renamed)
|
|
|
|
|
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(testSharedLibRequired SHARED testSharedLibRequired.cpp)
|
|
|
|
generate_export_header(testSharedLibRequired)
|
2013-01-12 15:13:19 +04:00
|
|
|
set_property(TARGET testSharedLibRequired
|
|
|
|
PROPERTY
|
|
|
|
INTERFACE_POSITION_INDEPENDENT_CODE ON
|
|
|
|
)
|
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
|
|
|
set_property(TARGET testSharedLibRequired APPEND PROPERTY
|
|
|
|
INCLUDE_DIRECTORIES "${CMAKE_CURRENT_BINARY_DIR}"
|
|
|
|
)
|
2013-03-25 00:18:17 +04:00
|
|
|
install(FILES
|
|
|
|
"${CMAKE_CURRENT_SOURCE_DIR}/testSharedLibRequired.h"
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/testsharedlibrequired_export.h"
|
|
|
|
DESTINATION include/testSharedLibRequired
|
|
|
|
)
|
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
|
|
|
set_property(TARGET testSharedLibRequired APPEND PROPERTY
|
2013-03-25 00:18:17 +04:00
|
|
|
INTERFACE_INCLUDE_DIRECTORIES "$<INSTALL_INTERFACE:$<INSTALL_PREFIX>/include/testSharedLibRequired>"
|
|
|
|
"$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>"
|
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
|
|
|
)
|
2013-01-20 20:09:29 +04:00
|
|
|
set_property(TARGET testSharedLibRequired
|
|
|
|
APPEND PROPERTY
|
|
|
|
COMPATIBLE_INTERFACE_BOOL CUSTOM_PROP
|
|
|
|
)
|
|
|
|
set_property(TARGET testSharedLibRequired
|
|
|
|
PROPERTY
|
|
|
|
INTERFACE_CUSTOM_PROP ON
|
|
|
|
)
|
2013-01-06 16:49:20 +04:00
|
|
|
set_property(TARGET testSharedLibRequired
|
|
|
|
APPEND PROPERTY
|
|
|
|
COMPATIBLE_INTERFACE_STRING CUSTOM_STRING
|
|
|
|
)
|
|
|
|
set_property(TARGET testSharedLibRequired
|
|
|
|
PROPERTY
|
|
|
|
INTERFACE_CUSTOM_STRING testcontent
|
|
|
|
)
|
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(testSharedLibDepends SHARED testSharedLibDepends.cpp)
|
|
|
|
set_property(TARGET testSharedLibDepends APPEND PROPERTY
|
|
|
|
INCLUDE_DIRECTORIES "${CMAKE_CURRENT_BINARY_DIR}"
|
|
|
|
)
|
|
|
|
generate_export_header(testSharedLibDepends)
|
|
|
|
|
|
|
|
set_property(TARGET testSharedLibDepends APPEND PROPERTY
|
|
|
|
INTERFACE_INCLUDE_DIRECTORIES
|
|
|
|
$<TARGET_PROPERTY:testSharedLibRequired,INTERFACE_INCLUDE_DIRECTORIES>
|
|
|
|
)
|
2013-03-25 00:18:17 +04:00
|
|
|
install(FILES
|
|
|
|
"${CMAKE_CURRENT_SOURCE_DIR}/testSharedLibDepends.h"
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/testsharedlibdepends_export.h"
|
|
|
|
DESTINATION include/testSharedLibDepends
|
|
|
|
)
|
|
|
|
set_property(TARGET testSharedLibDepends APPEND PROPERTY
|
|
|
|
INTERFACE_INCLUDE_DIRECTORIES "$<INSTALL_INTERFACE:$<INSTALL_PREFIX>/include/testSharedLibDepends>"
|
|
|
|
"$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>"
|
|
|
|
)
|
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
|
|
|
|
|
|
|
# LINK_PRIVATE because the LINK_INTERFACE_LIBRARIES is specified above.
|
|
|
|
target_link_libraries(testSharedLibDepends LINK_PRIVATE testSharedLibRequired)
|
2013-05-17 12:12:02 +04:00
|
|
|
target_link_libraries(testSharedLibDepends LINK_PUBLIC renamed_on_export)
|
|
|
|
target_link_libraries(testSharedLibDepends LINK_INTERFACE_LIBRARIES
|
|
|
|
$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,EXECUTABLE>:$<TARGET_NAME:testSharedLibRequired>>)
|
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
|
|
|
|
2012-09-23 15:45:17 +04:00
|
|
|
install(TARGETS testLibRequired
|
|
|
|
testLibIncludeRequired1
|
|
|
|
testLibIncludeRequired2
|
|
|
|
testLibIncludeRequired3
|
|
|
|
testLibIncludeRequired4
|
|
|
|
testLibIncludeRequired5
|
|
|
|
testLibIncludeRequired6
|
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
|
|
|
testSharedLibRequired
|
2012-09-23 15:45:17 +04:00
|
|
|
EXPORT RequiredExp DESTINATION lib )
|
2013-01-30 11:24:59 +04:00
|
|
|
install(EXPORT RequiredExp NAMESPACE Req:: FILE testLibRequiredTargets.cmake DESTINATION lib/cmake/testLibRequired)
|
2012-09-23 21:19:55 +04:00
|
|
|
|
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
|
|
|
install(TARGETS testLibDepends testSharedLibDepends EXPORT DependsExp DESTINATION lib )
|
2013-01-30 11:24:59 +04:00
|
|
|
install(EXPORT DependsExp FILE testLibDependsTargets.cmake DESTINATION lib/cmake/testLibDepends)
|
2012-09-23 21:19:55 +04:00
|
|
|
|
2012-11-05 15:43:28 +04:00
|
|
|
file(WRITE
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/testLibRequiredConfig.cmake"
|
|
|
|
"
|
|
|
|
if(\${CMAKE_FIND_PACKAGE_NAME}_FIND_VERSION VERSION_LESS 2.3 AND NOT \${CMAKE_FIND_PACKAGE_NAME}_INTERFACES)
|
|
|
|
set(\${CMAKE_FIND_PACKAGE_NAME}_NO_INTERFACES 1)
|
|
|
|
endif()
|
|
|
|
include(\"\${CMAKE_CURRENT_LIST_DIR}/testLibRequiredTargets.cmake\")
|
|
|
|
set(\${CMAKE_FIND_PACKAGE_NAME}_INCLUDE_DIRS \"${CMAKE_CURRENT_BINARY_DIR}\" \"${CMAKE_CURRENT_SOURCE_DIR}\" )
|
|
|
|
"
|
|
|
|
)
|
|
|
|
|
|
|
|
include(CMakePackageConfigHelpers)
|
|
|
|
write_basic_package_version_file( testLibRequiredConfigVersion.cmake VERSION 2.5 COMPATIBILITY AnyNewerVersion)
|
|
|
|
|
|
|
|
install(FILES
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/testLibRequiredConfig.cmake"
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/testLibRequiredConfigVersion.cmake"
|
|
|
|
DESTINATION lib/cmake/testLibRequired
|
|
|
|
)
|
2012-09-23 21:19:55 +04:00
|
|
|
|
2008-01-28 16:40:21 +03:00
|
|
|
# Install and export from install tree.
|
2008-02-01 17:57:47 +03:00
|
|
|
install(
|
|
|
|
TARGETS
|
2008-01-31 23:45:31 +03:00
|
|
|
testExe1 testLib1 testLib2 testExe2 testLib3 testLib4 testExe3
|
2008-08-12 00:23:10 +04:00
|
|
|
testExe2lib testLib4lib testLib4libdbg testLib4libopt
|
2009-07-11 18:10:51 +04:00
|
|
|
testLib6
|
2009-09-01 18:38:36 +04:00
|
|
|
testLibCycleA testLibCycleB
|
2008-01-28 16:40:21 +03:00
|
|
|
EXPORT exp
|
|
|
|
RUNTIME DESTINATION bin
|
2008-02-06 22:20:36 +03:00
|
|
|
LIBRARY DESTINATION lib NAMELINK_SKIP
|
2008-01-28 16:40:21 +03:00
|
|
|
ARCHIVE DESTINATION lib
|
2008-01-28 21:06:17 +03:00
|
|
|
FRAMEWORK DESTINATION Frameworks
|
2008-01-28 22:46:16 +03:00
|
|
|
BUNDLE DESTINATION Applications
|
2008-01-28 16:40:21 +03:00
|
|
|
)
|
2008-02-01 21:08:12 +03:00
|
|
|
install(
|
|
|
|
TARGETS
|
|
|
|
testExe2libImp testLib3Imp
|
|
|
|
EXPORT exp
|
|
|
|
RUNTIME DESTINATION bin
|
|
|
|
LIBRARY DESTINATION lib/impl
|
|
|
|
ARCHIVE DESTINATION lib/impl
|
|
|
|
)
|
2011-12-14 20:28:42 +04:00
|
|
|
install(
|
|
|
|
TARGETS
|
|
|
|
testLib3ImpDep
|
|
|
|
EXPORT exp
|
|
|
|
RUNTIME DESTINATION bin
|
|
|
|
LIBRARY DESTINATION lib/impl/dep
|
|
|
|
ARCHIVE DESTINATION lib/impl/dep
|
|
|
|
)
|
2009-04-09 00:29:04 +04:00
|
|
|
install(
|
|
|
|
TARGETS testLib5
|
|
|
|
EXPORT exp
|
|
|
|
# Leave out RUNTIME DESTINATION to test implib-only export.
|
|
|
|
LIBRARY DESTINATION lib
|
|
|
|
ARCHIVE DESTINATION lib
|
|
|
|
)
|
2008-01-28 16:40:21 +03:00
|
|
|
install(EXPORT exp NAMESPACE exp_ DESTINATION lib/exp)
|
|
|
|
|
2009-04-09 00:29:04 +04:00
|
|
|
# Install testLib5.dll outside the export.
|
|
|
|
if(WIN32)
|
|
|
|
install(TARGETS testLib5 RUNTIME DESTINATION bin)
|
2012-08-13 21:50:14 +04:00
|
|
|
endif()
|
2009-04-09 00:29:04 +04:00
|
|
|
|
2013-03-20 00:40:06 +04:00
|
|
|
add_subdirectory(sublib) # For CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE test.
|
2013-01-12 15:11:29 +04:00
|
|
|
|
2008-01-28 16:40:21 +03:00
|
|
|
# Export from build tree.
|
2008-01-31 01:26:09 +03:00
|
|
|
export(TARGETS testExe1 testLib1 testLib2 testLib3
|
2013-01-12 15:11:29 +04:00
|
|
|
testExe2libImp testLib3Imp testLib3ImpDep subdirlib
|
2013-05-17 12:12:02 +04:00
|
|
|
testSharedLibRequired testSharedLibDepends renamed_on_export
|
2008-01-28 16:40:21 +03:00
|
|
|
NAMESPACE bld_
|
|
|
|
FILE ExportBuildTree.cmake
|
|
|
|
)
|
2009-07-11 18:10:51 +04:00
|
|
|
export(TARGETS testExe2 testLib4 testLib5 testLib6 testExe3 testExe2lib
|
2008-08-12 00:23:10 +04:00
|
|
|
testLib4lib testLib4libdbg testLib4libopt
|
2009-09-01 18:38:36 +04:00
|
|
|
testLibCycleA testLibCycleB
|
2008-01-28 21:21:42 +03:00
|
|
|
NAMESPACE bld_
|
|
|
|
APPEND FILE ExportBuildTree.cmake
|
|
|
|
)
|