Extract a new method to encapsulate the requirements of evaluating
dependent-expressions, namely, propagation of the
EvaluateForBuildsystem setting, which is missing from the
getLinkedTargetsContent implementation.
Commit v3.1.0-rc1~688^2 (Genex: Only evaluate TARGET_OBJECTS to determine
target sources., 2014-03-20) introduced an error case for use of
TARGET_OBJECTS outside of the context of generating the buildsystem,
as the path to object files may be dependent on buildsystem
variables (See bug #15226).
Commit v3.1.0-rc1~314^2 (Allow INTERFACE_SOURCES to specify
$<TARGET_OBJECTS> (#14970), 2014-07-09) made it possible to
propagate such content to dependent targets.
While that commit propagated the EvaluateForBuildsystem setting
for the case of a TARGET_PROPERTY expression, as generated for
direct dependencies of a target in
cmTargetInternals::AddInterfaceEntries, it did not add propagation
for content from further transitive target dependencies, as determined
by getLinkedTargetsContent.
The evaluation files must be known before cmTargetTraceDependencies
attempts to find them, but we must actually generate the files after
cmTargetTraceDependencies, as that can add to target SOURCES. The
limitation is that the generated output name must not depend on the
SOURCES of a target if the generated file is used by that target.
Mark the output files as GENERATED so that trace dependencies does
not expect them to already exist in the filesystem.
Move the invokation of ForceLinkerLanguage in the Generate logic
to after the generated file names are known. ForceLinkerLanguage
tries to determine the sources of a target (in order to determine
an already-known language) and otherwise fails to get information
about the generated file.
Test that the output of file(GENERATE) can be used as a target source
file and that accessing the target SOURCES in the name of the output
file is an error. Accessing the TARGET_OBJECTS would be a similar
error if it was legal to use that generator expression in this
context. That is not currently possible and is a different error
condition, so test the current error output as a reminder to change
the expected output if that becomes possible in the future. Test
that generated rule files resulting from cmTargetTraceDependencies
appear in the SOURCES generated in the output file.
The logic introduced in commit v3.1.0-rc1~688^2~9 (Genex: Evaluate
TARGET_OBJECTS as a normal expression, 2014-02-26) ordered a map
by pointer value and then constructed a list of object files by
iterating over the map. This is not deterministic.
Since commit v3.1.0-rc1~688^2~5 (cmTarget: Allow any generator
expression in SOURCES property, 2014-03-18) the order produced by the
above-mentioned logic started being used for the actual list of object
files on the link line. Since it is not deterministic, spurious
re-links occur after re-running CMake simply because the order of
objects changed on the link line.
Fix this by iterating over the original vector of source files instead
of the map. This has a deterministic order.
When $<TARGET_PROPERTY> names a build property like COMPILE_DEFINITIONS
but not the usage requirement (INTERFACE_) version of it, the value
should be that used to build the target. It should not be influenced by
a dependent 'head' target like usage requirements are.
Extend the CompileDefinitions test with a case covering the corrected
behavior.
Reviewed-by: Stephen Kelly <steveire@gmail.com>
The context->Makefile is never NULL, but our checks for it convince
Clang scan-build that it might be NULL. Then it warns about later
unchecked uses. Drop the unnecessary checks.
In cmGeneratorExpressionEvaluator, teach getLinkedTargetsContent to call
cmGeneratorExpression::StripEmptyListElements to transform its return
value so that callers do not have to do so.
In cmGeneratorExpressionEvaluator, avoid searching through the list of
transitive interface property names repeatedly during evaluation of
TargetPropertyNode. Simply record the results of the first search for
later re-use.
In cmGeneratorExpressionEvaluator, make getLinkedTargetsContent a
template so it can traverse over either the Libraries in a cmTarget
LinkImplementationLibraries or a cmTarget LinkInterfaceLibraries. This
also avoids creating a separate vector<cmTarget*>.
Split the library lists out of LinkImplementation and LinkInterface into
LinkImplementationLibraries and LinkInterfaceLibraries parent classes,
respectively. Return these from GetLinkImplementationLibraries and
GetLinkInterfaceLibraries, respectively, so that callers cannot access
parts of the structures that have not been populated.
Fix cmTarget::GetSourceFiles to set EvaluateForBuildsystem on the
$<TARGET_PROPERTY:...,INTERFACE_SOURCES> generator expression so that
the $<TARGET_OBJECTS> generator expression is allowed within an
INTERFACE_SOURCES value.
Extend the InterfaceLibrary test to cover this case. Extend the
RunCMake.TargetObjects test to cover failure of $<TARGET_OBJECTS>
when used through $<TARGET_PROPERTY:...,INTERFACE_SOURCES> in a
non-buildsystem context.
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~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.
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.
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.
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.
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.
9407174b target_sources: New command to add sources to target.
81ad69e0 Make the SOURCES target property writable.
6e636f2e cmTarget: Make the SOURCES origin tracable.
3676fb49 cmTarget: Allow transitive evaluation of SOURCES property.
e6971df6 cmTarget: Make the source files depend on the config.
df753df9 cmGeneratorTarget: Don't add computed sources to the target.
869328aa cmComputeTargetDepends: Use valid config to compute target depends.
Extend the cmGeneratorExpressionDAGChecker with an interface
returning the name of the top target. Use that to determine
when there is a DAG violation, as required by the RunCMake.Languages
tests.
Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.
Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.
Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.
Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.
The output of this expression may contain macros for IDEs to replace
such as $(Configuration), $(CURRENT_ARCH) etc. To avoid generating
content which is not usable in other contexts, report an error if
there is an attempt to use it in other contexts.
This commit may be reverted in the future if a solution to the
above difference is implemented.
Use the clang RemoveCStrCalls tool to automatically migrate the
code. This was only run on linux, so does not have any positive or
negative effect on other platforms.
For the OLD CMP0022 behavior, we need to treat the implementation
as the interface when computing the interface libraries. Make it
possible to do that without computing the link languages by adding
a new GetLinkImplementationLibraries method. Extend the existing
GetLinkImplementation method to populate the languages if the
libraries have already been computed and cached.
Change GetTransitivePropertyTargets to invoke GetLinkInterfaceLibraries
instead of GetLinkInterface. This is key, as it is a method called
by cmGeneratorExpressionEvaluator.
Change the cmGeneratorExpressionEvaluator to invoke
GetLinkImplementationLibraries instead of GetLinkImplementation.
The callers already skip non-targets, so unify the target search.
Change supporting functions to accept a container of targets instead
of strings where possible.
Most callers already have a std::string, on which they called c_str() to pass it
into these methods, which internally converted it back to std::string. Pass a
std::string directly to these methods now, avoiding all these conversions.
Those methods that only pass in a const char* will get the conversion to
std::string now only once.
This is consistent with other similar expressions such as PLATFORM_ID,
and makes the CONFIGURATION expression obsolete.
Fix an off-by-one error in
GeneratorExpressionContent::EvaluateParameters exposed by a unit test.
Remove the test for 'bad' nullary use of $<CONFIG>.
Add a unit test to verify that $<CONFIG> and $<CONFIGURATION> have
the same value.
Sean McBride
Brad King
Stephen Kelly
Clinton Stimpson
Nils Gladitz
Ben Boeckel
Rolf Eike Beer