| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The test uses generate_export_header(cmp0022OLD ...) to generate the
cmp0022_export.h header used by both cmp0022OLD and cmp0022NEW. In
the latter the _EXPORTS symbol does not match what the header expects
so the library does not export anything. The Watcom linker does not
like to create shared libraries that do not export any symbols.
Fix this by setting the DEFINE_SYMBOL property on cmp0022NEW to match
that of cmp0022OLD as the header expects.
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| | |
3e30d9e TLL: Don't populate old link interface if CMP0022 is NEW.
574fec9 Export: Generate INTERFACE_LINK_LIBRARIES property on targets.
d0a76ea Introduce the INTERFACE_LINK_LIBRARIES property.
ddde61c Introduce the LINK_ONLY generator expression.
5aa9731 GenexEval: Add abstracted access to link interface for a target.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This property is generated only for targets which have recorded
policy CMP0022 as NEW, and a compatibility mode is added to
additionally export the old interfaces in that case too.
If the old interfaces are not exported, the generated export files
require CMake 2.8.12. Because the unit tests use a version which
is not yet called 2.8.12, temporarily require a lower version.
|
|\ \
| |/
|/|
| |
| |
| | |
4f7ceb5 Test non-IMPORTED libraries in the INTERFACE of IMPORTED libraries.
3405351 Add entire link interface transitive closure as target depends.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a non-IMPORTED library is added to the INTERFACE_LINK_LIBRARIES
of a IMPORTED target, the non-IMPORTED target needs to become a
target dependency and link dependency of the consuming target.
This is already the case since commit 30962029 (Make targets depend
on the link interface of their dependees, 2012-12-26), and fixed in
the parent commit, so test that it works.
|
|/
|
|
|
| |
This was missing from commit 80ca9c4b (Add COMPILE_OPTIONS target
property., 2013-05-16).
|
|
|
|
|
|
| |
This allows for example, the buildsystem to use names like 'boost_any'
instead of the overly generic 'any', and still be able to generate
IMPORTED targets called 'boost::any'.
|
|
|
|
|
|
|
|
|
|
| |
Check that source and binary directories are not part of the
INTERFACE_INCLUDE_DIRECTORIES for installed IMPORTED targets.
This is limited to directories which do not contain generator
expressions to evaluate. Such paths can only be checked at time
of use of the imported target, which will be done in a follow up
patch.
|
|
|
|
|
|
|
|
|
| |
Rename the variable added by commit 9ce1b9ef (Add
CMAKE_BUILD_INTERFACE_INCLUDES build-variable, 2012-11-25) to
CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE to be more consistent with the
existing CMAKE_INCLUDE_CURRENT_DIR variable.
Suggested-by: Alex Neundorf <neundorf@kde.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| | |
cbf0756 Revert "Add the TARGET_DEFINED generator expression"
21a342c Remove use of TARGET_DEFINED from the target_link_libraries test.
47b8d32 Remove use of TARGET_DEFINED from the ExportImport test.
2e39d21 Remove use of TARGET_DEFINED from target_include_directories test.
|
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
|
| |
Imported targets are re-exported so that they can be used by the
try_compile generated code with target_link_libraries.
This makes the use of the cmake_expand_imported_targets macro
obsolete. The macro is not able to expand the generator expressions
which may appear in the IMPORTED_LINK_INTERFACE_LIBRARIES content.
Instead it just sees them as 'not a target'.
|
|
|
|
|
|
|
|
| |
This reverts commit 2c3654c3de718fe822f8960063373774fc019494.
The removal of some tests added in commit 77cecb77 (Add includes and compile
definitions with target_link_libraries., 2012-11-05) are also squashed
into this commit.
|
|
|
|
|
| |
Propagate CMAKE_GENERATOR_TOOLSET through the test hierarchy so that all
tests can build with the selected generator toolset, if any.
|
|\
| |
| |
| | |
We need the latest Tests/CMakeLists.txt so we can refactor all tests.
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
7bf490e Make subclasses responsible for joining content.
f6b16d4 Don't allow targets args in the new target commands.
b3a7e19 Make the Property name protected so that subclasses can use it.
|