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
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.
Tweak `cmMessenger` to also show the "warning is for project developers"
notice for all diagnostics that are descendants of the `CMD_AUTHOR`
category. When doing so, also show both command-line options which can
suppress the message.
`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
Update expected test output to account for the new format of diagnostic
messages. These changes were applied entirely by `sed` using the
following commands:
- `/Use -Wno-dev to suppress/s/-Wno-dev/-Wno-author/g`
- `s/Warning [\\][(]dev[\\][)]/Warning \\(author\\)/g`
- `s/CMake Deprecation Warning/CMake Warning \\(deprecated\\)/g`
This is not a complete fix, but covers a significant fraction of the
needed changes, and this commit is strictly automated changes.
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
Commit 763aa084b0 (CMP0200: Fix crash in configuration selection policy
warning, 2025-09-10) fixed a bug in the CMP0200 policy warning and also
improved the test to exercise the problematic code, but did not properly
update the expected output. Add the second warning to the expected
output.
The recently introduced CMP0200 warnings could lead to a crash when
encountering targets with empty configuration values. Avoid calling
substr on an empty `string_view`.
Fixes: #27204
The recently introduced CMP0200 improved configuration selection, but
did not correctly implement case-insensitivity. Add some additional case
smashing to ensure that matching is not case sensitive. Improve the test
which was passing due to falling back to the first listed configuration
rather than selecting a matching configuration.
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.
See: #15415
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).
Logically revert commit 390a7d8647 (cmTargetPropertyComputer: Implement
GetProperty without cmMakefile, 2016-10-13, v3.8.0-rc1~445^2~9).
It relied on using `cmListFileBacktrace` to get a scope in which to
look up policies.
This does remove a backtrace from `LOCATION` property errors at generate
time, but the backtrace we reported before was incorrect. It pointed at
the addition of a target, not to the reference to the property.
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.14 and below to encourage projects to port
away from setting policies to OLD.
Brad King
Matthew Woehlke
Mickaël Germain
Robert Maynard
Martin Duffy
Marc Chevrier
AJIOB
Hanna Rusakovich
Joerg Bornemann
Deniz Bahadir
Ben Boeckel
Asit Dhal
Robert Maynard