Evaluate and lookup the target name only once per TargetPropertyEntry
instead of repeating it for each include directory entry. Use a local
checkCMP0027 variable to record whether the policy should be checked.
Evaluate the target name as a generator expression only if it looks like
one. Lookup the target by name only after evaluation of generator
expressions.
Implementation of CMP0027 OLD behavior needs to know whether each entry
in LinkImplementation::Libraries came from a generator expression or
not. Add a FromGenex member to cmLinkImplItem to record this.
Create a cmTargetInternals::AddInterfaceEntries method to construct a
$<TARGET_PROPERTY:tgt,INTERFACE_XYZ> generator expression and evaluate
it for every target in the link implementation. This will be useful to
de-duplicate such evaluation for each usage requirement separately.
The new method will soon be used in the implementation of the
INTERFACE_* usage requirement lookup methods (GetSourceFiles,
GetCompileOptions, GetCompileDefinitions, GetCompileFeatures,
GetIncludeDirectories). It is necessary for these methods to determine
whether an expression in LinkImplementationPropertyEntries evaluates to
a target or not because generator expression evaluation reports an error
for non-targets and we construct a $<TARGET_PROPERTY:tgt,INTERFACE_XYZ>
expression for each entry that is a target.
The implementation of each usage requirement currently processes the
LinkImplementationPropertyEntries and evaluates all generator
expressions to determine targets. That is no longer necessary because
GetLinkImplementationLibraries now returns resolved and cached targets
together with their name. Use it to implement AddInterfaceEntries.
Create a cmLinkImplItem class derived from cmLinkItem so more
information can be added to link implementation entries than link
interface entries. Convert the LinkImplementation Libraries member to
hold it. Update client sites accordingly.
Move the subtests that test with local projects into their own test. The reason
is that on slower or crowded machines the test may reach the limit of 25
minutes and therefore fail while it would pass if it was given enough time.
The split is roughly 3:1 with regard to the execution time, with the new
ExternalProjectLocal test being the faster one.
Print the "timeout correctly killed" message using message(STATUS) so
that 'ctest -S' puts it in the same pipe as the rest of the test command
handler output. This ensures it shows up in the same order every time.
Send status messages to the CTest HANDLER_OUTPUT log since they are part
of the script handler output. This also ensures they appear inline with
other test command handler output.
Because the 8bit string encoding in libarchive can be different than
the 8bit string encoding in CMake, change to call the wide version
of libarchive functions. They are different if CMake is configured
to use UTF-8 as the internal encoding.
Create helper functions for some libarchive calls to use wstring
internally on platforms supporting it.
When cross compiling, toolchains won't have install_name_tool,
which is provided by Xcode and command line tools on OS X.
This is a Mach-O specific utility and not required on all platforms.
Commit v2.8.11~310^2~1 (Keep track of INCLUDE_DIRECTORIES as a vector of
structs., 2012-11-19) added special case of INCLUDE_DIRECTORIES
for the purpose of origin-tracking of individual entries in the property. It
introduced a bug in that it returned an empty string instead of '0' in the
case that no includes have been set.
Commit v2.8.11~289^2~2 (Handle INTERFACE properties transitively for includes
and defines., 2012-09-23) introduced transitive handling of the property
through the link implementation, together with a whitelist of properties
which would be evaluated transitively. Because of the bug introduced
previously, the 'prop' in TargetPropertyNode is non-null,
meaning that the content (the empty string) would be evaluated as a generator
expression. This was harmless as the follow-up code was only for 'INTERFACE_'
variants of target properties, so the effect was the same.
Commits v2.8.11~280^2~2 (Keep track of properties used to determine linker
libraries., 2012-11-05) and v2.8.11~280^2~1 (Add API to calculate
link-interface-dependent bool properties or error., 2013-01-06) added a way
to track and report errors on properties which both determine and are
determined by the link implementation. This was later used in generator
expression evaluation by commit v2.8.11~252^2~2 (Make INTERFACE determined
properties readable in generator expressions., 2013-01-19). If a property
is unset (null), and the link implementation of the target was not being
evaluated, this commit made it possible to evaluate the property from the
link implementation instead. If the link implementation was being evaluated,
an empty string was returned from the generator expression evaluation, which
might be later reported as an error.
The above logic was written for 'compatible interface' properties, but in
fact it should have also included other properties. Because of the
empty-string-instead-of-null bug, this code block is not entered for the
INCLUDE_DIRECTORIES property. At this point, however, the bug still does
not significantly affect behavior, because the follow-up code is still a
no-op for the INCLUDE_DIRECTORIES property, and an empty string is returned
regardless. Commit v2.8.11~189^2~6 (Use the link information as a source of
compile definitions and includes., 2013-02-12) refactored the logic, but also
without a change in behavior.
Commit v2.8.11~156^2~2 (Expand includes and defines transitively
in 'external' genexes., 2013-02-13) refactored the logic again, this time with
a change of behavior. The INCLUDE_DIRECTORIES property was then mapped to
INTERFACE_INCLUDE_DIRECTORIES during transitive generator expression
evaluation. Because the transitive evaluation involved evaluation of the
link implementation, this introduced a recursive loop and a segfault with
code like:
add_library(empty1 ...)
add_library(empty2 ...)
target_link_libraries(empty1
PRIVATE
$<$<STREQUAL:$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>,/foo/bar>:empty2>
)
As there is no real use-case for reading a target property like that while
evaluating the link implementation, this went unnoticed. The same pattern
was followed for other special-cased reads of transitive target properties
such as COMPILE_DEFINITIONS.
The segfault was fixed in the parent commit, but change the property to
return null when appropriate for other future uses.
Commit v2.8.11~156^2~2 (Expand includes and defines transitively
in 'external' genexes., 2013-02-13) introduced a recursive loop
and a stack overflow during evaluation of a link implementation
which depends on a transitive property, such as
add_library(empty1 ...)
add_library(empty2 ...)
target_link_libraries(empty1
PRIVATE
$<$<STREQUAL:$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>,/foo/bar>:empty2>
)
There is no use-case for code like that currently, but it should not
cause a stack overflow.
Avoid the recursion by reporting an error early if a case like this
is found.
A library or executable target that consists only of a reference to an
object library may have no sources to compile or custom commands to run.
The command in the target is the link (or archive) command. Add missing
order-only dependencies to link commands so that target ordering
dependencies are satisfied for it without depending on an intermediate
compilation rule.
Extend the ObjectLibrary test to cover this case.
Co-Author: Brad King <brad.king@kitware.com>
9998d78d Tests: Speed up RunCMake.include_directories test
6eee5d74 Tests: Drop broken and now unused RunCMake_TEST_FILE option
f0f15b93 Tests: Refactor RunCMake.include_directories to drop RunCMake_TEST_FILE
8707814e Tests: Refactor RunCMake.File_Generate to drop RunCMake_TEST_FILE
IcedTea 2.5 have changed libarch for ppc64le to ppc64. Adjust FindJNI
to look for both for backward compatibility.
Signed-off-by: Dinar Valeev <dvaleev@suse.com>
f0e298ad Help: Add notes for topic 'vs14-generator'
5c105140 Tests: Simplify LoadCommand tests
b1cbd577 FindBoost: Add -vc140 mangling for VS 14
bdc7d9c8 VS14: Fix Cl and Link flag tables as previous versions
d96b3f68 VS14: Generate flag tables from MSBuild v140 tool files
65624c39 VS14: Add Visual Studio 14 generator (#14982)
8635ac23 Tests/Preprocess: Remove unnecessary VS version tests