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.
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.
As INTERFACE_COMPILE_DEFINITIONS are now possible, we can have
situations like this:
add_library(foo ...)
add_library(bar ...)
target_link_libraries(foo bar)
target_compile_definitions(bar INTERFACE SOME_DEF)
The INTERFACE_COMPILE_DEFINITIONS of bar determine how foo should be
compiled, and if they change, foo should be rebuilt.
Additionally, as of commit d1446ca7 (Append the COMPILE_DEFINITIONS
from the Makefile to all targets., 2012-09-17), we don't need to
read definitions from the makefile if we read them from the target,
so also de-duplicate the cached info.
The DependInfo for INTERFACE_INCLUDE_DIRECTORIES is already handled
correctly.
Remove the old "nocwd" behavior that attempts to provide the "--help"
output when no working directory is available. The long help output
scrolls the real error message out of typical terminal sizes. Also
execute as little code as possible when no working directory exists.
Since commit 08cb4fa4 (Process generator expressions in the
INCLUDE_DIRECTORIES property., 2012-09-18), it is possible to use
generator expressions with the include_directories command.
As that command can also have a SYSTEM argument, ensure that the
result of using that argument with generator expressions gives a
sane result.
e48d842 Cache context-independent includes on evaluation.
089fe1c Optimize genex evaluation for includes and defines.
179f495 find_package: Reword <package>_NO_INTERFACES documentation
e7b579b Test workaround of bad interface include directories from depends.
77cecb7 Add includes and compile definitions with target_link_libraries.
0b92602 Add the $<LINKED:...> generator expression.
0fa7f69 Add API to check if we're reading a includes or defines property.
2c3654c Add a way to exclude INTERFACE properties from exported targets.
d4297d5 Export targets to a targets file, not a Config file.
df4d2b2 Make it an error for INSTALL_PREFIX to be evaluated.
7ceeba9 Advance more when preprocessing exported strings.
30268b4 Handle reading empty properties defined by the link interface.
The commit 18a3195a ('Keep track of INCLUDE_DIRECTORIES as a vector
of structs.', 2012-11-19) moved the handling of includes from
cmGeneratorTarget to cmTarget, but in the process introduced this
bug.
link.exe has problems with very very long lines in rsp files too.
Use $in_newline instead of $in variable for rspcontent which
separates the arguments with a newline instead of a simple space
and was specially made for this purpose.
Since commit d46d8df0 (Re-implemented cmGeneratedFileStream to look like a
real stream and replace the destination file atomically, 2004-11-03) our
RenameFile implementation tries to deal with MoveFile not replacing
read-only files. In order to avoid the Get/SetFileAttributes pair we used
stat to test for existence of the destination file. This has a race in
which the destination could be created between the test for existence and
the MoveFile call.
Remove the stat call and use GetFileAttributes to detect whether the file
exists. This shortens the race but does not eliminate it. Use a loop to
try multiple times in case we lose the race. While at it, drop Win9x
support and always use MoveFileEx.
Brad King
Kitware Robot
Stephen Kelly
Patrick Gansterer