# CMake 3.18.0-rc1 is ready for testing

**URL:** https://discourse.cmake.org/t/cmake-3-18-0-rc1-is-ready-for-testing/1360
**Category:** Announcements
**Created:** [June 9, 2020, 7:09pm UTC](https://discourse.cmake.org/t/cmake-3-18-0-rc1-is-ready-for-testing/1360 "2020-06-09T19:09:34Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![robert.maynard](https://discourse.cmake.org/user_avatar/discourse.cmake.org/robert.maynard/32/4_2.png) [@robert.maynard](https://discourse.cmake.org/u/robert.maynard)
#### Post date: [June 9, 2020, 7:09pm UTC](https://discourse.cmake.org/t/cmake-3-18-0-rc1-is-ready-for-testing/1360/1 "2020-06-09T19:09:35Z")

</div>

I am proud to announce the first CMake 3.18 release candidate.  
[https://cmake.org/download/](https://cmake.org/download/)

Documentation is available at:  
[https://cmake.org/cmake/help/v3.18](https://cmake.org/cmake/help/v3.18)

Release notes appear below and are also published at  
[https://cmake.org/cmake/help/v3.18/release/3.18.html](https://cmake.org/cmake/help/v3.18/release/3.18.html)

Some of the more significant changes in CMake 3.18 are:

- The “CUDA” language can now be compiled using Clang.  
This is experimental and still under development.

- “cmake(1)” gained support for profiling of CMake scripts through the  
parameters “–profiling-output” and “–profiling-format”.

- The “add\_library()” and “add\_executable()” commands learned to  
create Alias Targets referencing non-“GLOBAL” Imported Targets.

- The “cmake\_language()” command was added for meta-operations on  
scripted or built-in commands, starting with a mode to “CALL” other  
commands, and “EVAL CODE” to inplace evaluate a CMake script.

- The “file(CONFIGURE)” subcommand was created in order to replicate  
the “configure\_file()” functionality without resorting to a pre-  
existing file on disk as input. The content is instead passed as a  
string.

- The “find\_program()”, “find\_library()”, “find\_path()” and  
“find\_file()” commands gained a new “REQUIRED” option that will stop  
processing with an error message if nothing is found.

- A “CMAKE\_CUDA\_ARCHITECTURES” variable was added to specify CUDA  
output architectures. Users are encouraged to use this instead of  
specifying options manually, as this approach is compiler-agnostic.  
The variable is initialized automatically when  
“CMAKE\_CUDA\_COMPILER\_ID” is “NVIDIA”. The variable is used to  
initialize the new “CUDA\_ARCHITECTURES” target property. See policy  
“CMP0104”.

- The “UNITY\_BUILD\_MODE” target property was added to tell generators  
which algorithm (“BATCH”, “GROUP”) to use for grouping included source  
files.

- The “CheckLinkerFlag” module has been added to provide a facility to  
check validity of link flags.

- The “$\<DEVICE\_LINK:…\>” and “$\<HOST\_LINK:…\>” “generator  
expressions” were added to manage device and host link steps.

- The “$\<LINK\_LANGUAGE:…\>” and “$\<LINK\_LANG\_AND\_ID:…\>” “generator  
expressions” were added.

- “ctest(1)” gained a new “CTEST\_RESOURCE\_SPEC\_FILE” variable, which  
can be used to specify a resource specification file.

- “ccmake(1)” learned to read a “CCMAKE\_COLORS” environment variable  
to customize colors.

- On Windows, the “Ninja” and “Ninja Multi-Config” generators, when a  
compiler is not explicitly specified, now select the first compiler  
(of any name) found in directories listed by the “PATH” environment  
variable.

# CMake 3.18 Release Notes

## Changes made since CMake 3.17 include the following.

## New Features

### Languages

- The “CUDA” language can now be compiled using Clang.  
This is experimental and still under development.

### Command-Line

- “cmake(1)” gained support for profiling of CMake scripts through the  
parameters “–profiling-output” and “–profiling-format”.

- “cmake(1)” gained a “cat” command line option that can be used to  
concatenate files and print them on standard output.

### Commands

- The “add\_library()” and “add\_executable()” commands learned to  
create Alias Targets referencing non-“GLOBAL” Imported Targets.

- The “cmake\_language()” command was added for meta-operations on  
scripted or built-in commands, starting with a mode to “CALL” other  
commands, and “EVAL CODE” to inplace evaluate a CMake script.

- The “execute\_process()” command gained the “ECHO\_OUTPUT\_VARIABLE”  
and “ECHO\_ERROR\_VARIABLE” options.

- The “export()” command now raise an error if used multiple times  
with same “FILE” without “APPEND”. See policy “CMP0103”.

- The “file()” command gained the “ARCHIVE\_CREATE” and  
“ARCHIVE\_EXTRACT” subcommands to expose the “cmake(1)” “-E tar”  
functionality to CMake scripting code.

- The “file(CONFIGURE)” subcommand was created in order to replicate  
the “configure\_file()” functionality without resorting to a pre-  
existing file on disk as input. The content is instead passed as a  
string.

- The “file(UPLOAD)” command gained “TLS\_VERIFY” and “TLS\_CAINFO”  
options to control server certificate verification.

- The “find\_program()”, “find\_library()”, “find\_path()” and  
“find\_file()” commands gained a new “REQUIRED” option that will stop  
processing with an error message if nothing is found.

- The “get\_property()” command with “SOURCE” scope gained the  
“DIRECTORY” and “TARGET\_DIRECTORY” options to get a property from  
the provided directory scope.

- The “get\_source\_file\_property()” command gained the “DIRECTORY” and  
“TARGET\_DIRECTORY” options to get a property from the provided  
directory scope.

- The “list()” operation “SORT” gained the “NATURAL” sort option to  
sort using natural order (see “strverscmp(3)” manual).

- The “set\_property()” command with the “SOURCE” scope gained the  
“DIRECTORY” and “TARGET\_DIRECTORY” options to set properties in the  
provided directory scopes.

- The “set\_source\_files\_properties()” command gained the “DIRECTORY”  
and “TARGET\_DIRECTORY” options to set properties in the provided  
directory scopes.

- The “string()” command learned a new “HEX” sub-command, which  
converts strings into their hexadecimal representation.

### Variables

- A “CMAKE\_CUDA\_ARCHITECTURES” variable was added to specify CUDA  
output architectures. Users are encouraged to use this instead of  
specifying options manually, as this approach is compiler-agnostic.  
The variable is initialized automatically when  
“CMAKE\_CUDA\_COMPILER\_ID” is “NVIDIA”. The variable is used to  
initialize the new “CUDA\_ARCHITECTURES” target property. See policy  
“CMP0104”.

- The “CMAKE\_PCH\_WARN\_INVALID” variable was added to initialize the  
“PCH\_WARN\_INVALID” target property to allow the removal of the  
precompiled header invalid warning.

### Properties

- The “CUDA\_ARCHITECTURES” target property was added to specify CUDA  
output architectures. Users are encouraged to use this instead of  
specifying options manually, as this approach is compiler-agnostic.  
The property is initialized by the new “CMAKE\_CUDA\_ARCHITECTURES”  
variable. See policy “CMP0104”.

- The “Fortran\_PREPROCESS” target property and “Fortran\_PREPROCESS”  
source-file property were added to control preprocessing of Fortran  
source files.

- The “FRAMEWORK\_MULTI\_CONFIG\_POSTFIX\_” target property and  
associated “CMAKE\_FRAMEWORK\_MULTI\_CONFIG\_POSTFIX\_” variable  
were created to allow adding a postfix to the name of a framework  
file name when using a multi-config generator.

- The “OBJECT\_OUTPUTS” source file property now supports “generator  
expressions”.

- The “UNITY\_BUILD\_MODE” target property was added to tell generators  
which algorithm to use for grouping included source files.

- The “VS\_SOURCE\_SETTINGS\_” target property was added to tell  
Visual Studio Generators for VS 2010 and above to add metadata to  
non-built source files using “”.

- The “VS\_SETTINGS” source file property was added to tell Visual  
Studio Generators for VS 2010 and above to add metadata to a non-  
built source file.

- The “VS\_PLATFORM\_TOOLSET” target property was added to tell Visual  
Studio Generators for VS 2010 and above to override the platform  
toolset.

- The “VS\_SOLUTION\_DEPLOY” target property was added to tell Visual  
Studio Generators for VS 2010 and above to mark a target for  
deployment even when not building for Windows Phone/Store/CE.

### Modules

- The “CheckLinkerFlag” module has been added to provide a facility to  
check validity of link flags.

- The “ExternalProject” module “ExternalProject\_Add()” command gained  
a new “GIT\_REMOTE\_UPDATE\_STRATEGY” keyword. This can be used to  
specify how failed rebase operations during a git update should be  
handled. The “CMAKE\_EP\_GIT\_REMOTE\_UPDATE\_STRATEGY” variable was also  
added as a global default and is honored by both the  
“ExternalProject” and “FetchContent” modules.

- The “FetchContent” module “FetchContent\_Declare()” command now  
supports a “SOURCE\_SUBDIR” option. It can be used to direct  
“FetchContent\_MakeAvailable()” to look in a different location for  
the “CMakeLists.txt” file.

- The “FindBLAS” module now provides an imported target.

- The “FindLAPACK” module now provides an imported target.

- The “FindPython3”, “FindPython2” and “FindPython” modules:

- The “FindRuby” module input and output variables were all renamed  
from “RUBY\_” to “Ruby\_” for consistency with other find modules.  
Input variables of the old case will be honored if provided, and  
output variables of the old case are always provided.

- The “FindSWIG” module now accepts target languages as “COMPONENTS”  
and “OPTIONAL\_COMPONENTS” arguments to “find\_package”.

- The “GoogleTest” module “gtest\_discover\_tests()” command:

- The “FindLibXslt” module now provides imported targets.

- The “UseSWIG” module now supports Fortran as a target language if  
the “SWIG\_EXECUTABLE” is SWIG-Fortran.

### Generator Expressions

- The “$\<DEVICE\_LINK:…\>” and “$\<HOST\_LINK:…\>” “generator  
expressions” were added to manage device and host link steps.

- The “$\<LINK\_LANGUAGE:…\>” and “$\<LINK\_LANG\_AND\_ID:…\>” “generator  
expressions” were added.

### CTest

- “ctest(1)” gained a new “CTEST\_RESOURCE\_SPEC\_FILE” variable, which  
can be used to specify a resource specification file.

- “ctest(1)” gained a “–stop-on-failure” option, which can be used to  
stop running the tests once one has failed.

- The “ctest\_test()” command gained a “STOP\_ON\_FAILURE” option which  
can be used to stop running the tests once one has failed.

- The “CTestCoverageCollectGCOV” module  
“ctest\_coverage\_collect\_gcov()” command gained a  
“TARBALL\_COMPRESSION” option to control compression of the tarball  
of collected results.

### CPack

- The “CPack Archive Generator”’s “TXZ” format learned the  
“CPACK\_ARCHIVE\_THREADS” variable to enable parallel compression.  
Requires support in the “liblzma” used by CMake.

- The “CPack NSIS Generator” gained a new variable  
“CPACK\_NSIS\_MANIFEST\_DPI\_AWARE” to declare that the installer is  
DPI-aware.

- The “CPack RPM Generator” gained “CPACK\_RPM\_PRE\_TRANS\_SCRIPT\_FILE”  
“CPACK\_RPM\_POST\_TRANS\_SCRIPT\_FILE” variables to specify pre- and  
post-trans scripts.

### Other

- “cmake-gui(1)” now populates its generator selection widget default  
value from the “CMAKE\_GENERATOR” environment variable.  
Additionally, environment variables “CMAKE\_GENERATOR\_PLATFORM” and  
“CMAKE\_GENERATOR\_TOOLSET” are used to populate their respective  
widget defaults.

- “ccmake(1)” learned to read a “CCMAKE\_COLORS” environment variable  
to customize colors.

## Deprecated and Removed Features

- The “Documentation” module has been deprecated via “CMP0106”. This  
module was essentially VTK code that CMake should not be shipping  
anymore.

- An explicit deprecation diagnostic was added for policy “CMP0070”  
and policy “CMP0071” (“CMP0069” 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.

## Other Changes

- On Windows, the “Ninja” and “Ninja Multi-Config” generators, when a  
compiler is not explicitly specified, now select the first compiler  
(of any name) found in directories listed by the “PATH” environment  
variable.

- The “LINK\_OPTIONS” and “INTERFACE\_LINK\_OPTIONS” target properties  
are now used for the device link step. See policy “CMP0105”.

- Creation of an “ALIAS” target overwriting an existing target now  
raises an error. See policy “CMP0107”.

- Linking a target to itself through an alias now raises an error. See  
policy “CMP0108”.

- The “FindPackageHandleStandardArgs” module option “REQUIRED\_VARS” is  
now optional if “HANDLE\_COMPONENTS” is specified.

- The “source\_group()” command now also recognizes forward slashes as  
subgroup delimiters, not just backslashes.

- “ctest(1)” now logs environment variables that it sets for each  
test, either due to the “ENVIRONMENT” property or the resource  
allocation feature, and submits this log to CDash. It does not log  
environment variables that were set outside of CTest.

- When building CMake itself from source and not using a system-  
provided libcurl, HTTP/2 support is now enabled for commands  
supporting network communication via “http(s)”, such as  
“file(DOWNLOAD)”, “file(UPLOAD)”, and “ctest\_submit()”. The  
precompiled binaries provided on “[cmake.org](http://cmake.org)” now support HTTP/2.

---

<div class="post-metadata">

### Author: ![Ubiquite](https://discourse.cmake.org/user_avatar/discourse.cmake.org/ubiquite/32/675_2.png) [@Ubiquite](https://discourse.cmake.org/u/Ubiquite)
#### Post date: [June 10, 2020, 2:32pm UTC](https://discourse.cmake.org/t/cmake-3-18-0-rc1-is-ready-for-testing/1360/2 "2020-06-10T14:32:22Z")

</div>

Hi and thank you for the great work

I felt excited by :

> The “VS\_PLATFORM\_TOOLSET” target property was added to tell Visual  
> Studio Generators for VS 2010 and above to override the platform  
> toolset.

But the doc seems to indicate that it’s unsafe if it use different compilers ?  
So for instance we can’t force v141 for one target if the default toolset is v142 ?  
I tested it and it seems to work though.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [June 10, 2020, 3:07pm UTC](https://discourse.cmake.org/t/cmake-3-18-0-rc1-is-ready-for-testing/1360/3 "2020-06-10T15:07:41Z")

</div>

@Ubiquite the implementation of that feature does not explicitly enforce any limitations, but if your setting chooses an incompatible `cl.exe` then the responsibility is yours. CMake only supports one compiler per language in general, and offers things like `CMAKE_C_COMPILER_{ID,VERSION}` on which projects can make decisions. If the final compiler used does not match then that is not supported. The use case for which `VS_PLATFORM_TOOLSET` was added uses the same compiler id/version.