The logic to select an imported configuration handled the case when
`IMPORTED_CONFIGURATIONS` was missing, but assumed that if it was
present, it was non-empty, which could cause CMake to crash if that
happens. (To be fair, I believe this would never happen for imports
generated by CMake.) Adjust the logic slightly to follow the same code
path when `IMPORTED_CONFIGURATIONS` is empty as is taken if it's
missing.
Fixes: #28065
Add a COMPARATOR form to $<LIST:SORT> that orders the list by a caller-defined
rule: a <body> evaluated per comparison with the two elements bound to $<_0>
and $<_1>, yielding "1" when the first should sort before the second. This
brings the custom ordering of list(SORT ... COMPARATOR) to generate time, so
elements can be ordered by target properties or any other generator expression.
CASE: and ORDER: still apply, while COMPARE: is rejected because the body
defines the ordering.
Fixes: #27892
Allow a binding operation to bind more than one operand at once, exposed as
$<_0>, $<_1>, .... A single value remains the common case, but the upcoming
SORT COMPARATOR must bind the two elements being compared, so the binding
becomes an indexed frame and $<_1> is added. Referencing an index the active
binding does not provide is reported as an error.
Issue: #27892
Let $<LIST:FILTER> select elements by an arbitrary condition: PREDICATE keeps or
drops each element according to a <body> evaluated with $<_0> bound,
complementing the existing regular-expression form. Also accept an explicit
REGEX keyword before the pattern so the regex and predicate forms read
symmetrically; the bare pattern keeps working.
Issue: #27892
Add a PREDICATE selector to $<LIST:TRANSFORM> that chooses which elements to
transform by evaluating a <body> per element (with $<_0> bound) and acting on
those for which it yields "1". This selects by computed condition instead of
the fixed AT/FOR/REGEX positions, so any generator expression -- including
target queries -- can decide where an action applies. It works with both the
canned actions and APPLY.
Issue: #27892
Add an APPLY action to $<LIST:TRANSFORM> that evaluates an arbitrary <body>
once per selected element, with $<_0> bound to the element, so a list can be
mapped through any generator expression at generate time. Unlike the
configure-time list(TRANSFORM ... APPLY <function>) command, the genex form has
no side effects and returns the body's value directly, and a list-valued result
expands into multiple elements.
The body evaluates in its own binding scope, so nested APPLY actions can shadow
$<_0>, and context-sensitive state it observes (such as target dependencies)
still propagates to the enclosing expression. APPLY accepts the same
AT/FOR/REGEX selectors as the canned actions.
Issue: #27892
Introduce "binding operations": generator expressions that evaluate a <body>
once for each value they supply, with $<_0> expanding to that value. This is
the foundation the $<LIST:TRANSFORM,...,APPLY> action and the predicate
selectors build on, letting a <body> refer to the element being processed.
Using $<_0> outside a binding operation is reported as an error rather than
silently expanding to nothing.
Issue: #27892
`LINK_LIBRARIES` entries guarded by `$<COMPILE_ONLY:...>` are not
linked, but must participate in target ordering so files generated by
compile-only dependencies, like headers, are available before
compilation.
Fixes: #27792
Create a brand new implementation of `cmTarget::GetMappedConfig` which
prioritized a target's `IMPORTED_CONFIGURATIONS` as the 'source of
truth' for what configurations are available. In particular, this means
that configuration selection when `IMPORTED_CONFIGURATIONS` is set does
not depend on the library type in any manner. The fallback logic also
uses a more consistent 'usability' criteria that should result in more
consistent configuration selection, particularly for `INTERFACE`
targets.
The previous implementation is retained as a separate method for users
requesting the OLD behavior.
Fixes: #27022
The historic implementation of `$<CONFIG>` had some errors that could
result in multiple configurations matching. First, it always considered
the configuration of the consuming target, even if a consumed imported
target selected a different configuration. Second, it matched the entire
list of `MAP_IMPORTED_CONFIG_<CONFIG>` configurations, even if none of
those were actually selected. The latter in particular is redundant at
best, as we also consider the selected configuration of an imported
target, which is the correct configuration to match for imported
targets. Refactor the implementation so that only one configuration is
considered.
Fixes: #23660
Issue: #27022
Refactoring in commit 72d116ee68 (GenEx: list oriented genexes use
cmList class, 2023-03-29, v3.27.0-rc1~205^2) accidentally caused
empty elements to be dropped by the `REMOVE_DUPLICATES` genex.
Fix it and add a test case.
Fixes: #25080
This generator expression is the inverse of `LINK_ONLY` and only coveys
usage requirements for the purposes of compilation. Its intended use is
to avoid needing to export targets that do not have link usage
requirements (e.g., header-only libraries) when used by another target.
It will also be used to represent private usage requirements on exported
C++ module-containing targets in the future.
Eventually there should be logic to collapse nesting of
`$<COMPILE_ONLY>` and `$<LINK_ONLY>` when generating instances of
either. A TODO is left in the code for this case.
See: #15415
Issue a deprecation warning on calls to `cmake_minimum_required` or
`cmake_policy` that set policies based on versions older than 3.5.
Note that the effective policy version includes `...<max>` treatment.
Update the check from commit 5845c218d7 (Deprecate compatibility with
CMake versions older than 2.8.12, 2020-06-12, v3.19.0-rc1~629^2).
These generator expressions can only be used in link options properties.
These expressions return the arguments respectively for device and host link
step, otherwise return an empty string.
For special properties like `INCLUDE_DIRECTORIES`, the pointer returned
by `cmTarget::GetProperty` is only valid until the next time the same
special property is queried on *any* target. When evaluating a nested
`TARGET_PROPERTY` generator expression we may look up such a property
more than once on different targets. Fix `TargetPropertyNode::Evaluate`
to store the lookup result in locally owned memory earlier.
Fixes: #19286
Adds `Fortran_COMPILER_ID` and `Fortran_COMPILER_VERSION` generator
expression support to match equivalent `C_COMPILER_ID`,
`CXX_COMPILER_ID`, `C_COMPILER_VERSION`, and `CXX_COMPILER_VERSION`
support.
This is very helpful in the case where the C/C++ compiler suite is a
different type of compiler from the platform Fortran compiler and
projects use generator expressions to assign compiler flags and
definitions. (e.g. `GNU` C/C++ and `SunPro` Fortran on Linux)
The old behavior of $<IN_LIST:...> is inconsistent with that of
if(IN_LIST), in that it does not find an empty search item even if
the list contains empty items. This change adds a new policy to
correctly handle empty items and make the behavior more consistent
with if(IN_LIST).
Fixes: #18556
Refactoring in commit v3.8.0-rc1~445^2~2 (cmTarget: Move sanity checks
and computed property access to callers, 2016-10-13) exposed a typo in
commit v3.8.0-rc1~445^2~3 (cmGeneratorTarget: Implement
cmTargetPropertyComputer interface, 2016-10-13). Together they broke
the `$<TARGET_PROPERTY:mytgt,SOURCES>` generator expression in the case
that the `SOURCES` target property is populated in part by the
`target_sources` command. Add the missing `;`-separator.
Fixes: #17243
Brad King
Matthew Woehlke
Mickaël Germain
Robert Maynard
Martin Duffy
Marc Chevrier
Deniz Bahadir
Ben Boeckel
Asit Dhal
Robert Maynard
Sebastian Lipponer
Andrew Paprocki
Kyle Edwards
Marc Chevrier
Alex Turbov
Gregor Jasny