Move some target related enumeration types from `cmStateTypes.h` to a
new header, as these really aren't "state" types. Also, make
`TargetType` a strongly-typed enumeration.
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
Prepare for a genex-driven SORT comparator without changing behavior: let
cmList::sort() accept a caller-supplied comparison function, and give the
$<LIST:SORT> COMPARE:/CASE:/ORDER: option parsing a single definition shared
with the canned handler. The new feature can then reuse both rather than
duplicating the sort plumbing and the option syntax.
Issue: #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
Several $<LIST> doc references appeared as plain literal text: the bound
operand $<_0>, the configure-time list(TRANSFORM ... APPLY) command (the
TRANSFORM APPLY action title and prose), and the $<LIST:TRANSFORM,...,APPLY,body>
example in the $<_0> definition. Use the :genex: and :command: roles so they
hyperlink to their definitions, matching the sibling canned actions and the
rest of the manual.
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
Resolve each canned $<LIST:TRANSFORM> action to its cmList action and argument
count through a single table rather than an inline chain, so the PREDICATE
selector added next can reuse the same action metadata instead of duplicating
it.
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
Give the AT/FOR/REGEX selector syntax shared by the $<LIST:TRANSFORM> actions a
single definition, so its diagnostics and index/REGEX semantics cannot drift
between actions. Also let a caller learn which elements a selector picks
without running a transform, as groundwork for actions that drive their own
per-element loop.
Issue: #27892
Add and use a couple helper functions for issuing policy warnings. This
improves consistency and allows some simplification of many call sites.
(One or two instances in particular are greatly simplified.)
Add new diagnostic categories CMD_POLICY and CMD_EXPERIMENTAL, both as
children of CMD_AUTHOR. Use the former when issuing policy warnings. Use
the latter when issuing experimental feature warnings.
Find places that are currently relying on diagnostic-specific message
types to issue diagnostics and replace these with calls to the new
diagnostic methods.
To manage the generation step, introduce cmGeneratorFileSet and
cmGeneratorFileSets classes.
These reorganizations of the code are done in preparation of the
implementation of SOURCES file set type as well as user's file set types.
Issues: #27550, #27383
This feature is required for the support of the future feature of
pattern rules (see #27383).
But it is also a valuable addition in the context of custom command and target.
Modify the implementation of policy CMP0199 to only remove the oddball
configuration map matching of `$<CONFIG>` in `NEW` mode, restoring the
old behavior of matching BOTH the consumer's configuration and the
selected configuration of the imported target. It turns out that users
are more dependent on the former than the latter, and while matching
more than one thing is still dodgy, we will likely need to introduce a
new generator expression to match the selected configuration of the
imported target.
Meanwhile, `$<CONFIG>` on targets imported from CPS still only matches
the selected configuration of the imported target, which is the behavior
specified by CPS. However, this can only happen for `$<CONFIG>`
expressions that were generated internally during import.
Update documentation and test cases accordingly.
Fixes: #27487Fixes: #27495
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 13. Some patterns:
* Types named in virtual `override` signatures no longer require
includes since the overridden signature already names them.
* A function argument's type needs to be included even if its constructor
is called only by implicit conversion. For example, constructing a
`std::function` from a lambda now requires `<functional>`.
* Some prior mysterious `<type_traits>` inclusions are no longer required.
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 13. Some patterns:
* Types named in virtual `override` signatures no longer require
includes since the overridden signature already names them.
* A function argument's type needs to be included even if its constructor
is called only by implicit conversion. For example, constructing a
`std::function` from a lambda now requires `<functional>`.
* Some prior mysterious `<type_traits>` inclusions are no longer required.
The cmLinkImplItem class used to contain some additional members
to support the CMP0027 policy. Since the CMP0027 policy and those
associated members were removed, the cmLinkImplItem class has been
a plain wrapper around cmLinkItem with no additional members.
It is no longer needed and cmLinkItem can be used directly wherever
cmLinkImplItem was used previously.
In general we disallow references to transitive target properties, such
as `COMPILE_DEFINITIONS`, in `[INTERFACE_]LINK_LIBRARIES` properties,
because the latter establish the transitivity itself. Prior to CMP0189,
the `[INTERFACE_]LINK_LIBRARIES` properties were not themselves transitive
in `$<TARGET_PROPERTY>` expressions, so existing projects have code like
target_link_libraries(foo PRIVATE "$<TARGET_PROPERTY:tgt,LINK_LIBRARIES>")
Policy CMP0189's NEW behavior, introduced by commit b3da9c6d60 (GenEx:
Evaluate LINK_LIBRARIES target properties transitively, 2025-02-24,
v4.1.0-rc1~731^2), makes `$<TARGET_PROPERTY:tgt,LINK_LIBRARIES>`
transitive, causing the above to be rejected. Since evaluation of a
target's link libraries can already encounter and handle other targets'
link libraries, allow it in this case.
Fixes: #27265
Extend commit e8010b67c7 (cmGeneratorExpressionDAGChecker: Make local
generator available in constructor, 2024-04-25, v3.30.0-rc1~172^2~6) and
commit 633afa0b2e (cmGeneratorExpressionDAGChecker: Make config name
available in constructor, 2024-05-08, v3.30.0-rc1~82^2~2) to make the
full evaluation context available in the constructor.
AJIOB
Matthew Woehlke
Brad King
Mickaël Germain
Marc Chevrier
Kyle Edwards
Ben Boeckel
Martin Duffy
Craig Scott