| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This tests whether the parameter is a usable target.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| | |
fc61a7a Add the target_compile_definitions command.
8a37ebe Add the target_include_directories command.
|
| | |
| |
| |
| | |
This is a convenience API to populate the corresponding properties.
|
| | |
| |
| |
| | |
This is a convenience API to populate the corresponding properties.
|
| |\ \
| | |
| | |
| | |
| | | |
9cfe4f1 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.
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
7653862 Add LINK_LIBRARIES property for direct target link dependencies
40cf3fb Make linking APIs aware of 'head' target
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
b6346f2 Tests: Fix warning about unused variable
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Resolve this warning:
".../Tests/CMakeCommands/target_link_libraries/depB.cpp", line 8: warning:
variable "a" was declared but never referenced
DepA a;
^
|
| |/ |
|
| |
|
|
|
|
|
| |
The CMakeCommands.build_command test performs output/error checking
so move it over to RunCMake to re-use the generalized infrastrucure.
This is the only test left using Tests/CMakeCommands/CMakeLists.txt
so remove it.
|
| | |
|
| |
|
|
|
| |
Verify that the command produces a FATAL_ERROR if and only if the
missing package is REQUIRED.
|
| |
|
|
|
|
|
|
| |
Add a "CMakeCommands.find_package" test to run CMake on a bunch of cases
in which find_package fails. Check that the process return code and
warning/error messages are as expected. Record expected test output in
corresponding files for reference by the check. These files will also
serve as a reference for the message text in each case.
|
| |
|
|
|
| |
Generalize the build_command test framework as a macro to add the
test. Process the CMakeCommands subdirectory explicitly.
|
| | |
|
| |
|
|
|
| |
Makes it possible to specify the link dependencies and link
interfaces in one command without repetition.
|
|
|
running -D dashboards from the command line and running ctest_configure, ctest_build and ctest_test commands in -S scripts. Also, allow a script to change it by setting the CTEST_CONFIGURATION_TYPE variable: allows for multiple configuration build/test cycles within one script. Add a new signature for the cmake command build_command that accepts CONFIGURATION as one argument. The original build_command signature is still there, but now marked as deprecated in the documentation. Of course... also add CTestConfig tests to verify that -C is honored for -D dashboards and -S scripts.
|
