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 c3c95f3010 (GoogleTest: Avoid generation error on duplicate
target test discovery, 2026-07-14, v4.4.1~24^2) has added a level of
indentation which made rebasing other changes harder than necessary.
Avoiding an else branch after a return command allows keeping the
original indentation.
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
e4a37fbf15 Tests/RunCMake/Swift: Add CMP0195 behavior checks
b7a78568c3 CMP0215: Update NEW behavior to require CMP0157/CMP0195 to be NEW
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12407
With AUTOGEN_BETTER_GRAPH_MULTI_CONFIG enabled, the per-config
'<ORIGIN>_autogen/timestamp_<CONFIG>' file was added to the origin target
as a bare file name, which resolves against the source directory. The
origin target therefore carried a source file that no rule creates, and
the build system could not trace the timestamp file back to the custom
command that creates it. Under the Visual Studio generators the bogus
path shows up as a <None> item in the project file.
Use the full path instead.
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
Follow up commit ed48feeae8 (clang-cl: Add support for C++ modules,
2026-03-27, v4.4.0-rc1~428^2). Prevent clang-cl from interpreting
absolute source paths as flags.
Fixes: #28036
Upstream libuv no longer supports these versions.
Follow up commit abac34eda2 (libuv: Restore support for macOS 10.x,
2026-03-05, v4.4.0-rc1~571^2~3). This leaves out macOS 10.4, since
a) it needs a lot more invasive changes, b) neither MacPorts nor my
PPCPorts support 10.4 anymore.
Signed-off-by: Sergey Fedorov <vital.had@gmail.com>
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
Fix commit 402d72b6c0 (OrangeC: Add support for compiling Windows
Resources, 2026-03-24, v4.4.0-rc1~444^2~1) to work for both C and CXX.
Inspired-by: Arha Gatram <agatram@nvidia.com>
Tyler Yankee
Brad King
Matthew Woehlke
leha-bot
Daniel Pfeifer
Kelvin Li
Joerg Bornemann
Evan Wilde
huangqinjin
Sergey Fedorov
Mickaël Germain
Marc Chevrier