The implementation in commits 77312cc6 (CUDA: Add support for
[CMAKE_]CUDA_LINKER_LAUNCHER, 2025-05-30, v4.1.0-rc1~80^2~1) and
cdf2a36f (HIP: Add support for [CMAKE_]HIP_LINKER_LAUNCHER, 2025-05-30,
v4.1.0-rc1~80^2) is broken, and the tests are wrongly configured
so as to never actually run. Revert the entire feature to avoid future
confusion, including documented support.
Enable the test for Fortran, which was added but untested by commit
d176a8c5ce (Fortran: Add support for [CMAKE_]Fortran_LINKER_LAUNCHER,
2025-05-26, v4.1.0-rc1~96^2), and whose implementation works.
Issue: #26967
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
Revert commit a324c2bb58 (GoogleTest: Base on builtin command
discover_tests, 2026-03-01, v4.4.0-rc1~30^2). The `discover_tests`
implementation does not persist already-discovered tests across ctest
runs, making it much slower on projects whose test binaries take a while
just to start up and list tests. Revert to the prior implementation
pending caching support in `discover_tests`.
Fixes: #28053
Issue: #28060
Commit 680fbb112a (Autogen: Enable depfile support for Visual Studio and
Xcode generators) disabled the PRE_BUILD optimization when a depfile is
used, because a PRE_BUILD event cannot carry depfile dependencies. Since
then, every target with AUTOMOC or AUTOUIC enabled gains an
'<ORIGIN>_autogen' and an '<ORIGIN>_autogen_timestamp_deps' target,
which the Visual Studio generators turn into two extra projects per
target in the generated solution.
Attach the autogen custom command to the origin target instead. The
custom command still carries the depfile, and the dependencies of the
origin target provide the ordering that
'<ORIGIN>_autogen_timestamp_deps' provides otherwise, because MSBuild
builds all referenced projects before any step of the referencing
project.
Use the conditions of the PRE_BUILD event, so that the
'<ORIGIN>_autogen' target keeps existing wherever it existed before
depfiles were enabled for the Visual Studio generators. In particular,
projects that name the target in add_dependencies() keep working.
Ninja and the Makefile generators keep the separate targets. Extra
targets have no cost for them, and '<ORIGIN>_autogen' has always existed
there.
The Xcode generator gained the same two targets per origin target in
4.4, but attaching the custom command there needs some more thoughts on
the per-config timestamp file first: Xcode rejects targets whose sources
vary by configuration, and with AUTOGEN_BETTER_GRAPH_MULTI_CONFIG the
timestamp file is per configuration.
Fixes: #28034Fixes: #28033
Adding checks to ensure that CMP0195 has the desired effect. If the
Swift compiler is too old and does not include the module triple in the
emitted target info, we won't set `CMAKE_Swift_MODULE_TRIPLE` and end up
with the flat directory structure. In this case, these tests won't have
the expected layout.
Issue: #28021
Update CMP0215 to avoid attempting to iterate through the flags
looking for `-emit-module-path` ins the user-specified flags. We don't
do this anywhere else in the code. The existing implementation didn't
handle correctly parsing the flag so `-I blah/my-emit-module-path/` and
`-Xcc -emit-module-path ...` would both trigger it, result in the
compiler not emitting any module. Furthermore, it didn't include the
user-specified module path as part of the build graph resulting in an
incorrect build graph that would never resolve.
The only two appropriate layouts for the module are either the flat
binary module file with the name `<module-name>.swiftmodule`, or the
nested form with
`<module-name>.swiftmodule/<module-triple>.swiftmodule`. The noted
Swift-Syntax situation passes the explicit `-emit-module-path` to get to
the latter form. This form is automatically emitted by CMake when
CMP0195 is `NEW`, removing the need for the flag. The Swift project
generally recommends the nested directory structure since it gathers all
of the generated interface outputs from the compiler (textual swift
interfaces, swiftdoc, sourceinfo, and the binary swiftmodule file) in a
single place, and since it uses the module triple in the filename,
cleanly allows fat mach-o binaries on Apple platforms.
Fixes: #28021
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
Commit 7644d557df (Check*: Refactor variable handling, 2026-07-20,
v4.4.1~12^2~1) introduced a subtle regression in the handling of
`CMAKE_REQUIRED_LINK_OPTIONS` and `CMAKE_REQUIRED_LIBRARIES` which
resulted in an error if these were set to a 'false-like' value. This
could happen, for example, if the user passes `<name>_LIBS`, which
happens to have the value `<name>-NOTFOUND`. Previously, such values
would be ignored.
Fix it by separately checking for user- or module-provided link options
or link libraries. (We were already doing this for the other variables
used to propagate requirements into checks.)
Fixes: #28026
Commit a72e241200 (Check*: Restore more toleration of `;-W...` in
CMAKE_REQUIRED_FLAGS, 2026-07-21) updated the Check* modules to share
required-flag handling without adding coverage for those paths.
Exercise each probe with required definitions followed by a warning
option.
Without the compatibility handling, CMake rejects the warning option.
Without the required definitions, all seven checks fail to find their
header, functions, prototype, or type.
Issue: #28001
These tests experience frequent timeouts in CI, which are either actual
timeouts due to low resource runners, or a platform-specific bug
causing an indefinite hang. Either way, it's beneficial to locate these
in their own test suite to reduce noise and ensure the rest of the
tests pass regularly.
The tests added in commit d92b6c3e20 (CPS: Add Symbolic Components,
2025-09-01, v4.2.0-rc1~48^2~1) had an inverted conditional, such that
they passed if the output did NOT match what was expected. The expected
expressions were also improperly escaped, which "canceled" this error,
allowing the tests to erroneously pass. Fix both of these errors.
The prior mechanism for reconciling cached diagnostic state with updates
from presets / command-line arguments based on whether the latter
modified diagnostics from their default state did not work. This is
because alterations that would not change the state relative to the
default were not recorded, even if they would alter the state relative
to the prior (cached) state.
The best fix for this is to apply alterations on top of the cached
state, rather than trying to determine whether an alteration is
important. Unfortunately, the only way to do this is to defer
alterations until after we can load the cache, which somewhat defeats
one of the original goals of reducing the number of mechanisms by which
alterations are recorded.
Modify how we handle diagnostic alterations to map them through a helper
function, which either defers them (in Project mode) or acts as a
pass-through (applying the changes immediately, in all other modes).
While this does, as noted, introduce another means of storing
diagnostics, this new storage effectively consists of a list of deferred
function calls, rather than a unique format for recording changes, which
is what we had prior to the Great Refactor.
Prior to commit 243462fafe (try_compile: Tolerate compile features from
non-enabled languages, 2026-05-18, v4.4.0-rc1~84^2) we accidentally
tolerated toolchain files setting `CMAKE_<LANG>_COMPILER_LOADED`.
Meson accidentally relied on this, so restore toleration of it.
Fixes: #27971
The discovery script created by commit 3748ca9f (GoogleTest: generate
single discovery script, 2026-04-08, v4.4.0-rc1~302^2~1) creates
generate-time collisions if gtest_discover_tests() is called on the
same target in the same directory with the same arguments multiple
times. Handle the case with a warning to preserve compatibility with
existing projects.
Fixes: #27940
Commit 433721b7a7 (ctest: Pass CTEST_SITE/CTEST_BUILD_NAME to configure
step, 2026-06-15) updated ctest_configure() to pass `-DSITE=...` and
`-DBUILDNAME=...` to the configure command whenever CTEST_SITE or
CTEST_BUILD_NAME are set. Projects that don't include the CTest module never
reference these cache variables, causing CMake to report an unused-cli warning.
Use `-C <initial-cache>` instead of `-D` to seed SITE/BUILDNAME. Cache entries
set using `-C` are not tracked by CMake's unused-cli diagnostic, so projects
using the CTest module still get DartConfiguration.tcl populated correctly,
while projects that never reference SITE/BUILDNAME no longer see the warning.
Fixes: #27953
Restore the logic from commit 6680df042e (GoogleTest: Avoid POST_BUILD
race condition for gtest_discover_tests(), 2025-10-26, v4.2.0-rc2~15^2)
that was lost in the refactoring in commit 3748ca9fc7 (GoogleTest:
generate single discovery script, 2026-04-08, v4.4.0-rc1~302^2~1). Add
a regression test.
Fixes: #27939, #27319, #27972
Restore the ordering before the refactoring in commit 0f20ba5b68
(Ninja: Swift: Extract helpers and reorder module flags, 2026-04-10,
v4.4.0-rc1~273^2~1) to ensure the correct precedence with launchers.
Add regression tests.
Fixes: #27931, #27934
- Forward the '--presets-file <file>' arguments to each workflow step.
- Ensure tests do not auto-set CMakePresets.json
- Fix typos in test names
Fixes: 27932
When the build is invoked under the native build tool's (commonly
spelled) `-C` option to change from the current working directory to a
given build tree, the default path to a snippet's `-ftime-trace` file
under its corresponding target's object directory was incorrectly
stored based on the path from the working directory.
File sets currently have issues with files containing semicolons;
particularly, names get mangled differently in different contexts. This
can result in failing to find a file's file set. Prior to dee8799d16
(FileSet management: Introduce dedicated classes for generation,
2026-02-16, v4.4.0-rc1~691^2), we guarded against this, but the
aforementioned commit introduced code that would try to use the found
fileset object without checking if it was valid. Add the missing checks
so that we do not crash trying to dereference a null pointer. Also,
refactor `cmGeneratorTarget::GetSourceFilePaths` to avoid unnecessary
work.
Fixes: #27924
Tyler Yankee
Matthew Woehlke
Daniel Pfeifer
Brad King
Joerg Bornemann
Evan Wilde
Mickaël Germain
Josef Šimánek
Vito Gamberini
Martin Duffy
Zack Galbreath
Marc Chevrier
Kyle Williams
Jocó Mihalicza