CMake 3.20 Release Notes

Changes made since CMake 3.19 include the following.

New Features



  • Makefile Generators, for some toolchains, now use the compiler to extract implicit dependencies while compiling source files.


  • C++23 compiler modes may now be specified via the CXX_STANDARD, CUDA_STANDARD, or OBJCXX_STANDARD target properties, or via the Compile Features functionality's cxx_std_23 meta-feature.

  • CUDA language support now works when nvcc is a symbolic link, for example due to a ccache or colornvcc wrapper script.

  • The CUDAARCHS environment variable was added for initializing CMAKE_CUDA_ARCHITECTURES. Useful in cases where the compiler default is unsuitable for the machine's GPU.


  • The NVIDIA HPC SDK compilers are now supported with compiler id NVHPC.

  • The Intel oneAPI NextGen LLVM compilers are now supported with compiler id IntelLLVM:

    • The icx/icpx C/C++ compilers on Linux, and the icx C/C++ compiler on Windows, are fully supported as of oneAPI 2021.1.

    • The ifx Fortran compiler on Linux is supported as of oneAPI 2021.1.

    • The ifx Fortran compiler on Windows is not yet supported.

    The Intel oneAPI Classic compilers (icc, icpc, and ifort) continue to be supported with compiler id Intel.

  • Support was added for the IAR STM8 compiler.


  • CMake's support for Cross Compiling for Android is now merged with the Android NDK's toolchain file. They now have similar behavior, though some variable names differ. User-facing changes include:

    • find_* functions will search NDK ABI / API specific paths by default.

    • The default CMAKE_BUILD_TYPE for Android is now RelWithDebInfo.

    • The CMAKE_ANDROID_NDK_VERSION variable was added to report the version of the NDK.

File-Based API

  • The cmake-file-api(7) gained a new "toolchains" object kind that describes the compiler used for each enabled language.





  • The ExternalData module ExternalData_Add_Target() function gained a SHOW_PROGRESS <bool> option for controlling whether or not to show progress output during the build.

  • The ExternalProject module ExternalProject_Add() function gained a CONFIGURE_HANDLED_BY_BUILD option. This can be used to make subsequent runs of the configure step be triggered by the build step when an external project dependency rebuilds instead of always re-running the configure step in such cases.

  • The FindBoost module gained a Boost_NO_WARN_NEW_VERSIONS option to silence the warning about unknown dependencies for new Boost versions.

  • The FindCUDAToolkit module gained support for finding CUDA toolkits when nvcc is a symbolic link, for example due to a ccache or colornvcc wrapper script.

  • The FindGDAL module has been improved to document and mark as advanced its cache variables. There is a new FindGDAL_SKIP_GDAL_CONFIG variable which may be used to skip over the gdal-config-based search. Users may also set GDAL_ADDITIONAL_LIBRARY_VERSIONS to add additional versions to the library name search strategy.

  • The FindIntl module now provides an imported target.

  • The FindOpenSSL module learned to support a version range.

  • The FindPython3, FindPython2 and FindPython modules gained options controlling how unversioned interpreter names are searched.

  • The UseJava module add_jar() command's GENERATE_NATIVE_HEADERS feature gained options to export the generated target.

  • The UseSWIG module gained the capability, for Makefile and Ninja generators, to use the swig tool to generate implicit dependencies.


  • The AUTOMOC feature now works with per-config sources.


  • ctest(1) gained a --test-dir option to specify the directory in which to look for tests.


Deprecated and Removed Features

Other Changes

  • When running cmake(1) to Generate a Project Buildsystem, unknown command-line arguments starting with a hyphen (-) are now rejected with an error. Previously they were silently ignored.

  • Source file extensions must now be explicit. See policy CMP0115 for details.

  • The LANGUAGE source file property now forces compilation as the specified language. See policy CMP0119.

  • On AIX, installation of XCOFF executables and shared libraries no longer requires relinking to change the runtime search path from the build-tree RPATH to the install-tree RPATH. CMake now edits the XCOFF binaries directly during installation, as has long been done on ELF platforms.

  • With MSVC-like compilers the value of CMAKE_CXX_FLAGS no longer contains the /GR flag for runtime type information by default. See policy CMP0117.

  • Ninja generators now transform the DEPFILE generated by an add_custom_command(). See policy CMP0116 for details.

  • The precompiled Linux binaries provided on have changed their naming pattern to cmake-$ver-linux-$arch, where $arch is either x86_64 or aarch64.

  • The precompiled Windows binaries provided on have changed their naming pattern to cmake-$ver-windows-$arch, where $arch is either x86_64 or i386.


Changes made since CMake 3.20.0 include the following.


  • The FindIntl module in CMake 3.20.0 added checks Intl_HAVE_GETTEXT_BUILTIN, Intl_HAVE_DCGETTEXT_BUILTIN, and Intl_IS_BUILTIN, but they were not implemented correctly. These have been removed and replaced with a single Intl_IS_BUILT_IN check, whose name is consistent with the FindIconv module.

  • The -rpath linker flag is now specified as supported on all Apple platforms, not just macOS. The install_name_dir used for iOS, tvOS and watchOS should now default to @rpath instead of using a full absolute path and failing at runtime when the library or framework is embedded in an application bundle (see XCODE_EMBED_<type>).


  • The Intel Classic 2021 compiler version numbers are now detected correctly as having major version 2021. CMake 3.20.1 and below were not aware of a change to the identification macro version scheme made by Intel starting in version 2021, and detected the version as 20.2.

  • The Intel oneAPI Fortran compiler is now identified as IntelLLVM. The oneAPI 2021.1 Fortran compiler is missing an identification macro, so CMake 3.20.1 and below identified it as Intel. CMake now has a special case to recognize oneAPI 2021.1 Fortran as IntelLLVM. The oneAPI 2021.2 Fortran compiler defines the proper identification macro and so is identified as IntelLLVM by all CMake 3.20 versions.

3.20.3, 3.20.4, 3.20.5, 3.20.6

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