CMake 3.22.0 available for download

Announcements
1

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

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

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

Some of the more significant changes in CMake 3.22 are:

  • The “Compile Features” functionality now correctly disables or
    enables compiler extensions when no standard level is specified and
    avoids unnecessarily adding language standard flags if the requested
    settings match the compiler’s defaults. See “CMP0128”.

  • The “cmake_host_system_information()” command can now query OS
    identification variables from the “/etc/os-release” file.

  • The “CMAKE_BUILD_TYPE” environment variable was added to provide a
    default value for the “CMAKE_BUILD_TYPE” variable.

  • The “CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>” variable was added to
    turn a non-REQUIRED “find_package()” call into a REQUIRED one.

  • The “FetchContent” module now passes through the “CMAKE_TLS_VERIFY”,
    “CMAKE_TLS_CAINFO”, “CMAKE_NETRC” and “CMAKE_NETRC_FILE” variables
    (when defined) to the underlying “ExternalProject” sub-build.
    Previously, those variables were silently ignored by “FetchContent”.

  • The “Visual Studio 10 2010” generator is now deprecated and will be
    removed in a future version of CMake.

CMake 3.22 Release Notes

Changes made since CMake 3.21 include the following.

New Features

Commands

  • The “cmake_host_system_information()” command can now query OS
    identification variables from the “/etc/os-release” file.

  • The “string(TIMESTAMP)” command now supports the “%V” specifier for
    ISO 8601 week numbers.

Variables

  • The “CMAKE_BUILD_TYPE” environment variable was added to provide a
    default value for the “CMAKE_BUILD_TYPE” variable.

  • The “CMAKE_CONFIGURATION_TYPES” environment variable was added to
    provide a default value for the “CMAKE_CONFIGURATION_TYPES”
    variable.

  • The “CMAKE_INSTALL_MODE” environment variable was added to tell
    “install()” rules (implemented by “file(INSTALL)”) to install
    symbolic links instead of copying of files.

  • The “CMAKE_<LANG>_LINK_WHAT_YOU_USE_FLAG” and
    “CMAKE_LINK_WHAT_YOU_USE_CHECK” variables were added to control the
    linker flag and check used by the “LINK_WHAT_YOU_USE” target
    property.

  • The “CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>” variable was added to
    turn a non-REQUIRED “find_package()” call into a REQUIRED one.

Properties

  • The “<LANG>_EXTENSIONS” target property is now initialized to
    “CMAKE_<LANG>_EXTENSIONS_DEFAULT”, detected from the compiler. See
    “CMP0128”.

  • The “VS_SETTINGS” source file property is now supported for all
    source file types. Previously it worked only for non-built sources.

Modules

  • The “CMakeDependentOption” module “cmake_dependent_option()” macro
    now supports full Condition Syntax. See policy “CMP0127”.

  • The “FetchContent” module now passes through the “CMAKE_TLS_VERIFY”,
    “CMAKE_TLS_CAINFO”, “CMAKE_NETRC” and “CMAKE_NETRC_FILE” variables
    (when defined) to the underlying “ExternalProject” sub-build.
    Previously, those variables were silently ignored by “FetchContent”.

  • The “FindBLAS” and “FindLAPACK” modules gained a
    “BLA_SIZEOF_INTEGER” option to find a BLAS/LAPACK whose ABI uses a
    specific integer size.

  • The “FindJasper” module now provides an imported target.

  • The “FindMatlab” module now provides imported targets.

  • The “FindPkgConfig” module gained a “PKG_CONFIG_ARGN” variable to
    specify arguments to “pkg-config” calls.

  • The “GoogleTest” module “gtest_discover_tests()” function gained a
    “TEST_FILTER” option to filter tests using “–gtest_filter” during
    test discovery.

  • The “UseSWIG” module, for Visual Studio Generators, can now use the
    “swig” tool to generate implicit dependencies.

CTest

  • “ctest(1)” learned to recognize labels attached to a test at run
    time. Previously it was only possible to attach labels to tests at
    configure time by using the “LABELS” test property. See Additional
    Test Measurements for more information.

  • “ctest(1)” learned to be able to modify the environment for a test
    through the “ENVIRONMENT_MODIFICATION” property. This is allows for
    updates to environment variables based on the environment present at
    test time.

  • The “ctest_memcheck()” command now also generates a
    “DynamicAnalysis-Test.xml” file which may be used to submit test
    results to CDash.

CPack

  • The “CPack DEB Generator” gained the option to set
    “CPACK_DEBIAN_COMPRESSION_TYPE” to “zstd”, which enables Zstandard
    compression for deb packages.

  • The “CPack NSIS Generator” gained a new
    “CPACK_NSIS_IGNORE_LICENSE_PAGE” variable to suppress the license
    page in the installer.

  • The “CPack RPM Generator” gained the
    “CPACK_RPM_REQUIRES_EXCLUDE_FROM” option to avoid scanning specific
    paths for dependencies.

Deprecated and Removed Features

  • The “Visual Studio 10 2010” generator is now deprecated and will be
    removed in a future version of CMake.

Other Changes

  • The “Compile Features” functionality now correctly disables or
    enables compiler extensions when no standard level is specified and
    avoids unnecessarily adding language standard flags if the requested
    settings match the compiler’s defaults. See “CMP0128”.

  • The “Compile Features” functionality now ignores features for
    languages that are not enabled.

  • The Ninja Generators now implement the “edit_cache” target using
    “ccmake(1)” if available.

  • The “Ninja” and “NMake Makefiles” generators now use the MSVC
    “-external:I” flag for system includes. This became available as of
    VS 16.10 (toolchain version 14.29.30037).

  • The “CPack NSIS Generator” now requires NSIS 3.03 or later.

Changes made since CMake 3.22.0-rc3:

Antons Jeļkins (2):

  • cmTimestamp: Declare component buffer before MinGW-specific code
  • MINGW-w64: Fix string(TIMESTAMP) build on 32bits.

Brad King (3):

  • libuv: Backport MinGW-w64 compilation fix to CMake 3.22 branch
  • IntelLLVM: Enable Fortran module rebuild avoidance in Makefile generators
  • CMake 3.22.0

Craig Scott (5):

  • Help: Add missing version details for Additional Test Measurements
  • Help: Improve cross-referencing of test LABELS and related features
  • Help: Clarify meaning of filter expression in gtest_discover_tests()
  • Tests: Fix and update wrongly named GoogleTest stdout file
  • gtest_discover_tests: Re-run PRE_TEST discovery on any arg change
2 Likes
3

@Tom_Osika I dowlnoaded this version for Windows. CMake and VTK build Ok, however when building vtk-examples the build aborts with:

ninja: fatal: CreateProcess: The parameter is incorrect.
 (is the command line too long?)

I then built using Visual Studio instead of ninja and it built Ok with no problems.

I reinstalled CMake-3.21.4 and configure/build works perfectly using ninja.

Here is the output when it fails: failure.zip (3.7 KB), the CMakeCache is
CMakeCache.zip (9.5 KB) for CMake 3.22.0

For comparison, here is the CMakeCache for CMake 3.21.4: CMakeCache.zip (9.5 KB)

Given that CMake 3.21.4 works, is there any reason why the command line is so long in the latest release? Or it is some other issue?

4

May I guess?:

The “Ninja” and “NMake Makefiles” generators now use the MSVC
“-external:I” flag for system includes. This became available as of
VS 16.10 (toolchain version 14.29.30037).

5

@ben.boeckel

6

I would guess that yes, -external:I pushed it over the limit, but is probably just a symptom of the number of include paths being ridiculous (oh how I wished VTK would just use #include "Common/Core/vtkObject.h" so we could just have a single include flag). Adding a few more include paths before probably would have triggered it as well.

I’d say the solutions here are:

  • use a VTK install tree rather than a build tree (so that you do get back to just a single -I being needed).
  • use CMAKE_NINJA_FORCE_RESPONSE_FILE=ON if using a build tree is necessary/more convenient
  • campaign in VTK to start putting the directories in the sources rather than the command line
  • find out where CMake computes the command line length and see why it doesn’t detect this case (though Windows has always been hacky here IIRC)
7

Thanks @ben.boeckel for the CMAKE_NINJA_FORCE_RESPONSE_FILE=ON suggestion. That works really well. Much appreciated. I suspect that VS2022 must use some sort of response file when building as I had no troubles using the VS2022 GUI.

MR is done.

8

@amaclean my understanding is that VS2022 uses the environment variable INCLUDE. To minimize clutter of the command line caused by system includes. I don’t think Ninja uses that however.

/I (Additional include directories) | Microsoft Docs

/external (External headers diagnostics) | Microsoft Docs

9

Probably.

That is for the toolchain and stdlib headers generally. MSBuild does not contain direct command lines, but instead is XML property lookup from which MSBuild knows how to generate the relevant command line based on what properties are set. I suspect it does its own internal command line building that avoids these problems. Of course, it could use INCLUDE, but environment variables are also subject to length limitations.

Note that CMake does not support /external for Visual Studio yet.

2 Likes
10

I just upgraded cmake to 3.22 after upgrading to latest VS2019 and got this:

CMake Error at CMakeLists.txt:63 (project):
Generator

Visual Studio 16 2019

could not find specified instance of Visual Studio:

C:/Program Files (x86)/Microsoft Visual Studio/2019/Community

This is very annoying, do you guys have regression tests against msvc?

Update 1: if I first run cmake using empty bin folder it detects correctly MSVC, so it seems it breaks only on existing projects.

Update 2 : this is an old thing but not only MSVC is not found but the whole runtime after upgrade either:

CMake Warning at C:/Program Files/CMake/share/cmake-3.22/Modules/InstallRequiredSystemLibraries.cmake:624 (message):
system runtime library file does not exist: 'C:/Program Files
(x86)/Microsoft Visual
Studio/2019/Community/VC/Redist/MSVC/14.29.30036/x64/Microsoft.VC142.CRT/msvcp140.dll

11

It breaks on existing projects because the path to the tools (compiler, linker, librarian) is cached in CMakeCache.txt. So either delete the CMakeCache.txt file and reconfigure or don’t change your environment for already configured projects ;).

12

I’m surprised the first error message you got was not to delete your cache now that you are using a newer CMake version.

13

In general updating to a new CMake version in an existing build tree works fine.

Changing the location of Visual Studio, or its set of available toolchains, is not something we can support in an existing build tree. Nor is it easy to detect.

14

That error can appear when the Visual Studio Installer doesn’t think the VS instance is finished installing. The installer may have requested a reboot, and will not consider the installation complete until after a reboot.

15

Hey guys, thanks for the quick response.

I will reply to all by summarizing the issue now that I spent some more time diagnosing.

@buildSystemPerson
Till now, updating cmake was not requiring rebuild of the cache.

@brad.king
I did have to restart indeed and I did that. Still, applying minor updates to the toolchain in MSVC was not braking anything until now. For example, the installer (cpack+wix) was able to find the MSVC runtime. However, duly noted, I understand now cmake does not guarantee compatibility and it’s entirely toolchain vendor specific.

One other question: Since we rely on batch script to run cmake (both for CI and devs alike) I am looking into auto cleaning (rebuild) the cache. So how can I force reloading of the cache via console, is the --clean-first flag the way to go?

16

@dr_ppetrov what was the value of CMAKE_GENERATOR_INSTANCE in your CMakeCache.txt of the existing build tree, and what is it in new build trees?

how can I force reloading of the cache via console

The cache is loaded when CMake runs to configure a build tree and generate the build system. If you remove the file, you should remove the adjacent top-level CMakeFiles/ directory too. Then you need to re-run CMake to regenerate the build tree.