# CMake 3.30 Release Notes

Changes made since CMake 3.29 include the following.

## New Features

### Presets

- `cmake-presets(7)` files now support schema version `9`. `include` fields now expand all macros except `$env{}` and preset-specific macros, i.e., those derived from the fields inside a preset's definition.

### File-Based API

- The `cmake-file-api(7)` "cmakeFiles" version 1 object's `version` field has been updated to 1.1. It gained a `globsDependent` field to report `file(GLOB)` calls using `CONFIGURE_DEPENDS`.

### Generators

- Visual Studio Generators now add `UseDebugLibraries` indicators to `.vcxproj` files to denote which configurations are debug configurations. See policy `CMP0162`.

### Languages

- The `Compile Features` functionality now implements support for the `cxx_std_26` and `cuda_std_26` meta-features to indicate that the compiler mode must be at least C++26. These meta-features were first documented by CMake 3.25, but were not fully implemented.

### Commands

- The `add_library()` command, on platforms that do not support shared libraries, now rejects creation of shared libraries instead of automatically converting them to static libraries. See policy `CMP0164`.

- The `enable_language()` command now fails with an error if it is called before the first `project()` call. See policy `CMP0165`.

- The `file(DOWNLOAD)` and `file(UPLOAD)` commands gained a `TLS_VERSION <min>` option to specify the minimum TLS version for connections to `https://` URLs.

### Variables

- The `CMAKE_<LANG>_STANDARD_LATEST` variable was added to describe the latest `<LANG>` language standard CMake supports for the selected compiler.

- The `CMAKE_TLS_VERIFY` environment variable was added as a fallback to the existing `CMAKE_TLS_VERIFY` variable. It specifies whether to verify the server certificate for `https://` URLs by default.

- The `CMAKE_TLS_VERSION` variable and `CMAKE_TLS_VERSION` environment variable were added to specify a default minimum TLS version for connections to `https://` URLs by the `file(DOWNLOAD)` and `file(UPLOAD)` commands.

- The `CMAKE_VS_USE_DEBUG_LIBRARIES` variable and corresponding `VS_USE_DEBUG_LIBRARIES` target property were added to explicitly control `UseDebugLibraries` indicators in `.vcxproj` files.

### Properties

- The `GENERATED` source file property is now visible in all directories. See policy `CMP0163`. Policy `CMP0118`'s documentation has been revised to describe its actual effects.

- The `PROPAGATE_TOP_LEVEL_INCLUDES_TO_TRY_COMPILE` global property can be used to propagate `CMAKE_PROJECT_TOP_LEVEL_INCLUDES` into `try_compile()` calls that use the whole-project signature. This is primarily intended as a way for dependency providers to be enabled in such `try_compile()` calls.

- A `VS_FILTER_PROPS` target property was added to tell Visual Studio Generators to use a custom MSBuild filter `.props` file.

### Modules

- The `ExternalProject` module's `ExternalProject_Add()` command gained a `TLS_VERSION <min>` option, and support for the `CMAKE_TLS_VERSION` variable and `CMAKE_TLS_VERSION` environment variable, to specify the minimum TLS version for connections to `https://` URLs.

- The `FindBacktrace` module now provides an imported target.

- The `FindBLAS` and `FindLAPACK` modules gained support for `libblastrampoline`.

- The `FindCUDAToolkit` module now provides a target for `libnvfatbin` and `libnvfatbin_static`, if found.

- The `FindCUDAToolkit` module now searches the `CMAKE_CUDA_COMPILER` variable and the `CUDACXX` environment variable even when the `CUDA` language isn't enabled.

- The `FindOpenMP` module gained an `OpenMP_RUNTIME_MSVC` option to control the OpenMP runtime used with MSVC.

- The `FindPython` and `FindPython3` modules gained support for the free threaded Python version.

- The `FindPython`, `FindPython2`, and `FindPython3` modules, on Windows, now offer better support for the Python debug variant:

  - new variables:

    - `Python_EXECUTABLE_DEBUG`

    - `Python_INTERPRETER`

    - `Python_DEBUG_POSTFIX`

  - new targets:

    - `Python::InterpreterDebug`

    - `Python::InterpreterMultiConfig`

  The `python_add_library()` command now manages the `DEBUG_POSTFIX` target property based on the value of the `Python_DEBUG_POSTFIX` variable.

### Generator Expressions

- The `<LANG>_COMPILER_FRONTEND_VARIANT` family of generator expressions were added to access the value of the associated `CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT` variables.

- Link features, as used with the `LINK_LIBRARY` generator expression, gained the ability to have attributes that describe their behavior by specifying the `CMAKE_LINK_LIBRARY_<FEATURE>_ATTRIBUTES` or `CMAKE_<LANG>_LINK_LIBRARY_<FEATURE>_ATTRIBUTES` variables.

- The `QUOTE` generator expression was added to evaluate to `"`.

- The `TARGET_PROPERTY` generator expression learned to evaluate custom transitive properties defined by new `TRANSITIVE_COMPILE_PROPERTIES` and `TRANSITIVE_LINK_PROPERTIES` target properties.

- The `TARGET_PROPERTY` generator expression now evaluates target properties `INTERFACE_LINK_OPTIONS`, `INTERFACE_LINK_DIRECTORIES`, and `INTERFACE_LINK_DEPENDS` correctly by following private dependencies of static libraries. See policy `CMP0166`.

### CTest

- The `ctest_submit()` command and `ctest -T Submit` step gained `TLSVersion` and `TLSVerify` options to control negotiation with `https://` URLs. See the `CTEST_TLS_VERSION` and `CTEST_TLS_VERIFY` variables.

### CPack

- The `CPack Inno Setup Generator` is now available on non-Windows hosts.

- The `CPack NuGet Generator` gained the `CPACK_NUGET_PACKAGE_README`, `CPACK_NUGET_PACKAGE_REPOSITORY_URL`, `CPACK_NUGET_PACKAGE_REPOSITORY_TYPE`, `CPACK_NUGET_PACKAGE_REPOSITORY_BRANCH`, and `CPACK_NUGET_PACKAGE_REPOSITORY_COMMIT` variables.

- The `CPack NuGet Generator` can now generate dependency groups for framework-specific dependencies. The `CPACK_NUGET_PACKAGE_TFMS` variable was added to specify a list of target framework monikers (TFMs) for which groups should be generated.

- The `CPack WIX Generator` gained support for WiX Toolset v4. See the `CPACK_WIX_VERSION` variable.

## Deprecated and Removed Features

- The `FindBoost` module has been removed by policy `CMP0167`. Port projects to upstream Boost's `BoostConfig.cmake` package configuration file, for which `find_package(Boost)` now searches.

- Calling `FetchContent_Populate()` with just the name of a dependency is now deprecated. Projects should call `FetchContent_MakeAvailable()` instead. See policy `CMP0169`. Calling `FetchContent_Populate()` with full population details rather than just a dependency name remains fully supported.

- The `Visual Studio 9 2008` generator has been removed.

## Other Changes

- The precompiled Windows `.msi` installers provided on cmake.org, when performing a fresh installation, now modify the system-wide `PATH` by default. When replacing an existing installation of 3.30 or later, the `PATH` modification preference is preserved by default.

- The official `.zip` source archive provided on cmake.org now uses LF newlines, instead of CRLF newlines, for consistency with modern conventions.

- The durations printed after "Configuring done" and "Generating done" messages now reflect time spent in generator-specific steps, and in a code model evaluation step at the beginning of generation that was not previously captured. Printed durations may appear longer than in previous versions of CMake, but are more accurate.

- `FetchContent` now prefers to populate content directly rather than using a separate sub-build. This may significantly improve configure times on some systems (Windows especially, but also on macOS when using the Xcode generator). `cmake --fresh` also forces the download, update, and patch steps of directly populated dependencies to be re-executed. Policy `CMP0168` provides backward compatibility for those projects that still rely on using a sub-build for content population.

- When `FETCHCONTENT_FULLY_DISCONNECTED` is set to true, `FetchContent_MakeAvailable()` and the single-argument form of `FetchContent_Populate()` require that the dependency's source directory has already been populated. CMake 3.29 and earlier did not check this requirement, but it is now enforced, subject to policy `CMP0170`.

## Updates

Changes made since CMake 3.30.0 include the following.

### 3.30.1, 3.30.2

- These versions made no changes to documented features or interfaces. Some implementation updates were made to support ecosystem changes and/or fix regressions.

### 3.30.3

- The `project(<PROJECT-NAME>)` command now sets `<PROJECT-NAME>_SOURCE_DIR`, `<PROJECT-NAME>_BINARY_DIR`, and `<PROJECT-NAME>_IS_TOP_LEVEL` as normal variables in addition to setting them as cache entries. This is needed to preserve support for some `FetchContent` use cases under policy `CMP0169`'s NEW behavior.

- The `FindPython` and `FindPython3` modules now define, respectively, the `Python_DEFINITIONS` and `Python3_DEFINITIONS` variables on Windows to support development with the free threaded version of Python. The `INTERFACE_COMPILE_DEFINITIONS` target property is also defined for the various targets provided by these modules.

### 3.30.4

- The `project(<PROJECT-NAME>)` command now sets `<PROJECT-NAME>_SOURCE_DIR`, `<PROJECT-NAME>_BINARY_DIR`, and `<PROJECT-NAME>_IS_TOP_LEVEL` as normal variables only if they are already set as cache or non-cache variables when `project()` is invoked. Cache entries by the same names are always set as before. This refines 3.30.3's behavior change to restore behavior of nested directories that call `project()` with the same project name, but the implementation in this release is flawed (this release note has been retoractively updated). It can result in different behavior between the first and subsequent runs. Do not use CMake 3.30.4 if your project contains nested calls to `project()` with the same project name and you use these variables.

### 3.30.5

- The `project(<PROJECT-NAME>)` command now sets `<PROJECT-NAME>_SOURCE_DIR`, `<PROJECT-NAME>_BINARY_DIR`, and `<PROJECT-NAME>_IS_TOP_LEVEL` as non-cache variables only if they are already set as non-cache variables when `project()` is invoked. Cache entries by the same names are always set as before. This refines 3.30.3's behavior change to restore behavior of nested directories that call `project()` with the same project name, and it addresses the bug in the implementation introduced in 3.30.4.