# CMake 4.4.0-rc2 is ready for testing

**URL:** https://discourse.cmake.org/t/cmake-4-4-0-rc2-is-ready-for-testing/15724
**Category:** Announcements
**Created:** [June 22, 2026, 3:11pm UTC](https://discourse.cmake.org/t/cmake-4-4-0-rc2-is-ready-for-testing/15724 "2026-06-22T15:11:01Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![johnwparent](https://discourse.cmake.org/user_avatar/discourse.cmake.org/johnwparent/32/2179_2.png) [@johnwparent](https://discourse.cmake.org/u/johnwparent)
#### Post date: [June 22, 2026, 3:11pm UTC](https://discourse.cmake.org/t/cmake-4-4-0-rc2-is-ready-for-testing/15724/1 "2026-06-22T15:11:01Z")

</div>

I am proud to announce the second CMake 4.4 release candidate.  
[https://cmake.org/download/](https://cmake.org/download/)

Documentation is available at:  
[https://cmake.org/cmake/help/v4.4](https://cmake.org/cmake/help/v4.4)

Release notes appear below and are also published at  
[https://cmake.org/cmake/help/v4.4/release/4.4.html](https://cmake.org/cmake/help/v4.4/release/4.4.html)

Release milestone is available at:  
[release milestone](https://gitlab.kitware.com/cmake/cmake/-/milestones/194)

Some of the most significant changes in CMake 4.4 are:

- CMake diagnostic actions are now tracked in a new state type managed  
by the “cmake\_diagnostic()” command. The new system introduces several  
new diagnostic categories.

- “macro()” invocations now preserve backslashes in arguments. See  
policy “CMP0219”.

- “cmake(1)”, “ctest(1)”, and “cpack(1)” gained “–presets-file”  
arguments to support loading “presets” from the specified file.

- The Ninja Generators now support generating a build target named  
“test\_prep/\<test-name\>” for each test added by “add\_test()”, which  
builds all dependencies for that test. This behavior is enabled by  
the new “CMAKE\_TEST\_BUILD\_DEPENDS” variable.

- “cmake --install” now supports installing multiple components.

- The “discover\_tests()” command was added to support registering  
tests discovered at test time by “ctest(1)”. It runs a user-provided  
discovery command, parses its output, and generates test names,  
arguments, and properties from regular-expression captures.

- The “execute\_process()” command gained “ENVIRONMENT” and  
“ENVIRONMENT\_MODIFICATION” options to run child processes with a  
modified environment.

- A “SOURCES” file set type was added to specify a target’s source  
files via file sets.

- The “SCOPE”, “TYPE”, “BASE\_DIRS”, “SOURCES”, and “INTERFACE\_SOURCES”  
file set properties were added to provide the declared details of a  
file set.

- The “CMakePackageConfigHelpers” module’s  
“write\_basic\_package\_version\_file()” command now supports  
“SamePatchVersion”, “SameFullVersion”, and “SemanticVersion”  
compatibility modes.

- “ctest(1)” gained support for forwarding extra arguments to test  
executables using a “–” separator.

CMake 4.4 Release Notes

* * *

Changes made since CMake 4.3 include the following.

# New Features

## Diagnostics

- CMake diagnostic actions are now tracked in a new state type managed  
by the “cmake\_diagnostic()” command. This replaces the old system  
which sometimes used variables to manage reporting actions and  
sometimes did not allow management beyond command-line options and  
presets. The new system also introduces several new diagnostic  
categories and significantly reduces the cost of adding additional  
categories in the future. See the “cmake-diagnostics(7)” manual for  
a list of available categories.

- The “CMD\_INSTALL\_ABSOLUTE\_DESTINATION” diagnostic category was added  
to diagnose “install()” commands that specify an absolute  
“DESTINATION”. This diagnostic may be controlled with the  
“-Winstall-absolute-destination” command-line option, the  
“installAbsoluteDestination” field in a “CMake Presets” “warnings”  
object, or the “cmake\_diagnostic()” command.

## Presets

- “cmake-presets(7)” files now support schema version 12.

- “cmake(1)”, “ctest(1)”, and “cpack(1)” gained “–presets-file”  
arguments to support loading “presets” from the specified file  
instead of “CMakePresets.json” and/or “CMakeUserPresets.json”. See  
“cmake --presets-file”, “cmake --build --presets-file”, “cmake  
–workflow --presets-file”, “ctest --presets-file”, and “cpack  
–presets-file” for details.

- “cmake-presets(7)”, in schema version 12 and above, now expand the  
${fileDir} macro to the directory of the presets file containing the  
“${fileDir}” macro, regardless of whether it is inherited by another  
preset in a different directory.

- “cmake-presets(7)” gained support for a “testPassthroughArguments”  
field in the test preset “execution” object for forwarding arguments  
to test executables via presets.

## File-Based API

- The “cmake-file-api(7)” “codemodel” version 2 object has been  
updated to 2.11.

- The “cmake-file-api(7)” “codemodel” version 2 “target” object’s  
“sources” and “interfaceSources” objects gained new “fileSetIndexes”  
fields to support sources belonging to multiple file sets. The  
“fileSetIndex” fields are maintained for backwards compatibility  
only, and users are advised to port to the new fields.

- The “cmake-file-api(7)” “codemodel” version 2 “target” object’s  
“sources” object gained a new “backtraces” field to represent  
multiple command invocations which associate a single source for a  
given target with multiple file sets. The “backtrace” field is  
maintained for backwards compatibility only, and users are advised  
to port to the new field.

- The “cmake-file-api(7)” “codemodel” version 2 “installers” object’s  
optional “fileSetType” field gained a new “SOURCES” value to  
incorporate the new “SOURCES” file set type in codemodel replies.

## Instrumentation

- The “cmake-instrumentation(7)” data version has been updated to 1.1.

- “cmake-instrumentation(7)” gained a “captureOutput” option which  
collects the “stdout” and “stderr” of instrumented commands.

- “cmake-instrumentation(7)” gained a “compileTrace” option which  
records compiler-generated trace files (e.g., from Clang’s “-ftime-  
trace” flag).

## Generators

- The Ninja Generators now support generating a build target named  
“test\_prep/\<test-name\>” for each test added by “add\_test()”, which  
builds all dependencies for that test. Build dependencies are  
registered for an executable target invoked by the test, targets  
referenced in generator expressions in the test command, and  
explicit dependencies added using the new “BUILD\_DEPENDS” option.  
This behavior is enabled by the new “CMAKE\_TEST\_BUILD\_DEPENDS”  
variable. A “test\_prep/all” target is also generated to depend on  
every “test\_prep/\<test-name\>” target. Tests with names that are not  
valid target names are excluded from this behavior. If multiple  
tests in different directories share the same name, their  
dependencies are merged into one “test\_prep/\<test-name\>” target.

## Languages

- CUDA language level 23 (corresponding to C++ 23) is now supported  
with NVCC 13.3 and above.

## Compilers

- C++ 20 named modules are now supported with “clang-cl”. See “cmake-  
cxxmodules(7)”.

- The “ibm-flang” compiler is now supported with “compiler id”  
“IBMFlang”.

- The Pelles C toolchain is now supported with “compiler id”  
“PellesC”.

- The Open Watcom “wlink” linker is now identified with  
“CMAKE\_\<LANG\>\_COMPILER\_LINKER\_ID” “OpenWatcom”.

- The wild linker is now supported with  
“CMAKE\_\<LANG\>\_COMPILER\_LINKER\_ID” “WILD”.

## Command-Line

- “cmake(1)” now supports “–build \<dir\> --preset \<pre\>” regardless of  
the current working directory.

- The “cmake -D” command-line option now populates a default  
“HELPSTRING” for variables known to CMake.

- “cmake --install” now supports installing multiple components.

- “cmake --install” now accepts “-j\<N\>” in addition to “-j \<N\>” for  
specifying the number of parallel jobs.

- The “cmake -E” commands “copy\_if\_different”, “copy\_if\_newer”,  
“copy\_directory”, “copy\_directory\_if\_different”, and  
“copy\_directory\_if\_newer” gained support for the “-t” argument.

- The “cmake -E tar” command-line tool gained the “–cmake-tar-  
encoding” flag to specify the pathname encoding used in archives.

## Commands

- The “block()” command can now create a “DIAGNOSTICS” scope.

- The “cmake\_diagnostic()” command was added to manipulate CMake’s  
diagnostic state.

- The “cmake\_parse\_arguments()” command gained a new “PARSE\_ARGN”  
signature that starts parsing after the last named argument of the  
calling function and works exactly like “PARSE\_ARGV” with “\<N\>”  
being the number of parameters in the function definition.

- The “discover\_tests()” command was added to support registering  
tests discovered at test time by “ctest(1)”. It runs a user-provided  
discovery command, parses its output, and generates test names,  
arguments, and properties from regular-expression captures.

- The “execute\_process()” command gained “ENVIRONMENT” and  
“ENVIRONMENT\_MODIFICATION” options to run child processes with a  
modified environment.

- The “file(ARCHIVE\_CREATE)” and “file(ARCHIVE\_EXTRACT)” commands  
gained an “ENCODING” option to specify the encoding of the archive  
pathnames. The default is now “UTF-8”. See policy “CMP0213”.

- The “file(READ\_SYMLINK)” command gained a “RESULT” option to capture  
errors without failing.

- The “if()” command gained a new “DIAGNOSTIC” operator that evaluates  
to true if a given diagnostic category name is known to CMake.

- The “include()” command now has a “NO\_DIAGNOSTIC\_SCOPE” option.

- The “list(FILTER)” command gained a new “PREDICATE” mode that  
invokes a user-defined “function()” to decide which elements are  
included or excluded, complementing the existing “REGEX” mode.

- The “list(SORT)” command gained a new “COMPARATOR” keyword that  
invokes a user-defined “function()” to compare elements,  
complementing the built-in “COMPARE” methods.

- The “list(TRANSFORM)” command gained a new “APPLY” action that  
invokes a user-defined “function()” for each element of the list,  
enabling arbitrary per-element transformations.

- The “list(TRANSFORM)” command gained a new “PREDICATE” selector that  
invokes a user-defined “function()” to decide which elements are  
transformed.

- The “string(JSON … PARTIAL\_EQUAL)” command was added to compare  
two JSON values using _partial_ equality.

## File Sets

- A “SOURCES” file set type was added to specify a target’s source  
files via file sets.

- The “CXX\_SCAN\_FOR\_MODULES” file set property was added to control  
whether a file set’s sources are scanned for C++ modules.

- The “INDEPENDENT\_FILES” file set property was added to specify that  
a file set’s sources do not depend on any generated files.

- The “JOB\_POOL\_COMPILE” file set property was added to assign a file  
set’s sources to a specific Ninja job pool.

- The “SCOPE”, “TYPE”, “BASE\_DIRS”, “SOURCES”, and “INTERFACE\_SOURCES”  
file set properties were added to provide the declared details of a  
file set.

- The “SKIP\_LINTING” file set property was added to exclude a file  
set’s sources from target-wide code checks.

- The “SKIP\_PRECOMPILE\_HEADERS” file set property was added to avoid  
using precompiled headers for a file set’s sources.

- The “SKIP\_UNITY\_BUILD\_INCLUSION” file set property was added to  
exclude a file set’s sources from inclusion in unity builds.

## Variables

- The “CMAKE\_INSTALL\_DEFAULT\_COMPONENT\_NAME” variable gained support  
for a special “\<PROJECT\_NAME\>” placeholder value. It tells each  
“install()” invocation to take a default component name from the  
current “PROJECT\_NAME” variable value.

## Environment Variables

- The “CMAKE\_DISABLE\_PRECOMPILE\_HEADERS” environment variable was  
added to disable precompiled headers by default.

## Properties

- The “VERIFY\_INTERFACE\_HEADER\_SETS” and “VERIFY\_PRIVATE\_HEADER\_SETS”  
target properties now always create the per-target verification  
target and the aggregate “all\_verify\_interface\_header\_sets”,  
“all\_verify\_private\_header\_sets”, and “all\_verify\_header\_sets”  
targets when the property is enabled, even if the target has no  
matching header sets.

- The “VERIFY\_INTERFACE\_HEADER\_SETS” and “VERIFY\_PRIVATE\_HEADER\_SETS”  
target properties now support “OBJC” and “OBJCXX” languages in  
addition to “C” and “CXX”.

- The “VS\_SOLUTION\_DEPLOY” target property is now implemented for  
targets created by “add\_custom\_target()”.

## Modules

- The “CMakePackageConfigHelpers” module’s  
“write\_basic\_package\_version\_file()” command now supports  
“SamePatchVersion”, “SameFullVersion”, and “SemanticVersion”  
compatibility modes. The older “ExactVersion” mode is now documented  
as deprecated in favor of the more explicit “SamePatchVersion” and  
“SameFullVersion” modes. The “SemanticVersion” mode treats “0.y.z”  
versions more strictly than “1.y.z” and later versions.

- The “ExternalData” module gained an “ExternalData\_LINK\_MODE”  
variable to select an ordered list of file materialization modes for  
hard links, symbolic links, and copies.

- The “ExternalData” module gained an “ExternalData\_STATE\_ROOT”  
variable to store hash records outside “ExternalData\_BINARY\_ROOT”.

- The “ExternalProject” and “FetchContent” modules gained  
“CMAKE\_EP\_GIT\_CLONE\_RETRY\_COUNT” and  
“CMAKE\_EP\_GIT\_CLONE\_RETRY\_DELAY” variables to control “git clone”  
retries.

- The “FindCUDAToolkit” module now creates a “CUDA::sanitizer” target  
for the compute-sanitizer library.

- The “FindCUDAToolkit” module now provides an imported target for  
“cufilt” in CUDA 11.4 and above.

- “FindPython” and “FindPython3” modules gained the support of the  
Stable ABI for Free Threaded Python (“SABIT”) as specified by **PEP  
803**.

## Generator Expressions

- The “TARGET\_OBJECTS” generator expression now has an optional  
“SOURCE\_FILES:…” argument, which can take one or more source files  
as arguments, and will filter its output to only include objects  
built from those source files.

## Swift

- The Ninja Generators gained the “Swift\_SEPARATE\_MODULE\_EMISSION”  
target property, initialized by the  
“CMAKE\_Swift\_SEPARATE\_MODULE\_EMISSION” variable, to control whether  
importable Swift targets emit “.swiftmodule” from a dedicated build  
edge. Policy “CMP0215” enables this by default.

- The default “Swift\_MODULE\_NAME” now replaces hyphens with  
underscores, since hyphens are not valid in Swift module  
identifiers.

- Swift targets now have a package name by default. See policy  
“CMP0216”.

- The “Swift\_PACKAGE\_NAME” target property was added to specify a  
Swift package name.

- Swift targets on Windows now support the “$\<TARGET\_PDB\_FILE:…\>”  
family of generator expressions.

## CTest

- “ctest(1)” gained support for forwarding extra arguments to test  
executables using a “–” separator.

- “ctest(1)” gained a CoverageTool option in Dashboard Client mode to  
configure tests for coverage collection by “llvm-cov”.

- The “ctest\_configure()”, “ctest\_build()”, “ctest\_test()”, and  
“ctest\_memcheck()” commands gained “PRESET” and “PRESETS\_FILE”  
arguments to support using “presets” for their Dashboard Client  
steps.

- “ctest(1)” gained a “–source-dir” option to specify the source  
directory. When combined with “-T” Configure, this allows CTest to  
perform an initial configure step for an empty binary directory.

- “ctest(1)” gained support for a “CTEST\_SUBMIT\_PARTS” variable that  
restricts which parts are uploaded when operating in Dashboard  
Client mode.

- The “ctest\_update()” command gained “VERSION\_ONLY” and  
“VERSION\_OVERRIDE” options to select or report a source revision  
without requiring the corresponding “CTEST\_UPDATE\_VERSION\_ONLY” or  
“CTEST\_UPDATE\_VERSION\_OVERRIDE” dashboard script variables.

## CPack

- The “CPack Archive Generator” gained the “CPACK\_ARCHIVE\_ENCODING”  
variable to specify the pathname encoding used in package archives.

- The “CPack NSIS Generator” gained a new variable  
“CPACK\_NSIS\_IGNORE\_COMPONENTS\_PAGE” to ignore the component  
selection page in the installer.

- The “CPACK\_RPM\_SPEC\_MORE\_DEFINE” variable now supports a list of  
definitions.

# Deprecated and Removed Features

- The “-W[no-][error=]dev” command-line options are deprecated. The  
new spelling is “-W[no-][error=]author”.

- The “–warn-uninitialized” command-line option is deprecated. The  
new spelling is “-Wuninitialized”.

- The “–no-warn-unused-cli” command-line option is deprecated. The  
new spelling is “-Wno-unused-cli”.

- The “CMAKE\_WARN\_DEPRECATED” and “CMAKE\_ERROR\_DEPRECATED” variables  
are deprecated. The new “cmake\_diagnostic()” command should be used  
instead.

- The “MACROS” directory property does not exist anymore. See policy  
“CMP0217”.

# Other Changes

- A file may belong to at most one non-“HEADERS” file set in a target.  
See policy “CMP0211”.

- “macro()” invocations now preserve backslashes in arguments. See  
policy “CMP0219”.

- “variable\_watch()” callback command arguments preserve backslashes.  
See policy “CMP0219”.

- “ctest(1)” now exits with non-zero if invoked with no arguments and  
no test input file exists.

- Test drivers generated by the “create\_test\_sourcelist()” command now  
support the “-N” option to list all tests, one per line. This is  
useful in combination with the new “discover\_tests()” command.

- Names of executables given to the “DEPENDS” argument of  
“add\_custom\_command()” no longer have “.exe” suffixes stripped to  
establish target-level dependencies. See policy “CMP0212”.

- Targets which provide C++ modules may now be consumed by targets  
with different “compile features” and “options” than the provider.

* * *

Changes made since CMake 4.4.0-rc1:

Ben Boeckel (1):

- Clang-FindBinUtils: find unprefixed `clang-scan-deps` binaries as well

Brad King (3):

- Help: Add release note for the instrumentation version format change in 4.3.4
- ExternalProject: Fix ENVIRONMENT\_MODIFICATION with spaces in values
- CMake 4.4.0-rc2

Daksh Mamodiya (1):

- file(ARCHIVE\_EXTRACT): Fix resource leaks on error paths

Jakob Ronestjärna (1):

- ExternalData: Remove redundant debug message

James Miro (1):

- FindDoxygen: Avoid leaking child process stderr

John Parent (1):

- Help: Restore sphinx pre-5.0 compatibility

Matthew Woehlke (3):

- Exports: Capture context for diagnostics
- CPS: Fix crash when package `requires` isn’t an object
- if: Add `DIAGNOSTIC <category>` condition

Ottmar Zittlau (1):

- GoogleTest: Avoid cluttering custom working directory during discovery

Tyler Yankee (2):

- Tests/instrumentation: Check errors for query schema validation
- instrumentation: Add JSON schema for snippet files

Zack Galbreath (2):

- ctest: Honor preset binaryDir for initial configuration
- ctest: Pass CTEST\_SITE/CTEST\_BUILD\_NAME to configure step

---

<div class="post-metadata">

### Author: ![LegalizeAdulthood](https://discourse.cmake.org/user_avatar/discourse.cmake.org/legalizeadulthood/32/5282_2.png) [@LegalizeAdulthood](https://discourse.cmake.org/u/LegalizeAdulthood)
#### Post date: [June 22, 2026, 5:02pm UTC](https://discourse.cmake.org/t/cmake-4-4-0-rc2-is-ready-for-testing/15724/2 "2026-06-22T17:02:25Z")

</div>

@brad.king Did the improved diagnostics for cmake presets make it into this release?

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [June 22, 2026, 11:02pm UTC](https://discourse.cmake.org/t/cmake-4-4-0-rc2-is-ready-for-testing/15724/3 "2026-06-22T23:02:27Z")

</div>

> [@LegalizeAdulthood](#):
>
> Did the improved diagnostics for cmake presets make it into this release?

[CMake MR 11987](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/11987) is in 4.4, yes.

---

<div class="post-metadata">

### Author: ![LegalizeAdulthood](https://discourse.cmake.org/user_avatar/discourse.cmake.org/legalizeadulthood/32/5282_2.png) [@LegalizeAdulthood](https://discourse.cmake.org/u/LegalizeAdulthood)
#### Post date: [June 23, 2026, 2:15pm UTC](https://discourse.cmake.org/t/cmake-4-4-0-rc2-is-ready-for-testing/15724/4 "2026-06-23T14:15:43Z")

</div>

I keep wondering when I’ll rate an appearing in the changelog `:)` (not a big deal, just easier to see when my contributions are shipping)

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [June 23, 2026, 2:20pm UTC](https://discourse.cmake.org/t/cmake-4-4-0-rc2-is-ready-for-testing/15724/5 "2026-06-23T14:20:38Z")

</div>

> [@LegalizeAdulthood](#):
>
> I keep wondering when I’ll rate an appearing in the changelog

Changes that don’t affect user-facing documented interfaces often don’t get change logs.

FYI, the release notes are added incrementally in the MRs that make the corresponding changes and then consolidated once later. If a MR doesn’t have a release note we’ll ask for one during review if appropriate. If not, then it’s unlikely one will be added later.

> [@LegalizeAdulthood](#):
>
> just easier to see when my contributions are shipping

All merge requests are assigned a milestone indicating the version that will include them.

---

<div class="post-metadata">

### Author: ![LegalizeAdulthood](https://discourse.cmake.org/user_avatar/discourse.cmake.org/legalizeadulthood/32/5282_2.png) [@LegalizeAdulthood](https://discourse.cmake.org/u/LegalizeAdulthood)
#### Post date: [June 25, 2026, 1:40pm UTC](https://discourse.cmake.org/t/cmake-4-4-0-rc2-is-ready-for-testing/15724/6 "2026-06-25T13:40:54Z")

</div>

Improved diagnostics aren’t considered user-facing?

I just think it’s important to let people know that one of the pain points around presets has been alleviated. Whether my name is attached isn’t important, TBH.