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
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
They don't support setting compiler via this variable, they use the
toolsets, so you could switch the compiler by choosing another toolset.
Closes: #21644
As of commit ed48feeae8 (clang-cl: Add support for C++ modules,
2026-03-27, v4.4.0-rc1~428^2) CMake tries to support modules for
clang-cl, which can mostly be accomplished, except for the ClangCl VS
toolset, where the /scanDependencies flag is not yet supported.
Amend commit 3022f0363f (VS: set ScanSourceForModuleDependencies at
vcxproj level, 2024-04-27, v3.28.5~3^2) to only emit this setting when
scanning is supported by the toolchain.
Fixes: #27957
Issue: #27977
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.
Four per-format version descriptions in cmake-instrumentation.7.rst
still claimed the data version is always 1.0, contradicting both the
authoritative Data Version paragraph (which says 1.1) and the JSON
schemas (which accept minor versions 0 and 1).
Replace the hardcoded version claims with a reference to the Data
Version section, so these lines remain correct as future minor
versions are added without requiring additional doc updates.
Fixes: #27889
Add an existence check to the `if` command for diagnostic categories,
mirroring the check for policies. Aside from being desirable for
consistency's sake, this will make it easier for users to write logic to
manipulate diagnostics from newer versions of CMake that don't exist
today.
Prior to this commit, ctest would sometimes use the current working directory
as its binary directory rather than honoring `binaryDir` from a configure
preset. This would occur when using ctest in dashboard client mode to perform
an initial configuration with a preset.
`ctest --source-dir=<dir> -T Configure -D CTEST_PRESET=<preset>`
An explicit `--build-dir` still takes precedence over the preset's `binaryDir`.
Brad King
Tyler Yankee
leha-bot
Joerg Bornemann
Evan Wilde
Mickaël Germain
Marc Chevrier
FeRD (Frank Dana)
Aiden Woodruff
Vito Gamberini
Daksh Mamodiya
Matthew Woehlke
Zack Galbreath
Martin Duffy