| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Refactoring in commit 6ed9c7e0 (cmState: Host buildsystem properties for
directories, 2015-07-18) broke include_directories(BEFORE). Fix it and
add a test case.
|
| |
|
|
|
|
|
| |
Fix test cases whose behavior differs when their source or build tree is
under CMAKE_INSTALL_PREFIX by setting an install prefix under the build
tree. Otherwise they may fail when run under the default install prefix
(e.g. /usr/local).
|
| |
|
|
|
|
|
|
|
| |
The moved tests are related to paths in INTERFACE_INCLUDE_DIRECTORIES
in general, and when exporting, and covering cases of the install
location being within the build or source prefix etc. Other build
properties containing paths should have similar tests, so this
allows some parameterization while keeping the preparation of the
various directory structures.
|
| |
|
|
|
| |
Drop use of RunCMake_TEST_FILE and pass the test file in through a
definition in RunCMake_TEST_OPTIONS.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Allow directories in the source tree or build tree only if the
install tree is a subdirectory of the source tree or build tree,
as appropriate.
Re-use the test files in the RunCMake.include_directories test
to run in multiple scenarios. Bump the required CMake version
in the test to 3.0 to ensure that the new policy warnings are
emitted correctly.
|
| |
|
|
| |
Test that no warning or error diagnostic is issued for 'good code'.
|
| | |
|
| |
|
|
| |
Configuration sensitive expressions are not permitted.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit 650e61f8 (Add a convenient way to add the includes install
dir to the INTERFACE., 2013-01-05) introduced an error case for
using the install(TARGETS) command with specified INCLUDES DESTINATION,
but no specified EXPORT set.
It is convenient to use a variable to set the various destinations
for different outputs (as KDE does), and some targets such as
executables are installed but not exported. This was triggering
the error case, but as it is a common case, remove the error.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Add policy CMP0021 to preserve existing behavior in projects expecting
it from earlier CMake versions.
|
| |
|
|
|
|
|
|
|
| |
We can do this check only if the TargetName is non-empty, which means
that we're evaluating INTERFACE_INCLUDE_DIRECTORIES from a linked
dependency which was set using target_link_libraries.
It is possible to have relative paths in INCLUDE_DIRECTORIES already
in CMake 2.8.10.2, so that part will require a policy to fix.
|
| |
|
|
|
|
|
|
|
|
| |
It is considered an error if the INTERFACE_INCLUDE_DIRECTORIES contains
a directory which does not exist, which indicates a programmer error
by the upstream, or a packaging error.
One of the RunCMake.CompatibleInterface tests also needs to be updated
due to this change. Non-existant includes were used in the test, but
are not needed.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Setting include directories or compile definitions on a target created
with add_custom_target does not make sense.
|
| | |
|
|
|
This fixes a regression introduced in commit 290e92ad (Move
GetIncludeDirectories to cmGeneratorTarget, 2012-09-16) which loops over
cmGeneratorTargets before they get created, so the container is empty.
|
