| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Make a C executable instead of attempting to make a C++ static
library (and not really succeeding). This was introduced in
commit 894f52f3 (Handle INTERFACE properties transitively for
includes and defines., 2012-09-23).
|
| |
|
|
|
| |
Contextually, the behavior is as if the properties content from another
target is included in the string and then the result is evaluated.
|
| |
|
|
|
|
|
| |
The test exports two libraries into two separate exports,
and then include()s the generated export files. This must not fail.
Alex
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Add the function cmake_expand_imported_targets() to expand imported
targets in a list of libraries into their on-disk file names for a
particular configuration. Adapt the implementation from KDE's
HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES which has been in
use for over 2 years. Call the function from all the Check*.cmake
macros to handle imported targets named in CMAKE_REQUIRED_LIBRARIES.
Alex
|
| |
|
|
|
|
|
| |
Imported targets do not themselves build, but we can follow dependencies
through them to find real targets. This allows imported targets to
depend on custom targets that provide the underlying files at build
time.
|
| |
|
|
|
|
|
| |
Imported targets do not themselves build, but we can follow dependencies
through them to find real targets. This allows imported targets to
depend on custom targets that provide the underlying files at build
time.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
As of CMake 2.6 this variable is not defined, and the ANSI flags for the
HP compiler are simply hard-coded in the default C flags.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This tests linking to an imported target that is not visible but is a
transitive dependency of a target that is visible. See issue #8843.
|
| |
|
|
|
|
| |
Create a DEBUG_CONFIGURATIONS global property as a way for projects to
specify which configuration names are considered to be 'debug'
configurations.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
- 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
|
| | |
|
| |
|
