cmake_path(IS_PREFIX) and $<PATH:IS_PREFIX> treated an empty path as a
prefix of every path, including another empty path, following
std::filesystem::path. A prefix that is empty because a variable was
set to an empty value, or because a generator expression argument
expanded to nothing, therefore satisfied a check meant to reject it.
Return false for an empty prefix, in cmCMakePath::IsPrefix so that every
caller shares one implementation and both the plain and NORMALIZE forms
are covered. Normalizing an empty path leaves it empty, so no separate
handling of NORMALIZE is needed. Unlike the component comparison, which
follows std::filesystem::path deliberately, IsPrefix has no counterpart
in the standard: it borrows path iteration but the predicate itself is
defined by CMake, so an empty prefix is a gap to fill rather than a
standard answer to override.
Add policy CMP0223 and restore the old result behind it at the two
released surfaces. The other callers of IsPrefix, source_group() and
the Makefile generator's source classification, take the new behavior
ungated: source_group() rejects an empty TREE argument before reaching
it, and the generator passes the source and binary directories.
The if(PATH_IS_PREFIX) operator, new in this same release, follows the
policy too rather than simply taking the new behavior, so that it agrees
with cmake_path(IS_PREFIX) in every policy state and the parity
assertions in its test hold unconditionally.
Fixes: #28077
Adjust documentation of `install(CODE|SCRIPT)` to more understandably
reflect how the subcommand actually operates. Adjust argument parsing of
the same to "accept" the `COMPONENT` argument being given more than
once, consistent with how single-valued arguments are usually parsed.
Testing whether one path is a prefix of another is possible today with
cmake_path(IS_PREFIX), but the idiom needs a separate statement plus a
scratch variable and takes the prefix as a variable name, so projects
reach for if(path MATCHES "^${prefix}") instead. That is wrong whenever
the prefix contains a regex metacharacter, and it accepts siblings,
because '^/a/b' matches '/a/bc'.
Add a binary operator where the left operand is the candidate prefix and
the right is the path, matching the operand order of cmake_path(IS_PREFIX)
and $<PATH:IS_PREFIX> so that the same operation reads the same way on all
three surfaces. Neither operand is normalized, matching the default of
cmake_path(IS_PREFIX) and the existing PATH_EQUAL operator, so '.' and
'..' are compared as ordinary components. The test is non-strict, purely
lexical, and applies no relative-to-absolute reconciliation.
Add policy CMP0222 for compatibility, modeled on CMP0139. The keyword
is consumed as an operator only when it appears in the second argument
slot, so a variable named PATH_IS_PREFIX keeps working in unary and
left-operand position. What the policy covers is such a variable
appearing after another token, as in if(NOT PATH_IS_PREFIX AND other),
which becomes a configure error under NEW.
Since the operator is an if() spelling of cmake_path(IS_PREFIX) and shares
its implementation, test it by asserting the two agree over a corpus of
inputs rather than by restating expected values. Those are pinned by the
cmake_path(IS_PREFIX) test, so the operator's tests stay limited to what
has no command equivalent, and no platform branching is needed because
parity holds whatever the host path model answers.
Fixes: #28040
`DISTRIB_*` read os-release under `CMAKE_SYSROOT`, so cross builds got
the target distro from a host-oriented command, and a process-wide
static froze the first result. Add a `FROM_SYSROOT <bool>` option and
policy `CMP0221` to default to the host, parse per call, and scope
`CMAKE_SYSROOT` so the fallback scripts follow the same choice.
Fixes: #27640
Amends the documentation update in commit 24b76eaa93 (Help: Improve
readability and accuracy of runtime deps-related content, 2021-07-03,
v3.21.0-rc3~16^2).
Until a new feature is (potentially) implemented offering projects more
flexibility in this regard, the semantics around installation of
internal build-tree dependencies should be clarified, as it has caused
confusion on multiple occasions.
Issue: #28048
Installing a module target without a LIBRARY DESTINATION no longer
raises an error. On DLL platforms, the default destination is the
RUNTIME default. Otherwise, the LIBRARY default is used.
Closes: #27759
The TRANSFORM action registry held one live action instance per action for
the whole process, and each instance carried per-call state: a raw Selector
pointer, REPLACE's helper, APPEND/PREPEND's operands. That was harmless
while every action ran to completion uninterrupted, but commit c7af6e94d8
(list(TRANSFORM): Add PREDICATE selector, 2026-04-08, v4.4.0-rc1) added a
selector that runs a user function once per element, interleaved with the
transform. User code reentering list(TRANSFORM) with the same action now
rebinds the shared instance mid-flight. That produces silently wrong
results, and a use-after-free once any element is transformed after the
reentering one. It needs no unusual code to hit: a predicate calling
find_package(Python) reaches list(TRANSFORM ... REPLACE) inside FindPython's
own module.
Make action objects immutable and per-call. Operands and the selector become
constructor arguments, Initialize is deleted, and the registry becomes a
constexpr table of metadata with a MakeTransformAction factory. The
InSelection guard, duplicated in all eight actions, moves into the base class.
This also closes a second hole in the same machinery. TransformActionApply
overrode only the vector form of Initialize, so transform(APPLY, "f",
selector) dispatched to the empty two-argument virtual in the base, left
Selector null, and dereferenced it. With no virtual Initialize left to
inherit, an APPLY action without a cmMakefile is no longer constructible, so
the throwing stub that guarded the vector form is no longer needed.
Close a third, from commit 651f82642c (Add APPLY action for list(TRANSFORM),
2026-04-08, v4.4.0-rc1): the cmMakefile overload performs APPLY
unconditionally but validated only the arity of the action passed to it.
APPEND, PREPEND and APPLY all take one argument, so transform(APPEND, "x",
makefile) passed validation and then silently ran APPLY, calling "x" as a
function instead of appending it. Reject any action but APPLY up front.
That path is unreachable from CMake code, since HandleTransformCommand only
selects the overload for APPLY, and Tests/CMakeLib has no cmMakefile to drive
it with, so it carries no test.
Document the predicate's evaluation order while here. It runs once per
element, immediately before that element would be transformed. The manual
did not state the timing, which matters precisely because a predicate that
reenters list(TRANSFORM) observes the outer call mid-flight.
Fixes: #28031
Iterating a JSON array with GET re-parses the entire string on every
call, so walking N elements is O(N^2). ARRAY_SPLIT parses the array
once and returns its elements as a CMake list, letting each element be
queried individually in linear total time.
Each element is re-serialized as compact JSON and encoded to survive
CMake list parsing: '[' and ']' inside strings are emitted as \u005B
and \u005D, and ';' is escaped as '\;'. Every element therefore stays
valid, re-queryable JSON.
Fixes: #27985
Propagates variables set in enable_language() logic up variable scopes
so that the language can be used by targets in the ancestor directories.
Works through block() and function() scopes as well. The
add_subdirectory() call can be thought of as the effective call site for
enabling the language. The same holds for endblock() and the actual
function call.
Adds a policy CMP0220 to control this behavior. As the language is
"enabled" at each ancestor scope, the policy is checked. If OLD, the
language is not enabled at this scope and the ones above.
Closes: #27881#27508#27389
Related: #26751#27564
Introduce `CMD_STRICT` to act as a parent for warnings about allowed but
disrecommended usage. Introduce a warning that discourages use of
non-target directives (which modify the build environment for the entire
[sub]tree). Add notes to the official documentation recommending use of
target-specific alternatives. This has been accepted wisdom for quite
some time, but only some of the affected commands made any mention of
this in the documentation.
File sets have evolved to be more ubiquitous throughout a CMake build,
outside the scope of simply the target_sources command. Move general
information to the `cmake-buildsystem(7)` manual and keep only
reference information specific to the syntax of target_sources in its
command page. Sprinkle some more cross-references to the new location.
Fixes: #27900
Suggested-By: Marc Chevrier <marc.chevrier@gmail.com>
The ctest(1) command line allows repeating -L/-LE to form an AND
filter over test labels, but the ctest_test() and ctest_memcheck()
scripting commands accepted only a single INCLUDE_LABEL/EXCLUDE_LABEL
value, so a dashboard script could not express that filter.
The label-matching engine already stores the include/exclude
expressions as vectors and applies them with AND semantics; only the
command binding was single-value. Change both keywords to multi-value
(NonEmpty<vector<string>>) and hand the collected list straight to the
engine. ctest_memcheck() gains the same behavior for free, since it
inherits the option set.
Fixes : #27497
Move documentation added by commit 45623dd5f6 (cmake_language: Add
PRINT_TARGETS operation, 2026-06-26) to the end of the signature list
to make room for more print signatures.
Issue: #27513
Recent changes to the `target_sources()` docs changed the `<items>`
placeholders to `<source>` or `<files>` (for `FILE_SET` commands),
but the documentation still used "items" frequently, and even
`<items>` once.
Change all mentions of "items" to use terms that match the
corresponding placeholders, for consistency.
Recent changes to the `target_sources()` docs changed the `<items>`
placeholders to `<source>` or `<files>` (for `FILE_SET` commands),
but the documentation still used "items" frequently, and even
`<items>` once.
Change all mentions of "items" to use terms that match the
corresponding placeholders, for consistency.
2c181bd60a GoogleTest: Drop newlines from test names
b464920acc string(STRIP): Document that it removes newlines
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12262
The install({TARGETS, EXPORT}) versions of the command now accept ALIAS
targets. The behavior is identical to what would happen if the name of
the target that the ALIAS references were put instead. The
export(TARGETS) command also has the same support and behavior for ALIAS
targets now.
Closes: #20979
17094eb572 ALIAS: Add test for generator expressions with ALIAS targets
5f8cc64695 ALIAS: Add support for add_dependencies for ALIAS targets
79e421b053 ALIAS: Add support for target_* commands
3b327695aa ALIASED_TARGET: Make property read-only
a121419908 ALIAS: Add support for set_property and set_target_properties commands
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12207
The add_dependencies command currently accepts ALIAS targets for
<target-dependencies> which resolve to the referenced target. This further
relaxes the command to accept an ALIAS <target> where the command will
add the dependencies to the target which the alias references.
Now that set_property and set_target_properties support ALIAS targets,
we need to extend support to all the target_* type commands that modify
target properties.
Relaxes target_compile_definitions, target_compile_features,
target_compile_options, target_include_directories,
target_link_directories, target_link_libraries, target_link_options,
target_precompile_headers, and target_sources to now accept ALIAS
targets. These commands set properties on the target which the alias
references.
Currently, getting properties from an ALIAS target retrieves the property
from the target which the alias references while setting properties results
in an error. This relaxes set_property and set_target_properties to
accept ALIAS targets and act on the referenced target, mirroring the get
behavior.
An error is raised when setting ALIAS_GLOBAL or ALIASED_TARGET on an ALIAS
target.
Closes: #19445
Add an --out-of-date option to ctest which runs only those tests with
recorded build dependencies whose timestamps are newer than the timestamp
at which the test last finished.
Fixes: #27614