CMake 3.19.0 available for download

I am happy to announce that CMake 3.19.0 is now available for download at:
https://cmake.org/download/

Documentation is available at:
https://cmake.org/cmake/help/v3.19

Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.19/release/3.19.html

Some of the more significant changes in CMake 3.19 are:

  • “cmake(1)” and “cmake-gui(1)” now recognize “CMakePresets.json” and
    “CMakeUserPresets.json” files (see “cmake-presets(7)”).

  • The “Xcode” generator now uses the Xcode “new build system” when
    generating for Xcode 12.0 or higher. See the
    “CMAKE_XCODE_BUILD_SYSTEM” variable. One may use “-T buildsystem=1”
    to switch to the legacy build system.

  • The Visual Studio Generators for VS 2015 and above gained support
    for the Visual Studio Tools for Android. One may now set
    “CMAKE_SYSTEM_NAME” to “Android” to generate “.vcxproj” files for
    the Android tools.

  • CMake learned to support “ISPC” as a first-class language that can
    be enabled via the “project()” and “enable_language()” commands.
    “ISPC” is currently supported by the Makefile Generators and the
    “Ninja” generator on Linux, macOS, and Windows using the Intel ISPC
    compiler.

  • “CUDA” language support for Clang now supports separable compilation
    (“CUDA_SEPARABLE_COMPILATION”)

  • The “CMake GUI” now has an environment variable editor.

  • The “file(GENERATE)” command gained a new “TARGET” keyword to
    support resolving target-dependent generator expressions.

  • The “CMAKE_OPTIMIZE_DEPENDENCIES” variable was added to initialize
    the new “OPTIMIZE_DEPENDENCIES” target property and avoid
    unnecessarily building dependencies for a static library.

  • The “CheckCompilerFlag” module has been added to generalize
    “CheckCCompilerFlag” and “CheckCXXCompilerFlag” to more languages.
    It also supports the “CUDA” and “ISPC” languages.

  • The “CheckSourceCompiles” module has been added to generalize
    “CheckCSourceCompiles” and “CheckCXXSourceCompiles” to more
    languages. It also supports the “CUDA” and “ISPC” languages.

  • The “CheckSourceRuns” module has been added to generalize
    “CheckCSourceRuns” and “CheckCXXSourceRuns” to more languages. It
    also supports the “CUDA” language.

  • The “FindCUDAToolkit” module gained support for finding CUDA
    toolkits that do not contain “nvcc”, as well as for finding
    scattered toolkit installations when cross-compiling.

  • Interface Libraries may now have source files added via
    “add_library()” or “target_sources()”. Those with sources will be
    generated as part of the build system.

  • Compatibility with versions of CMake older than 2.8.12 is now
    deprecated and will be removed from a future version. Calls to
    “cmake_minimum_required()” or “cmake_policy()” that set the policy
    version to an older value now issue a deprecation diagnostic.

CMake 3.19 Release Notes

Changes made since CMake 3.18 include the following.

New Features

Presets

  • “cmake(1)” and “cmake-gui(1)” now recognize “CMakePresets.json” and
    “CMakeUserPresets.json” files (see “cmake-presets(7)”).

Generators

  • The “Xcode” generator now uses the Xcode “new build system” when
    generating for Xcode 12.0 or higher. See the
    “CMAKE_XCODE_BUILD_SYSTEM” variable. One may use “-T buildsystem=1”
    to switch to the legacy build system.

  • The “Xcode” generator gained support for linking libraries and
    frameworks via the Link Binaries With Libraries build phase
    instead of always by embedding linker flags directly. This behavior
    is controlled by a new “XCODE_LINK_BUILD_PHASE_MODE” target
    property, which is initialized by a new
    “CMAKE_XCODE_LINK_BUILD_PHASE_MODE” variable.

  • The Visual Studio Generators for VS 2015 and above gained support
    for the Visual Studio Tools for Android. One may now set
    “CMAKE_SYSTEM_NAME” to “Android” to generate “.vcxproj” files for
    the Android tools.

Languages

  • CMake learned to support “ISPC” as a first-class language that can
    be enabled via the “project()” and “enable_language()” commands.
    “ISPC” is currently supported by the Makefile Generators and the
    “Ninja” generator on Linux, macOS, and Windows using the Intel ISPC
    compiler.

  • “CUDA” language support for Clang now includes:

    • separable compilation (“CUDA_SEPARABLE_COMPILATION”), and

    • finding scattered toolkit installations when cross-compiling.

File-Based API

  • The “cmake-file-api(7)” “codemodel” version 2 “version” field has
    been updated to 2.2.

  • The “cmake-file-api(7)” “codemodel” version 2 “target” object gained
    a new “languageStandard” field in the “compileGroups” objects.

Command-Line

  • The “cmake(1)” command-line tool’s “–install” mode gained a “–
    default-directory-permissions” option.

  • “cmake(1)” gained a “-E create_hardlink” command-line tool that can
    be used to create hardlinks between files.

GUI

  • The “CMake GUI” now has an environment variable editor.

Commands

  • The “add_test()” command now (officially) supports whitespace and
    other special characters in the name for the test it creates. See
    policy “CMP0110”.

  • The “cmake_language()” command gained a “DEFER” mode to schedule
    command calls to occur at the end of processing a directory.

  • The “configure_file()” command gained a “NO_SOURCE_PERMISSIONS”
    option to suppress copying the input file’s permissions to the
    output file.

  • The “execute_process()” command gained a “COMMAND_ERROR_IS_FATAL”
    option to specify a fatal error.

  • The “file(ARCHIVE_CREATE)” command gained a “COMPRESSION_LEVEL”
    option to specify the compression level.

  • The “file(CHMOD)” and “file(CHMOD_RECURSE)” subcommands were added
    to set permissions of files and directories.

  • The “file(DOWNLOAD)” command “” argument is now optional. If
    it is not specified, the file is not saved.

  • The “file(GENERATE)” command gained a new “TARGET” keyword to
    support resolving target-dependent generator expressions.

  • The “file()” command gained a new “REAL_PATH” sub-command to compute
    a path with symlinks resolved.

  • The “find_package()” command learned to handle a version range.

  • The “separate_arguments()” command gained a new “PROGRAM” option. It
    allows the arguments to be treated as a program invocation and will
    resolve the executable to a full path if it can be found.

  • The “DIRECTORY” option of the “set_property()”, “get_property()”,
    and “get_directory_property()” commands now accepts references to
    binary directory paths, such as the value of
    “CMAKE_CURRENT_BINARY_DIR”.

  • The “string()” command gained a set of new “JSON” sub commands that
    provide JSON parsing capabilities.

Variables

  • The “CMAKE_CLANG_VFS_OVERLAY” variable was added to tell Clang to
    use a VFS overlay to support the Windows SDK when cross-compiling
    from hosts with case-sensitive filesystems.

  • The “CMAKE_MFC_FLAG” variable now supports generator expressions.

  • The “CMAKE_OPTIMIZE_DEPENDENCIES” variable was added to initialize
    the new “OPTIMIZE_DEPENDENCIES” target property and avoid
    unnecessarily building dependencies for a static library.

  • The “CMAKE_PCH_INSTANTIATE_TEMPLATES” variable was added to
    initialize the new “PCH_INSTANTIATE_TEMPLATES” target property.

  • The “CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM” variable was
    added to tell the Visual Studio Generators what maximum version of
    the Windows SDK to choose.

Properties

  • The “EXCLUDE_FROM_ALL” target property now supports “generator
    expressions”.

  • The “OPTIMIZE_DEPENDENCIES” target property was added to avoid
    unnecessarily building dependencies for a static library.

  • The “PCH_INSTANTIATE_TEMPLATES” target property was added to enable
    template instantiation in the precompiled header. This is enabled by
    default and may significantly improve compile times. Currently only
    supported for Clang (version 11 or later).

  • The “WIN32_EXECUTABLE” target property now supports “generator
    expressions”.

Modules

  • The “CheckCompilerFlag” module has been added to generalize
    “CheckCCompilerFlag” and “CheckCXXCompilerFlag” to more languages.
    It also supports the “CUDA” and “ISPC” languages.

  • The “CheckLinkerFlag” module now supports the “CUDA” language.

  • The “CheckSourceCompiles” module has been added to generalize
    “CheckCSourceCompiles” and “CheckCXXSourceCompiles” to more
    languages. It also supports the “CUDA” and “ISPC” languages.

  • The “CheckSourceRuns” module has been added to generalize
    “CheckCSourceRuns” and “CheckCXXSourceRuns” to more languages. It
    also supports the “CUDA” language.

  • The “CMakePackageConfigHelpers” module gained support for version
    ranges.

  • The “FindCUDAToolkit” module gained support for finding CUDA
    toolkits that do not contain “nvcc”, as well as for finding
    scattered toolkit installations when cross-compiling.

  • The “FindPackageHandleStandardArgs” module learned to handle version
    ranges. It also gained the “find_package_check_version()” command to
    check the validity of a version against version-related arguments of
    “find_package()” command.

  • The “FindPython3”, “FindPython2” and “FindPython” modules gained the
    ability to handle a version range.

  • The “FindPython3”, “FindPython2” and “FindPython” modules provide,
    respectively, the variable “Python3_LINK_OPTIONS”,
    “Python2_LINK_OPTIONS” and “Python_LINK_OPTIONS” for link options.

  • The “FindSDL” module now provides:

    • An imported target “SDL::SDL”.

    • Result variables “SDL_LIBRARIES” and “SDL_INCLUDE_DIRS”.

    • Version variables “SDL_VERSION”, “SDL_VERSION_MAJOR”,
      “SDL_VERSION_MINOR”, and “SDL_VERSION_PATCH”.

  • The “FindSWIG” module gained the ability to handle a version range.

  • The “FindTIFF” module gained a “CXX” component to find the “tiffxx”
    library containing C++ bindings.

  • The “FindVulkan” module now provides a “Vulkan::glslc” imported
    target and associated “Vulkan_GLSLC_EXECUTABLE” variable which
    contain the path to the GLSL SPIR-V compiler.

  • The “UseSWIG” module gained support for new source file properties
    “OUTPUT_DIR” and “OUTFILE_DIR” to manage output directories on a
    per-source basis.

CTest

  • “ctest(1)” now supports the CUDA “compute-sanitizer” checker
    (previously known as “cuda-memcheck”) as the
    “CTEST_MEMORYCHECK_COMMAND”. The different tools (“memcheck”,
    “racecheck”, “synccheck” and “initcheck”) supported by “compute-
    sanitizer” can be selected by adding appropriate flags to the
    “CTEST_MEMORYCHECK_COMMAND_OPTIONS” variable. The default flags are
    “–tool memcheck --leak-check full”.

CPack

  • CPack gained the “CPACK_PRE_BUILD_SCRIPTS”,
    “CPACK_POST_BUILD_SCRIPTS”, and “CPACK_PACKAGE_FILES” variables.

  • The “CPack External Generator” gained the
    “CPACK_EXTERNAL_BUILT_PACKAGES” variable.

  • The “CPack WIX Generator” gained a “CPACK_WIX_CUSTOM_XMLNS” option
    to specify custom XML namespaces.

Other

  • Interface Libraries may now have source files added via
    “add_library()” or “target_sources()”. Those with sources will be
    generated as part of the build system.

Deprecated and Removed Features

  • Compatibility with versions of CMake older than 2.8.12 is now
    deprecated and will be removed from a future version. Calls to
    “cmake_minimum_required()” or “cmake_policy()” that set the policy
    version to an older value now issue a deprecation diagnostic.

  • An explicit deprecation diagnostic was added for policy “CMP0071”
    (“CMP0071” and below were already deprecated). The “cmake-
    policies(7)” manual explains that the OLD behaviors of all policies
    are deprecated and that projects should port to the NEW behaviors.

  • macOS SDKs older than 10.5 are no longer supported.

  • “cmake-gui(1)” now requires Qt5. Support for compiling with Qt4 has
    been removed.

  • The “cmake(1)” command-line option “–warn-unused-vars” has been
    removed and is now silently ignored. The option has not worked
    correctly since CMake 3.3.

Documentation

The following guides have been added:

  • “IDE Integration Guide”

  • “Importing and Exporting Guide”

Other Changes

  • Building for macOS will now use the latest SDK available on the
    system, unless the user has explicitly chosen a SDK using
    “CMAKE_OSX_SYSROOT”. The deployment target or system macOS version
    will not affect the choice of SDK.

  • The “CMAKE_<LANG>_COMPILER” variable may now be used to store
    “mandatory” compiler flags like the “CC” and other environment
    variables.

  • The “CMAKE_<LANG>_FLAGS_INIT” variable will now be considered during
    the compiler identification check if other sources like
    “CMAKE_<LANG>_FLAGS” or “CFLAGS” are not set.

  • The “find_program()” command now requires permission to execute but
    not to read the file found. See policy “CMP0109”.

  • An imported target missing its location property fails during
    generation if the location is used. See policy “CMP0111”.

  • The following target-based generator expressions that query for
    directory or file name components no longer add a dependency on the
    evaluated target. See policy “CMP0112”.

    • “TARGET_FILE_DIR”

    • “TARGET_LINKER_FILE_BASE_NAME”

    • “TARGET_LINKER_FILE_NAME”

    • “TARGET_LINKER_FILE_DIR”

    • “TARGET_SONAME_FILE_NAME”

    • “TARGET_SONAME_FILE_DIR”

    • “TARGET_PDB_FILE_NAME”

    • “TARGET_PDB_FILE_DIR”

    • “TARGET_BUNDLE_DIR”

    • “TARGET_BUNDLE_CONTENT_DIR”

  • Makefile Generators no longer repeat custom commands from target
    dependencies. See policy “CMP0113”.

  • The “ExternalProject” module handling of step target dependencies
    has been revised. See policy “CMP0114”.

  • The “OSX_ARCHITECTURES” target property is now respected for the
    “ASM” language.

  • If “CUDA” compiler detection fails with user-specified
    “CMAKE_CUDA_ARCHITECTURES” or “CMAKE_CUDA_HOST_COMPILER”, an error
    is raised.


Changes made since CMake 3.19.0-rc3:

Ben Boeckel (7):

  • Help/get_filename_component: clarify NAME_W[L]E summaries
  • clang-tidy: ignore misc-no-recursion
  • clang-tidy: ignore new warnings from newer versions
  • Tests/FindBoost/TestPython: support finding 3.8 and 3.9
  • ci: update to Fedora 33 for Linux builds
  • gitlab-ci: update Linux CI to use Fedora 33
  • gitlab-ci: use Fedora 33 to build sources

Brad King (8):

  • Utilities/Sphinx: Tell Sphinx that documentation is written in English
  • Ninja: Avoid cleandead with dyndep bindings for Fortran module dependencies
  • Xcode: Default to arm64 arch on Apple Silicon hosts during compiler id
  • Xcode: Extract CMAKE_<LANG>_COMPILER from compiler id with multiple archs
  • ci: install gmock in the Fedora 31 image
  • Suppress MSVC 14.28 C5105 warning triggered by Windows SDK
  • gitlab-ci: Update Windows builds to MSVC 19.28
  • CMake 3.19.0

Erlend Egeberg Aasland (2):

  • CPack/IFW: Add support for QtIFW 4.0
  • CPack/IFW: Locate the archivegen utility

Gusts Kaksis (1):

  • Xcode: Clean library paths to avoid linker duplicate symbol definitions

Haibo Huang (1):

  • Android: Use NDK_KNOWN_DEVICE_ABI{32,64}S instead of NDK_DEFAULT_ABIS

Marc Chevrier (1):

  • FindPython: Fix version range tests

Michael Hirsch (1):

  • Help: MSVC now has C standard level flags

Miro Hrončok (1):

  • FindPython{Interp,Libs}: Add support for version 3.10

Nikita Nemkin (1):

  • Help: Fix .. versionadded directives in environment variable docs

Silvio Traversaro (1):

  • FindRuby: Consider more VS runtime suffix combinations

Tobias Ribizel (1):

  • CTest: Rename CudaMemcheck to CudaSanitizer

Double underscore? Is that a typo?

It should read CMAKE_<LANG>_COMPILER, but <LANG> has been interpreted as HTML and not rendered.

Should be fixed now. Names of the form “SOMETHING_<blah>_MORETHINGS” need escaping to avoid the <blah> part being treated as a HTML tag when they are not surrounded by back-ticks.

MacOS Issue with Objective-C

It seems that cmake 3.19.0 has a breaking change: trying to generate projects to compile *.m files with this version, appends “-x c” instead of “-x objective-c” to the C compiler command line.

This in turn results in Objective-C files being compiled as C, which in turn generates all sorts of weird compiler errors (due to Objective-C syntax being unrecognized).

Downgrading to cmake 3.18.5 resolved those issues.

I have not yet tested this with “*.mm” files (Objective-C++).

The issue can be easily reproduced by attempting to build https://github.com/obsproject/obs-studio on MacOS.

Hi

This regression will be corrected in 3.19.1: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5519

Looking at OBS I see that you are marking the .m files explicitly as C Language files. The purpose and documentation of the LANGUAGE flag is to control what language the files are not to mean use the C compiler.

Going forward, expect CMake 3.20 to introduce a policy around this behavior and for proper forward compatibility, OBS should mark these files OBJC not C.

Hi,
Thank you for the information & confirmation of the regression.
Looking forward to 3.19.1 release.

Can you kindly confirm that there is no similar regression with *.mm files?

For 3.19.0 If projects mark .mm with the LANGUAGE of CXX they will fail if you actually meant objective-c++. The previous behavior will be restored in 3.19.1. Looking at the OBS project I see no files being marked explicitly as CXX.

Again CMake 3.20.0 will introduce a policy where the CMake 3.18 and older behavior will become deprecated and you will need to mark objective-c files as OBJC and not C.

Thank you for clarifying.
In the meantime, is ETA for 3.19.1 release known?

Note that since CMake 3.16, one can enable OBJC and OBJCXX as first-class languages with project() or enable_language(). That will automatically treat .m and .mm files as those respective languages, and the LANGUAGE source file property does not need to be set at all.