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.
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.
Use LinkImplementationPropertyEntries directly instead of asking
GetProperty to construct a string for LINK_LIBRARIES. This gives us
access to the entry backtraces.
If ComputeLinkImplementationLanguages were ever to cause
GetLinkImplementationLibraries to be invoked then a LinkImplMap entry
may appear in the middle of computing it in GetLinkInformation. Instead
create the map entry up front and store in it boolean values indicating
which pieces of the LinkImplementation structure have been populated.
This approach leads to shorter code that is easier to follow too.
Members of the cmTargetInternals structure do not need to be made
'mutable' even to cache data because there is no reason for the
internal methods to be 'const'.
Teach GetTransitivePropertyTargets to use the GetLinkInterfaceLibraries
method with usage_requirements_only==true instead of evaluating the
INTERFACE_LINK_LIBRARIES property directly. This avoids duplicate
evaluations and makes use of the caching done by
GetLinkInterfaceLibraries.
Add a 'usage_requirements_only' parameter to GetLinkInterfaceLibraries
and supporting internal APIs to pass through to ExpandLinkItems so it
knows whether to use SetTransitivePropertiesOnly while evaluating
generator expressions.
Simplify the implementation of GetTransitivePropertyTargets by using
ExpandLinkItems with usage_requirements_only==true to evaluate the
generator expressions in the link interface for us.
Add a 'usage_requirements_only' parameter to ExpandLinkItems so that it
knows whether to use SetTransitivePropertiesOnly while evaluating
generator expressions. Update existing call sites to pass 'false' since
they are for linking and not usage requirements.
Use GetLinkImplementationLibraries instead of GetDirectLinkLibraries
because it tells us whether there will be any libraries to link after
evaluating generator expressions. Also GetDirectLinkLibraries will be
dropped soon.
Instead of storing just the string names in these structures, lookup any
target associated with each item and store its cmTarget pointer. Use
the cmLinkItem class to hold the name and pointer together. Update
client sites to use the pre-stored lookup result instead of looking up
the target name again.
Create a cmTarget::LookupLinkItems helper method to handle the lookup.
Since lookups are now moving from cmComputeLinkDepends::AddLinkEntries
to cmTarget::LookupLinkItems, move use of CheckCMP0004 to the latter.
This drops use of CheckCMP0004 from entries added for _LIB_DEPENDS
variables by cmComputeLinkDepends::AddVarLinkEntries, but I do not
think that use was intentional originally anyway.
Add a method like GetUtilities but that provides the target names
already looked up and resolved to cmTarget pointers internally. Update
call site in cmComputeTargetDepends::AddTargetDepend to use the
already-found target instead of looking it up again.
In cmTarget, cmGeneratorTarget, and cmGeneratorExpressionEvaluator, fix
target name lookups to occur in the cmMakefile context of the target
that referenced the name, not the current 'head' target. The context
matters for imported targets because they are directory-scoped instead
of globally unique. We already do this in cmComputeLinkDepends and
cmComputeTargetDepends.
Extend the InterfaceLibrary test with an example covering this behavior.
Move generator expression evaluation for imported library lists out of
GetImportInfo and into a new GetImportLinkInterface helper. This avoids
duplicating the computation and storage of all imported target info just
because some of it is parameterized on the 'head' target.
Many of the 'head' arguments added by commit v2.8.11~289^2~1 (Make
linking APIs aware of 'head' target, 2013-01-04) turned out not to be
needed. The "link implementation" of a target never needs to be
computed with anything but itself as the 'head' target (except for
CMP0022 OLD behavior because then it is the link interface).
Remove the unused 'head' target paths. Add "internal" versions of
cmTarget::GetDirectLinkLibraries and GetLinkImplementationLibraries
to support the CMP0022 OLD behavior without otherwise exposing the
'head' target option of these methods.
Create an ExpandLinkItems method to handle evaluation of generator
expressions in a library list and expansion of the ;-list into a vector.
Replace some duplicate copies of the implementation with calls to the
new helper.
Create a Platform/Android module that includes Platform/Linux since
Android is based on Linux. Provide only the minimal settings needed to
get builds with Android NDK toolchains to work.
Disable use of RPATH since the Android loader ignores it and we cannot
predict the install destination anyway.
Android supports soname but shared library names must end in ".so" and
we cannot represent the versioned names with associated symlinks on all
host operating systems anyway. However, we do want the SONAME of
library files to be set so that linking to them by path to the library
file produces NEEDED entries with the soname and not the path. Add a
new CMAKE_PLATFORM_NO_VERSIONED_SONAME setting to tell the
cmTarget::GetLibraryNames method that not to use the VERSION or
SOVERSION target properties in the soname.
Allow setting build properties based on the features available
for a target. The availability of features is determined at
generate-time by evaluating the link implementation.
Ensure that the <LANG>_STANDARD determined while evaluating
COMPILE_FEATURES in the link implementation is not lower than that
provided by the INTERFACE of the link implementation. This is
similar to handling of transitive properties such as
POSITION_INDEPENDENT_CODE.
The languages used in compiling STATIC libraries need to be propagated
to dependents regardless of the settings of INTERFACE_LINK_LIBRARIES or
CMP0022. They are independent of the libraries in the link interface.
Prior to commit v2.8.12~192^2~2 (Introduce the INTERFACE_LINK_LIBRARIES
property, 2013-06-04) the cmTarget::ComputeLinkInterface code path for
"explicitLibraries" could never be taken for STATIC libraries, so the
logic to propagate languages existed only in the non-explicitLibraries
code path. After that commit, INTERFACE_LINK_LIBRARIES could be set for
STATIC libraries to cause the "explicitLibraries" code path to be taken.
The commit also left the old non-explicitLibraries code path conditional
on CMP0022 not being set to NEW. Thus link language propagation was
left missing from two cases by that commit.
The explicitLibraries code path was fixed to propagate languages by
commit v2.8.12~149^2~1 (cmTarget: Fix iface libraries and languages for
static libraries, 2013-07-26). However, the non-explicitLibraries case
was never taught to propagate languages when CMP0022 is set to NEW. Fix
that now. Factor the logic to propagate link languages out of the link
interface libraries conditions so that it always occurs. Update
Tests/Fortran to set CMP0022 to NEW to test this case (because the test
passes only if link language propagation works).
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.
These policies should be checked at the call site that tries to access
the LOCATION or SOURCES property, not the directory scope containing the
target. Thread the caller context through cmTarget::GetProperty to use
for checking the policy setting and emitting a diagnostic with proper
backtrace.
Extend the RunCMake.CMP0026 and RunCMake.CMP0051 tests with
cross-directory cases.
Brad King
Stephen Kelly
Ben Boeckel