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.
As an INTERFACE_LIBRARY has no direct link dependencies, we can
short-circuit in cmGeneratorExpressionEvaluator and
in cmGlobalGenerator::CheckLocalGenerators.
As they do not generate any output directly, any generate- or install-
related code acn also be short-circuited. Many of the local generators
already do this.
Because only INTERFACE related properties make sense on INTERFACE_LIBRARY
targets, avoid setting other properties, for example via defaults.
Teach the cmGeneratorExpressionEvaluator filesystem artifact logic
to reject OBJECT_LIBRARY targets since they have no main artifact.
Without the explicit rejection evaluation falls through to an
internal CMake error message in cmTarget::GetOutputInfo.
Extend the RunCMake.GeneratorExpression test to cover these cases.
This has follow-on effects for other methods and classes. Further
work on making the use of const cmTarget pointers common can be
done, particularly with a view to generate-time methods.
When using the boost MPL library, one can set a define to increase
the limit of how many variadic elements should be supported. The
default for BOOST_MPL_LIMIT_VECTOR_SIZE is 20:
http://www.boost.org/doc/libs/1_36_0/libs/mpl/doc/refmanual/limit-vector-size.html
If the foo library requires that to be set to 30, and the independent
bar library requires it to be set to 40, consumers of both need to set
it to 40.
add_library(foo INTERFACE)
set_property(TARGET foo PROPERTY INTERFACE_boost_mpl_vector_size 30)
set_property(TARGET foo PROPERTY COMPATIBLE_INTERFACE_NUMBER_MAX boost_mpl_vector_size)
target_compile_definitions(foo INTERFACE BOOST_MPL_LIMIT_VECTOR_SIZE=$<TARGET_PROPERTY:boost_mpl_vector_size>)
add_library(bar INTERFACE)
set_property(TARGET bar PROPERTY INTERFACE_boost_mpl_vector_size 40)
# Technically the next two lines are redundant, but as foo and bar are
# independent, they both set these interfaces.
set_property(TARGET bar PROPERTY COMPATIBLE_INTERFACE_NUMBER_MAX boost_mpl_vector_size)
target_compile_definitions(bar INTERFACE BOOST_MPL_LIMIT_VECTOR_SIZE=$<TARGET_PROPERTY:boost_mpl_vector_size>)
add_executable(user)
target_link_libraries(user foo bar)
Because the TARGET_PROPERTY reads the boost_mpl_vector_size property
from the HEAD of the dependency graph (the user target), and because
that property appears in the COMPATIBLE_INTERFACE_NUMBER_MAX of
the dependencies of the user target, the maximum value for it is
chosen for the compile definition, ie, 40.
There are also use-cases for choosing the minimum value of a number.
In Qt, deprecated API can be disabled by version. Setting the
definition QT_DISABLE_DEPRECATED_BEFORE=0 disables no deprecated
API. Setting it to 0x501000 disables API which was deprecated before
Qt 5.1 etc.
If two dependencies require the use of API which was deprecated in
different Qt versions, then COMPATIBLE_INTERFACE_NUMBER_MIN can be
used to ensure that both can compile.
d169b1f Genex: Use cmArraySize for targetPolicyWhitelist
86d5d80 Genex: Remove use of TransitiveWhitelistCompare
73d7705 Add some templates for cleaner array iteration.
CMake/Source/cmGeneratorExpressionParser.cxx: In member function ‘void cmGeneratorExpressionParser::ParseGeneratorExpression(std::vector<cmGeneratorExpressionEvaluator*>&)’:
CMake/Source/cmGeneratorExpressionParser.cxx:116:55: warning: conversion to ‘unsigned int’ from ‘long int’ may alter its value [-Wconversion]
CMake/Source/cmGeneratorExpressionParser.cxx:240:39: warning: conversion to ‘int’ from ‘long int’ may alter its value [-Wconversion]
Commit 10a069b5 (Genex: Fix $<CONFIG> with IMPORTED targets and
multiple locations., 2013-07-15) changed the logic here to include
handling of the MAP_IMPORTED_CONFIG_<CONFIG> target property, but
it was buggy in several ways.
Uppercase the configs in all cases, and compare the mapped configs
with the parameter to the CONFIG genex, instead of with the key of
the mapping.
* The ALIAS name must match a validity regex.
* Executables and libraries may be aliased.
* An ALIAS acts immutable. It can not be used as the lhs
of target_link_libraries or other commands.
* An ALIAS can be used with add_custom_command, add_custom_target,
and add_test in the same way regular targets can.
* The target of an ALIAS can be retrieved with the ALIASED_TARGET
target property.
* An ALIAS does not appear in the generated buildsystem. It
is kept separate from cmMakefile::Targets for that reason.
* A target may have multiple aliases.
* An ALIAS target may not itself have an alias.
* An IMPORTED target may not have an alias.
* An ALIAS may not be exported or imported.
It accepted an optional argument to test for equality, but no way
to get the linker language of a particular target.
TARGET_PROPERTY provides this flexibility and STREQUAL provides
the necessary API for equality test.
Extend the CompileDefinitions test to cover accessing the
property of another target.
9cf3547 Add the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property.
1925cff Add a SYSTEM parameter to target_include_directories (#14180)
286f227 Extend the cmTargetPropCommandBase interface property handling.
83498d4 Store system include directories in the cmTarget.
f1fcbe3 Add Target API to determine if an include is a system include.
2679a34 Remove unused variable.
Unlike other target properties, this does not have a corresponding
non-INTERFACE variant.
This allows propagation of system attribute on include directories
from link dependents.
Use preprocessor loops and add a unit test for the appropriate
policies. All policies whose value is recorded at target creation
time should be part of this list.
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.
Stephen Kelly
Brad King
Rolf Eike Beer