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
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
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
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.
Using `signature` renders the anchor links for each sub-command, and is
consistent with the other `Help/command` pages which contain multiple
sub-commands.
- Added intro code blocks showing how to include these modules.
- Used word "command" instead of "macro".
- Added examples sections.
- Updated and synced descriptions of commands and arguments.
- Added a rubric title for variables that affect the checks.
- Listed CMAKE_TRY_COMPILE_TARGET_TYPE variable in the rubric together
with CMAKE_REQUIRED_* variables.
- Added link to CheckCompilerFlag module in the target_compile_options()
docs.
- Used lowercase style for check_fortran_compiler_flag() command.
- Added a link to `$<COMPILE_LANGUAGE:languages>` generator expression
so it can be linked from other pages (See commit
2e37a20f02 for more info on the initial
style used).
- Fixed the GENEX_NOTE inclusion (starting with line after the 2nd line)
where part of the sentence was rendered in the output.
Update wording added by commit 6e5ccabe9b (Genex: Update
$<TARGET_FILE_BASE_NAME:...>: take care of POSTFIX, 2019-04-25,
v3.15.0-rc1~175^2) to associate references to the `<CONFIG>_POSTFIX`
properties with references to the `OUTPUT_NAME` properties because
they are both used together. Avoid association with the `PDB_NAME`
properties because they cause `<CONFIG>_POSTFIX` to be ignored.
The `LINK_LIBRARIES` and `INTERFACE_LINK_LIBRARIES` target properties
establish the graph of link dependencies used to propagate usage
requirements transitively. Therefore the `$<TARGET_PROPERTY:...>`
generator expression should evaluate them transitively as it does for
other transitive properties. Add policy CMP0189 for compatibility.
Fixes: #26709
Issue: #12435
When doing successive matches, track the input start and current search
start positions separately to prevent the `^` anchor from matching in
the middle of the string. Add policy CMP0186 to provide compatibility.
Issue: #26629Fixes: #16899
Covers almost all blocks containing actual code, except:
* Parsed-literal blocks can't be highlighted, including many command
summaries and substitution-heavy docs like find_... commands.
This is a Sphinx limitation.
* Code with errors, like CMP0049, DEPLOYMENT_ADDITIONAL_FILES,
DEPLOYMENT_REMOTE_DIRECTORY, @PACKAGE_INIT@ substitution in the
tutorial, bracket arguments/comments in cmake-language.7 and
cmake-developer.7.
* FindQt4 module, which needs reformatting.
Revert commit 4a11772618 (GenEx: Limit TARGET_PROPERTY transitive
closure optimization to subgraphs, 2024-05-31, v3.31.0-rc1~114^2).
The change caused substantial performance regressions in some
existing use cases. Revert it pending further investigation.
Issue: #25728Fixes: #26457
Implements the generator expression $<PATH:MATIVE_PATH> which convert
path(s) into a native format with platform-specific slashes (``\`` on
Windows hosts and ``/`` elsewhere).
Fixes: #26515
Teach the `$<TARGET_PROPERTY:...>` generator expression to check for a
new `TRANSITIVE_LINK_PROPERTIES` property in the target's link
closure to enable transitive evaluation of named properties through
the link closure, including entries guarded by `$<LINK_ONLY:...>`.
Fixes: #20416
Teach the `$<TARGET_PROPERTY:...>` generator expression to check for a
new `TRANSITIVE_COMPILE_PROPERTIES` property in the target's link
closure to enable transitive evaluation of named properties through
the link closure, excluding entries guarded by `$<LINK_ONLY:...>`.
Issue: #20416
Regularize and fill out a documentation pattern from commit ddb9442f48
(GenEx: Fix TARGET_PROPERTY evaluation of transitive link properties,
2024-04-22).
In commit 835f34949e (Help: Update cmake-buildsystem(7) build and usage
requirements, 2024-04-23) we labeled the sections documenting `COMPILE_*`
properties as "build properties". All the properties it documents are
about compilation steps before linking, including the Autogen features
for compiling Qt metadata, so rename the sections as "compile properties".
This is also consistent with the name of the `$<COMPILE_ONLY:...>`
generator expression.
In commit bbba701899 (Link properties: must be transitive over private
dependency on static library, 2019-12-06, v3.17.0-rc1~323^2) and
commit af9d4f24ae (Link properties: must be transitive over private
dependency on static library, 2019-12-11, v3.17.0-rc1~305^2) we
neglected to implement CMP0099 NEW behavior for `TARGET_PROPERTY`
evaluation. Add policy CMP0166 to fix this.
Marc Chevrier
Tyler Yankee
15daksh-2003
Mickaël Germain
scivision
Kyle Edwards
Peter Kokot
Craig Scott
xndcn
Brad King
Martin Duffy
Alex Turbov
Nikita Nemkin
Timothy Finnegan
Michael Herwig
Deniz Bahadir