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.