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
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.
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
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>
Since commit 302a645d73 (CPack/DEB: use `triggers` instead of legacy
postXXX scripts for `ldconfig`, 2026-03-05, v4.4.0-rc1~583^2) the
`triggers` feature refers to `DPKG_EXECUTABLE` if the latter is defined.
Unfortunately, it is defined only if one particular execution branch has
executed. Move the `find_program(dpkg)` to the function scope to make
it available in all execution branches.
Prior to porting `gtest_discover_tests` to `discover_tests` it silently
tolerated an unpaired property name. `discover_tests` does not support
that, so remove the unpaired argument. Also add a warning to help
projects avoid such usage.
Fixes: #28004
Refactoring in commit a72e241200 (Check*: Restore more toleration of
`;-W...` in CMAKE_REQUIRED_FLAGS, 2026-07-21, v4.4.1~12^2) changed the
pattern that `Check*` modules use to forward `CMAKE_REQUIRED_FLAGS` to
`try_compile` calls. However, it accidentally left out part of the new
pattern in the `CheckSymbolExists` module. Fix that and add tests.
Fixes: #28001
Commit 5abaf65154 (Check*: Restore toleration of `;-W...` in
CMAKE_REQUIRED_FLAGS, 2026-06-24, v4.4.0-rc3~2^2) introduced logic to
prevent `-W*` arguments in `CMAKE_REQUIRED_FLAGS` from being passed as
CMake arguments in the `check[_<lang>]_source_{compiles,runs}` family of
utilities. However, several other related modules are also affected.
Update those to also use the new logic, and to have more uniform
implementations, making use of the refactoring from the previous commit.
Fixes: #27961
Commit 5abaf65154 (Check*: Restore toleration of `;-W...` in
CMAKE_REQUIRED_FLAGS, 2026-06-24, v4.4.0-rc3~2^2) introduced logic to
prevent `-W*` arguments in `CMAKE_REQUIRED_FLAGS` from being passed as
CMake arguments. It was never the intent of `CMAKE_REQUIRED_FLAGS` to
support such usage; however, since older versions of CMake would
silently accept such arguments, some users were unintentionally passing
compiler warnings as CMake arguments. Although this usage is incorrect,
it was silently tolerated until CMake 4.4, which began treating unknown
`-W*` as an error.
Because it turns out that modules besides `CheckSource{Compiles,Runs}`
are affected, we are going to need the logic added by that commit in
many more places. As a first step toward accommodating that need, move
the logic to a new internal helper. While we're at it, try to generally
consolidate the common logic for handling the various variables that the
`Check*` family of modules uses for injecting arguments into the
ultimate `try_compile` calls.
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
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
Tcl/Tk 9.0.0 was released[1] in 2024, and is already up to version
9.0.4 (just released 2026-07-26).
Tcl/Tk 9.1 is currently nearing beta,[2] and will likely release soon.
Since it's still possible to have both of these libraries installed
without Tclsh or Wish (making version detection via those tools
unviable), add 9.0 and 9.1 variants to the explicit library/include
path and file matches performed by FindTCL.
Also add 9.0 and 9.1 patterns to the tool detections in FindTclsh,
FindTclStub, and FindWish.
[1]: https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/
[2]: https://sourceforge.net/projects/tcl/files/Tcl/9.1b0/
Version 8.7 of Tcl/Tk never made it past alpha status.
What was briefly labeled 8.7a5 eventually released as 9.0.0.
And in FindTclStub, also remove patterns for ttkstub8.8, which
even more than 8.7 never actually existed.
The `CMAKE_REQUIRED_FLAGS` variable, used by the various entry points to
`cmake_check_source_{compiles,runs}`, specifies that flags shall not be
separated by semicolons. This is because the way in which it is passed
to the child `cmake` process means that, when considered as a list (with
semicolon separated items), only the first item is actually used as
compile flags, with any additional items actually seen as arguments to
the child `cmake` process. While this usage is unsupported, if invoked
accidentally, flags starting with `-W` were silently ignored by CMake.
However, CMake 4.4 newly complains about unrecognized warning
categories, which means that uses which were silently broken now result
in a hard error.
In the longer term, it would be helpful to introduce a policy to repair
improper use of semicolons in `CMAKE_REQUIRED_FLAGS` in order to do what
the user probably meant. However, for various reasons, we do not want to
introduce a policy to CMake 4.4 at this time, and anyway, the policy
won't help users that haven't enabled it. Therefore, alter the 'check
source' functions to detect arguments being passed to `cmake` rather
than the compiler, and remove any such that start with `-W`. This
removes any arguments that newly cause errors starting with CMake 4.4,
while not otherwise altering behavior in case any users were abusing
this implementation quirk.
Strictly speaking, this means that users can no longer abuse this quirk
to alter CMake's diagnostics. However, the only case in which this
should be observable is if the user is already abusing the quirk to
inject their own CMake logic into the CMake-provided test projects.
Since this was never supported, anyone doing that can keep the pieces.
Issue: #27901Fixes: #27893
Revise commit eb8cb2c6c2 (Fortran: Detect pointer size on Intel archs
with PGI, 2014-04-10, v3.0.0-rc4~4^2) to consider more variants of the
architecture macros.
Revise commit cfbf0480ff (Sunway: Add sw_64 support, 2025-08-05,
v4.2.0-rc1~373^2) to use the same set of preprocessor definitions for
all languages, and to order them consistently w.r.t. other archs.
In commit 32a5f11e50 (FindOpenGL: respect legacy preference for OpenGL
and GLX libraries, 2025-10-31, v4.3.0-rc1~544^2) the result variables
were spelled incorrectly. Also re-order logic to preserve the CMP0072
warning text naming the GLVND libraries.
Fixes: #27299