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.
The error messages were incorrect (reporting that the expression
requires one or two parameters), and repeated. Remove the now-unused
ZeroOrMoreParameters enum value.
Existing single-parameter expressions work due to special casing
which assumes that if there is only one parameter, and the node
accepts arbitrary content, then the result is the input.
This is true for the existing expressions matching that
pattern - namely the "1" and "TARGET_NAME" expressions. However,
the LOWER_CASE, and UPPER_CASE expressions should also accept
arbitrary content, and in their case, the result is not the input.
Refactor the cmGeneratorExpressionEvaluator to allow that extension.
Actually evaluate the "1" and "0" nodes.
Brad King
Nils Gladitz
Stephen Kelly
Ben Boeckel
Rolf Eike Beer