This is a partial revert of commit 77cecb77 (Add includes and compile
definitions with target_link_libraries., 2012-11-05).
As the interface includes and defines are now determined by the link
closure, there is no need to populate the corresponding properties
explicitly.
After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a
generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of
its link interface dependencies.
That means that code such as this will result in the 'user' target
using /bar/include and /foo/include:
add_library(foo ...)
target_include_directories(foo INTERFACE /foo/include)
add_library(bar ...)
target_include_directories(bar INTERFACE /bar/include)
target_link_libraries(bar LINK_PUBLIC foo)
add_executable(user ...)
target_include_directories(user PRIVATE
$<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>)
Also process the interface include directories from direct link
dependencies for in-build targets.
The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The
include directories related code is currently more complex because
we also need to store a backtrace at configure-time for the purpose
of debugging includes. The compile definitions related code will use
the same pattern in the future.
This is not a change in behavior, as existing code has the same effect,
but that existing code will be removed in follow-up commits.
Since commit 34c882a9 (Allow VS 7 project Rebuild and Solution Rebuild to
work, 2007-11-10) we use a "CMakeFiles/generated.stamp" and some
associated files in the build tree to avoid re-running CMake when the
inputs have not changed but VS has cleaned the outputs it knows about.
When we do not really need to re-run we restore the generated.stamp file.
The non-re-run case can happen in multiple targets in parallel in VS >= 10
so we must restore the file atomically to avoid races. Write the stamp
file to a random temporary name and then atomically rename it to the real
stamp file.
ba48e63 Generate config-specific interface link libraries propeties.
deb51a7 Remove unused forward declarations.
9712362 Don't allow utility or global targets in the LINKED expression.
faa927e Make sure INTERFACE properties work with OBJECT libraries.
510fdcb Whitelist target types in target_{include_directories,compile_definitions}
4de7178 Ensure that the build interface includes have been added.
df74bc3 Only append build interface include dirs to particular targets.
d4e5c67 Don't keep track of content determined by target property values.
1fb545a Move a special case for PIC from the genex to the cmTarget code.
57175d5 Only use early evaluation termination for transitive properties.
4cf161a Fix determination of evaluating link libraries.
3a298c0 Fix generation of COMPILE_DEFINITIONS in DependInfo.cmake.
655e98b Ensure type specific compatible interface properties do not intersect.
46e2896 The COMPATIBLE_INTERFACE does not affect the target it is set on.
5f926a5 Test printing origin of include dirs from tll().
7c0ec75 De-duplicate validation of genex target names.
...
Since commit fd33bf93 (fix for bug 6102, allow users to change the
compiler, 2007-12-13) we keep an internal ;-list of language compiler
variable and value pairs. Preserve empty values on expansion to ensure
that the key/value pairing remains consistent.
This is needed in the case that Automoc is used, as that calls
GetIncludeDirectories, which may cache the resulting include dirs
too early in the generate step.
Also, because the automoc step is so early, we can't cache the
include directories at that point. At that point the build interface
of all dependencies are not populated yet, so we'd be caching the
includes before appending the build interface. Only start caching
when we're definitely generating the buildsystem. At that point, the
includes should be stable.
We still need to invoke AppendBuildInterfaceIncludes
in the GlobalGenerator because the build interface includes affect
mostly the dependencies of targets (such as the automoc targets),
rather than the targets themselves, so the build interface needs
to be appended for all targets before generation is done.
All ctest --build-and-test invocations require the options
--build-generator ${CMAKE_GENERATOR}
--build-makeprogram ${CMAKE_TEST_MAKEPROGRAM}
to be passed and have consistent values, except for a few special cases.
Collect the generator options in a variable instead of repeating the
options everywhere explicitly.
When the CMAKE_GENERATOR option is given to ExternalProject_Add, look
also for option CMAKE_GENERATOR_TOOLSET to select the value of the cmake
"-T" command-line flag. When no CMAKE_GENERATOR option is given
explicitly then use the current project's CMAKE_GENERATOR_TOOLSET (since
we already use its CMAKE_GENERATOR).
The ctest_configure command already reads the CTEST_CMAKE_GENERATOR
variable to get the value for the cmake -G option. Read new variable
CTEST_CMAKE_GENERATOR_TOOLSET for -T.
The "ctest --build-and-test" mode already has "--build-generator" to
specify the -G option to CMake. Add a "--build-generator-toolset" option
to specify the -T value.
Implement generator toolset selection (cmake -T) for VS >= 10 by setting
the PlatformToolset. Extend the RunCMake.GeneratorToolset test case to
verify CMAKE_GENERATOR_TOOLSET when the generator supports -T.
Since commit 485a940e (VS: Simplify MSVC version reporting, 2012-08-23)
all MSVC version information is detected during the compiler id step
from the actual compiler invoked by generated build systems rather than
hard-coded in VS generators. Therefore we can set the PlatformToolset
in VS >= 10 project files and support toolsets from other VS versions.
Reject the option by default. It will be implemented on a per-generator
basis. Pass the setting into try_compile project generation. Add cache
entry CMAKE_GENERATOR_TOOLSET and associated variable documentation to
hold the value persistently.
Add a RunCMake.GeneratorToolset test to cover basic "-T" option cases.
Verify that CMAKE_GENERATOR_TOOLSET is empty without -T, that -T is
rejected when the generator doesn't support it, and that two -T options
are always rejected.
This tracking was added during the development of commit 042ecf04
(Add API to calculate link-interface-dependent bool properties
or error., 2013-01-06), but was never used.
It was not necessary to use the content because what is really
useful in that logic is to determine if a property has been implied
to be null by appearing in a LINK_LIBRARIES genex.
I think the motivating usecase for developing the feature of
keeping track of the targets relevant to a property was that I
thought it would make it possible to allow requiring granular
compatibility of interface properties only for targets which
depended on the interface property. Eg:
add_library(foo ...)
add_library(bar ...)
add_executable(user ...)
# Read the INTERFACE_POSITION_INDEPENDENT_CODE from bar, but not
# from foo:
target_link_libraries(user foo $<$<TARGET_PROPERTY:POSTITION_INDEPENDENT_CODE>:bar>)
This obviously doesn't make sense. We require that INTERFACE
properties are consistent across all linked targets instead.
We need to make sure expressions which evaluate TARGET_PROPERTY:TYPE
multiple times for example get the correct result each time, and
not an empty string instead.
Stephen Kelly
Kitware Robot
Brad King
Alex Neundorf
Eric NOULARD