| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This generator has been deprecated since CMake 3.3. Remove it.
Update documentation, modules, and tests to drop content specific
to this generator.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The target_link_libraries command records the PRIVATE dependencies of a
STATIC library in INTERFACE_LINK_LIBRARIES as "$<LINK_ONLY:dep>". This
hides the target name from export namespacing logic inside a generator
expression. When user-written generator expressions reference a target
name they must put it inside a "$<TARGET_NAME:dep>" expression to allow
the export logic to rename the target. In the case that the private
dependency is not already a generator expression, target_link_libraries
must use "$<LINK_ONLY:$<TARGET_NAME:dep>>" to allow the export logic to
rename the target.
Reported-by: Tamás Kenéz <tamas.kenez@gmail.com>
|
| |
|
|
|
|
| |
Use cmake_policy(PUSH/POP) to isolate CMP0022 policy changes.
|
|
|
|
|
| |
Teach install(DIRECTORY) to support generator expressions in the list
of directories, much like install(FILES) already supports.
|
|\
| |
| |
| |
| | |
4eb77a1c Tests: Use C-Style comments in C sources and headers
|
| |
| |
| |
| |
| | |
Not all C compilers tolerate C++-style comments in C code, so do not use
them in our tests.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 899458ab (Tests: Cover NO_SONAME property for SHARED libraries,
2015-08-20) introduced a few new ExportImport tests, and the
check_lib_{no}soname.cmake scripts that parse readelf(1)'s output.
Make the regular expression matching the SONAME line output by readelf
less strict, as the output format varies across implementations: GNU
binutils' readelf is the only one to write each ELF header within
parentheses (which the previous regular expression expected). The new
tests were thus failing when either Fedora's elfutils (eu-readelf) or
elftoolchain's readelf (present on recent FreeBSD versions) were being
used, as they both list the headers without parentheses.
The same issue also affected Tests/Plugin's check_mod_soname.cmake, so
fix that one as well -- the only reason the test was not failing is that
it tested that the regular expression did not match, which was always
the case with a non-binutils readelf.
|
|
|
|
|
|
|
|
| |
This property was added by commit v2.8.9~204^2~2 (Support building
shared libraries or modules without soname, 2012-04-22). A test for
using the property on MODULE libraries was added by commit
v2.8.9~204^2~1 (Test NO_SONAME property, 2012-04-23). Add such a test
for SHARED libraries too.
|
|
|
|
|
|
|
| |
If {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY is set with a genex then
do not add the per-config subdirectory on multi-config generators.
This will allow projects to use $<CONFIG> to place the per-config
part of the directory path somewhere other than the end.
|
| |
|
|
|
|
|
|
|
|
| |
When writing export files, correctly encode property values that contain
characters special to the CMake language parser. We must ensure that
they parse correctly when loaded on the consuming side.
Reported-by: Dan Liew <dan@su-root.co.uk>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The iface_test_bld gets the excludedFromAll include directory with
"-isystem" because it is added indirectly through an imported target.
On AIX with GCC the -isystem flag causes sources to be preprocessed as:
# 3 "/.../excludedFromAll.h" 2 3 4
The flags after the file name are documented here:
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html
and the "4" flag says that following content is extern "C". This
causes the excludedFromAll function to be declared as a C symbol
and not mangled for C++, which fails to link later because the
symbol is really provided as C++.
Work around this by setting the NO_SYSTEM_FROM_IMPORTED target property
on iface_test_bld. Somehow iface_test_exp does not end up with -isystem
so we do not need this workaround for that target.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow per-config destinations for targets in EXPORT sets.
Using multiple install(TARGETS) with separate CONFIGURATIONS is
rejected as a target appearing more than once in an export set.
Now instead one can write
install(TARGETS foo EXPORT exp DESTINATION lib/$<CONFIG>)
to get a single logical membership of the target in the export set
while still having a per-config destination.
|
|
|
|
|
|
| |
Use the same rules for paths in source and binary dirs in
installed INTERFACE_SOURCES as are used for
INTERFACE_INCLUDE_DIRECTORIES.
|
|
|
|
|
| |
Extend the ExportImport test to try using an imported library with
try_run.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When install(EXPORT) is given an absolute destination we cannot compute
the install prefix relative to the installed export file location.
Previously we disallowed installation of targets in such exports with a
relative destination, but did not enforce this for target property
values besides the location of the main target file. This could lead to
broken installations when the EXPORT is installed to an absolute path
but usage requirements are specified relative to the install prefix.
Since an EXPORT installed to an absolute destination cannot be relocated
we can just hard-code the value of CMAKE_INSTALL_PREFIX as the base for
relative paths. This will allow absolute install(EXPORT) destinations
to work with relative destinations for targets and usage requirements.
Extend the ExportImport test with a case covering this behavior.
|
|
|
|
|
| |
Propagate CMAKE_GENERATOR_PLATFORM through the test hierarchy so that all
tests can build with the selected generator platform, if any.
|
|
|
|
|
|
|
|
|
|
|
| |
Add properties and variables corresponding to CXX equivalents.
Add features for c_function_prototypes (C90), c_restrict (C99),
c_variadic_macros (C99) and c_static_assert (C11). This feature
set can be extended later.
Add a <PREFIX>_RESTRICT symbol define to WriteCompilerDetectionHeader
to conditionally represent the c_restrict feature.
|
| |
|
| |
|
|
|
|
|
|
|
| |
In the ExportImport, Fortran, and MacRuntimePath tests the
CMAKE_TEST_MAKEPROGRAM variable is used to pass an explicit request for
a CMAKE_MAKE_PROGRAM value to be used when building the inner projects.
Rename these use cases to CMake_TEST_NESTED_MAKE_PROGRAM.
|
|
|
|
|
|
|
|
| |
Teach the install(FILES) and install(PROGRAMS) commands to evaluate
generator expressions in the list of files.
Extend the ExportImport test to cover installation cases involving
generator expressions.
|
|
|
|
|
| |
INTERFACE_LIBRARY targets have no corresponding files, and so
require no DESTINATION to install anything to.
|
|
|
|
|
|
| |
Teach the export command to handle export sets defined by invocations
of install(TARGETS ... EXPORT foo). This makes maintenance of targets
exported to both the build tree and install tree trivial.
|
|\
| |
| |
| |
| | |
ef7c11e Tests: Fix standalone build of tests with nested projects
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit fd6076d0 (Tests: Pass CMAKE_MAKE_PROGRAM instead of
--build-makeprogram, 2013-11-15) the ExportImport, Fortran, and
MacRuntimePath tests use the value of CMAKE_TEST_MAKEPROGRAM as the
CMAKE_MAKE_PROGRAM for their nested projects configurations.
Teach these tests to initialize CMAKE_TEST_MAKEPROGRAM when it is
not provided, such as when building the tests manually.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Code such as
target_include_directories(foo INTERFACE
$<INSTALL_INTERFACE:include$<FOO>>
)
should be treated as a relative directory, despite the genex, after
the INSTALL_INTERFACE is stripped away.
Previously, this would generate a relative directory on export, which
would be an error on import, so no policy is needed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Code such as
install(TARGETS ...
INCLUDES DESTINATION $<INSTALL_INTERFACE:include>
)
should behave as if the INSTALL_INTERFACE wrapper were not present.
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
In code such as
install(TARGETS ...
INCLUDES DESTINATION $<FOO>include
)
the generator expressions are evaluated at generate-time. Delay
determining whether each entry is a relative path until after
the generator expressions are evaluated. Such relative paths
are based relative to the CMAKE_INSTALL_PREFIX.
|
|
|
|
|
|
|
|
|
|
| |
Pass the CMAKE_TEST_MAKEPROGRAM, if any, to each test at CMake time in
the CMAKE_MAKE_PROGRAM cache entry. Pass the CMAKE_TEST_MAKEPROGRAM
into the ExportImport, Fortran, and MacRuntimePath tests so that they
may do the same for the nested project configurations.
Now "ctest --build-and-test" can get the make program from the test
build tree cache, so drop the explicit --build-makeprogram.
|
|
|
|
|
|
|
|
| |
Introduce a policy to control the behavior.
The AliasTargets unit test already tests that using a
double-semicolon in the name is not an error. Change the ExportImport
test to use a namespace with a double-semicolon too.
|
|\
| |
| |
| |
| |
| |
| | |
ce0c303 install: Teach EXPORT option to handle INTERFACE_LIBRARY targets
435c912 export: Add support for INTERFACE_LIBRARY targets
fe73226 Add the INTERFACE_LIBRARY target type.
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| | |
a63fcbc Always consider includes from IMPORTED targets to be SYSTEM.
|
| |
| |
| |
| |
| |
| |
| | |
Introduce a target property to control this behavior variable
to set the default value for the target property.
This does not affect try_compile runs.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Re-insert the semicolon which was removed during splitting.
Commit d777b8e7 (Genex: Allow relative paths in INSTALL_INTERFACE.,
2013-07-25) introduced the prefixItems method to allow relative paths
in the argument of the INSTALL_INTERFACE expression. That method was
buggy in that it did not re-introduce the semicolon separator in
the result.
This bug also affects paths which are already absolute in user code.
|
| |
|
| |
|
|
|
|
| |
Configuration sensitive expressions are not permitted.
|
|
|
|
|
|
|
|
| |
The new feature of install(TARGETS ... INCLUDES DESTINATION) introduced
in commit 650e61f8 (Add a convenient way to add the includes install
dir to the INTERFACE., 2013-01-05) introduced this crash. If the
new feature is used with a target which has no
INTERFACE_INCLUDE_DIRECTORIES, a segfault occurred.
|
|\
| |
| |
| |
| | |
d777b8e Genex: Allow relative paths in INSTALL_INTERFACE.
|
| |
| |
| |
| |
| |
| |
| | |
These paths can be prepended with the ${_IMPORT_PREFIX} generated
in the export file.
Such relative paths were previously an error.
|
|\ \
| |/
| |
| |
| | |
650e61f Add a convenient way to add the includes install dir to the INTERFACE.
|
| |
| |
| |
| |
| |
| |
| | |
Export the INCLUDES DESTINATION without appending to the
INTERFACE_INCLUDE_DIRECTORIES of the target itself. That way, a target
can be exported multiple times with different INCLUDES DESTINATION
without unintended cross-pollution of export sets.
|
| | |
|
|\ \
| |/
|/|
| |
| | |
295a42c Fix ExportImport test cmp0022NEW build on Watcom
|