ff015ee Genex: Report error if a target file is needed to evaluate link libraries.
b58aff9 Genex: Extend EvaluatingLinkLibraries to also check the top target name.
b1c19ce Genex: Make LINK_LANGUAGE report an error when evaluating link libraries.
0e1cb07 Add missing return after error report.
If the expression $<TARGET_PROPERTY:prop> appears in the content
of a target property, the target that prop is read from is
the 'head target' of the expression. In contexts such as evaluating
the content of a target property during generation, such
as INCLUDE_DIRECTORIES, the 'head target' is the one on which the
initial request was made.
If evaluating a generator expression which is not a target property
content, the target must be explicitly specified. Such contexts
include add_custom_command and file(GENERATE). The content might
then look like
$<TARGET_PROPERTY:tgt,prop>
However, as there is no HeadTarget set, any generator expressions
evaluated as part of reading prop from tgt which do not specify
the tgt directly report an error.
Modify the logic of the TARGET_PROPERTY generator expression so
that in such contexts, the 'head target' is set to the appropriate
target which was first encountered.
3aa9ce4 GenexEval: Fix evaluation of INCLUDE_DIRECTORIES target property.
0b39fef GenexEval: Extract a getLinkedTargetsContent from TargetPropertyNode.
53164ac cmTarget: Remove some hardcoding of transitive property names.
This property should come from the content of the property itself,
plus the INTERFACE_INCLUDE_DIRECTORIES of the link *implementation*.
In contrast, when the INTERFACE_INCLUDE_DIRECTORIES is evaluated for
a target, the INTERFACE_INCLUDE_DIRECTORIES of the link *interface*
is used.
Similar logic applies for the COMPILE_DEFINITIONS target properties.
If the propertyName is already an INTERFACE_ variant of the property,
ie, the expression is similar to
$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>
then the INTERFACE_INCLUDE_DIRECTORIES of the link *interface* of foo
is used.
However, if the propertyName is not an INTERFACE_ variant, and the
interfacePropertyName is, ie, the expression is similar to:
$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>
then the INTERFACE_INCLUDE_DIRECTORIES of the link *implementation*
of foo is used.
This will be used to process transitive components of properties
which depend on linked targets. Currently only the link interface
of the target can be used as the source of the linked targets, but
in the next commit it will be possible to use the link implementation
as the source of link targets.
This commit does not change the semantics of the code.
They can't be used when evaluating link libraries, but they can be
used for include directories and compile definitions. Later they can
be used for compile options.
a7ba452 Add the JOIN generator expression.
96ec314 Make it possible for any genex to have arbitrary content at the end.
bd638ee Rename the method determining if a genex accepts arbitrary content.
dc742fe Extract the ProcessArbitraryContent method.
This generator expression joins a list with a separator. The separator
may contain arbitrary content, such as commas, which is ordinarily a
delimiter in the generator expression syntax.
cbf0756 Revert "Add the TARGET_DEFINED generator expression"
21a342c Remove use of TARGET_DEFINED from the target_link_libraries test.
47b8d32 Remove use of TARGET_DEFINED from the ExportImport test.
2e39d21 Remove use of TARGET_DEFINED from target_include_directories test.
8dfdf1c Fix the tests for evaluating includes and defines.
98a6725 Fix constness of accessors.
7e70744 Expand includes and defines transitively in 'external' genexes.
d1a2729 Fix DAG checker finding cycling dependencies.
e72eaad Workaround broken code where a target has itself in its link iface.
ec2c67b Strip stray semicolons when evaluating generator expressions.
This reverts commit 2bee6f5ba5.
This expression is not used, and has a semantic which is not completely
optimal (namely considering utility targets to be targets, though
usually we are interested in linkable targets).
Remove it so that we have more freedom to define better expressions in
the future.
Conflicts:
Source/cmGeneratorExpressionEvaluator.cxx
Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
Tests/CMakeCommands/target_compile_definitions/consumer.cpp
This means that we can use expressions of the form
$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>
to get a list of the interface include directories of foo, including
those coming from dependencies.
We can't have a test of a target which has a single include directory in
its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms
a single include directory to include a prefix, which is not what the test
expects. We test a target with two directories instead as a means to
test a target with no link dependencies.
There is a test for this since commit 8e756d2b (Tolerate cycles in
shared library link interfaces (#12647), 2012-01-12), so make sure
it continues to pass, even as we require no self-references in new
INTERFACE_ property generator expressions.
After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a
generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of
its link interface dependencies.
That means that code such as this will result in the 'user' target
using /bar/include and /foo/include:
add_library(foo ...)
target_include_directories(foo INTERFACE /foo/include)
add_library(bar ...)
target_include_directories(bar INTERFACE /bar/include)
target_link_libraries(bar LINK_PUBLIC foo)
add_executable(user ...)
target_include_directories(user PRIVATE
$<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>)
Also process the interface include directories from direct link
dependencies for in-build targets.
The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The
include directories related code is currently more complex because
we also need to store a backtrace at configure-time for the purpose
of debugging includes. The compile definitions related code will use
the same pattern in the future.
This is not a change in behavior, as existing code has the same effect,
but that existing code will be removed in follow-up commits.
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.
Generator expressions whose output depends on the configuration
now record that fact. The GetIncludeDirectories method can use
that result to cache the include directories for later calls.
GetIncludeDirectories is called multiple times for a target
for each configuration, so this should restore performance for
multi-config generators.
While porting boost to use these features, the generation step took
too long (several minutes before I stopped it). The reason was that
the boost libraries form a large interdependent mesh. The libraries
list their dependencies in their INTERFACE such as:
$<LINKED:boost::core>;$<LINKED:boost::config>;$<LINKED:boost::mpl>
As boost::core already depends on the boost::config libraries, that
expression has no impact on the end-content, as it is removed after
the generation step. There is no DAG issue though, so the generator
expression evaluation would fully evaluate them. In the case of the
config library, it also depends on the core library, so all depends
are followed through that again, despite the fact that they've just
been evaluated. After this patch, the evaluation skips libraries if
they have already been seen via depends or directly in the content.
This patch keeps track of targets whose INTERFACE has been consumed
already. The INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS properties
are whitelisted because repeated content will be stripped out later
during generation. For other properties now and in the future, that
may not be the case.
This is both a short form of using a TARGET_DEFINED expression
together with a TARGET_PROPERTY definition, and a way to strip
non-target content from interface properties when exporting.
Stephen Kelly
Brad King
Jean-Christophe Fillion-Robin