\_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
---
### Author:  [@amaclean](https://discourse.cmake.org/u/amaclean)
#### Post date: [November 19, 2021, 4:36am UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/3 "2021-11-19T04:36:08Z")
@Tom_Osika I dowlnoaded this version for Windows. CMake and VTK build Ok, however when building `vtk-examples` the build aborts with:
```bash
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](https://discourse.cmake.org/uploads/short-url/lETFQYdA3GFrQwBihB0vfv2Q9cu.zip) (3.7 KB), the CMakeCache is
[CMakeCache.zip](https://discourse.cmake.org/uploads/short-url/2d5kLlHRAPo60yUP24oUStMxcU3.zip) (9.5 KB) for CMake 3.22.0
For comparison, here is the CMakeCache for CMake 3.21.4: [CMakeCache.zip](https://discourse.cmake.org/uploads/short-url/n1Hfb4CK639t63Xefx36kP6uy5K.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?
---
### Author:  [@hsattler](https://discourse.cmake.org/u/hsattler)
#### Post date: [November 19, 2021, 3:09pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/4 "2021-11-19T15:09:56Z")
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).
---
### Author:  [@robert.maynard](https://discourse.cmake.org/u/robert.maynard)
#### Post date: [November 19, 2021, 7:27pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/5 "2021-11-19T19:27:56Z")
@ben.boeckel
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 19, 2021, 8:00pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/6 "2021-11-19T20:00:36Z")
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)
---
### Author:  [@amaclean](https://discourse.cmake.org/u/amaclean)
#### Post date: [November 29, 2021, 3:57am UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/7 "2021-11-29T03:57:43Z")
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.
---
### Author:  [@buildSystemPerson](https://discourse.cmake.org/u/buildSystemPerson)
#### Post date: [November 29, 2021, 11:53am UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/8 "2021-11-29T11:53:42Z")
@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](https://docs.microsoft.com/en-us/cpp/build/reference/i-additional-include-directories?view=msvc-160)
[/external (External headers diagnostics) | Microsoft Docs](https://docs.microsoft.com/en-us/cpp/build/reference/external-external-headers-diagnostics?view=msvc-160)
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 29, 2021, 12:03pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/9 "2021-11-29T12:03:27Z")
> [@amaclean](#):
>
> I suspect that VS2022 must use some sort of response file when building as I had no troubles using the VS2022 GUI.
Probably.
> [@buildSystemPerson](#):
>
> my understanding is that VS2022 uses the environment variable INCLUDE.
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.
---
### Author:  [@dr\_ppetrov](https://discourse.cmake.org/u/dr_ppetrov)
#### Post date: [December 1, 2021, 1:16pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/10 "2021-12-01T13:16:33Z")
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
---
### Author:  [@vre](https://discourse.cmake.org/u/vre)
#### Post date: [December 1, 2021, 2:10pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/11 "2021-12-01T14:10:45Z")
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 ;).
---
### Author:  [@buildSystemPerson](https://discourse.cmake.org/u/buildSystemPerson)
#### Post date: [December 1, 2021, 2:32pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/12 "2021-12-01T14:32:44Z")
> [@dr\_ppetrov](#):
>
> This is very annoying, do you guys have regression tests against msvc?
I’m surprised the first error message you got was not to delete your cache now that you are using a newer CMake version.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [December 1, 2021, 3:35pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/13 "2021-12-01T15:35:12Z")
> [@buildSystemPerson](#):
>
> the first error message you got was not to delete your cache now that you are using a newer CMake version.
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.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [December 1, 2021, 3:36pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/14 "2021-12-01T15:36:17Z")
> [@dr\_ppetrov](#):
>
> I just upgraded cmake to 3.22 after upgrading to latest VS2019 and got this:
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.
---
### Author:  [@dr\_ppetrov](https://discourse.cmake.org/u/dr_ppetrov)
#### Post date: [December 1, 2021, 4:01pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/15 "2021-12-01T16:01:12Z")
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?
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [December 1, 2021, 4:07pm UTC](https://discourse.cmake.org/t/cmake-3-22-0-available-for-download/4503/16 "2021-12-01T16:07:46Z")
@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.