We can't find both preprocessing expressions at once, because then
the BUILD_INTERFACE will always be favored if both are present, even
if INSTALL_INTERFACE appears first.
This was affecting the behavior of install(EXPORT) because the
INTERFACE_INCLUDE_DIRECTORIES contained entries like
/foo/include;$<INSTALL_INTERFACE:/bar/include>
As the INSTALL_INTERFACE always evaluates to '0', it always needs
to be preprocessed properly.
Update the unit test introduced in commit 5daaa5c4 (Fix TARGET_PROPERTY
target extractions., 2013-01-26) to not use the expression, but still
test the appropriate code.
This establishes that linking is used to propagate usage-requirements
between targets in CMake code. The use of the target_link_libraries
command as the API for this is chosen because introducing a new command
would introduce confusion due to multiple commands which differ only in
a subtle way.
We need to make sure we can export targets which have content such
as $<0:$<TARGET_PROPERTY:not_a_target,INTERFACE_INCLUDE_DIRECTORIES>
That means making not finding a target non-fatal here.
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.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
In cmComputeLinkDepends we compute the transitive closure of private
shared library dependencies. When a shared library is added to this
closure we must follow all of its dependencies whether they are private
or public. Previously we only followed the private dependencies. Fix
the implementation to follow the public dependencies too. Also extend
the ExportImport test to cover this case.
We test that LINK_INTERFACE_MULTIPLICITY propagates through export() and
install(EXPORT) into dependent projects. A simple cycle of two archives
that need to be scanned three times ensures that the importing project
uses the multiplicity correctly.
This extends the ExportImport test. The Export project creates a C++
static library and exports it. Then the Import project links the
library into a C executable. On most platforms the executable will link
only if the C++ linker is chosen correctly.
This creates target properties ARCHIVE_OUTPUT_NAME, LIBRARY_OUTPUT_NAME,
and RUNTIME_OUTPUT_NAME, and per-configuration equivalent properties
ARCHIVE_OUTPUT_NAME_<CONFIG>, LIBRARY_OUTPUT_NAME_<CONFIG>, and
RUNTIME_OUTPUT_NAME_<CONFIG>. They allow specification of target output
file names on a per-type, per-configuration basis. For example, a .dll
and its .lib import library may have different base names.
For consistency and to avoid ambiguity, the old <CONFIG>_OUTPUT_NAME
property is now also available as OUTPUT_NAME_<CONFIG>.
See issue #8920.
Linking to a Windows shared library (.dll) requires only its import
library (.lib). This teaches CMake to recognize SHARED IMPORTED library
targets that set only IMPORTED_IMPLIB and not IMPORTED_LOCATION.
Rename the recently added INTERFACE mode of the target_link_libraries()
command to LINK_INTERFACE_LIBRARIES. This makes it much more distinct
from a normal call to the command, and clearly states its connection to
the property of the same name. Also require the option to appear
immediately after the target name to make it a mode rather than an
option.
- Motivation:
- It depended on the order of installation
- It supported only a single destination for each target
- It created directory portions of an install name without user request
- Updated ExportImport test to install targets in an order that expoed
this bug
- Split IMPORTED_LINK_LIBRARIES into two parts:
IMPORTED_LINK_INTERFACE_LIBRARIES
IMPORTED_LINK_DEPENDENT_LIBRARIES
- Add CMAKE_DEPENDENT_SHARED_LIBRARY_MODE to select behavior
- Set mode to LINK for Darwin (fixes universal binary problem)
- Update ExportImport test to account for changes
- Imported bundles have the MACOSX_BUNDLE property set
- Added cmTarget::IsAppBundleOnApple method to simplify checks
- Document BUNDLE keyword in INSTALL command
- Updated IMPORTED_LOCATION property documentation for bundles
- Updated ExportImport test to test bundles
Stephen Kelly
Brad King
Alex Neundorf
Kitware Robot
Ken Martin