cmake-variables (7) Linux Manual Page

cmake-variables – CMake Variables Reference

This page documents variables that are provided by CMake or have meaning to CMake when set by project code.

For general information on variables, see the Variables section in the cmake-language manual.

NOTE: CMake reserves identifiers that:

•

begin with CMAKE_ (upper-, lower-, or mixed-case), or

•

begin with _CMAKE_ (upper-, lower-, or mixed-case), or

•

begin with _ followed by the name of any CMake Command.

Variables That Provide Information

Cmake_Ar

Name of archiving tool for static libraries.

This specifies the name of the program that creates archive or static libraries.

Cmake_Argc

Number of command line arguments passed to CMake in script mode.

When run in -P script mode, CMake sets this variable to the number of command line arguments. See also CMAKE_ARGV0, 1, 2 …

Cmake_Argv0

Command line argument passed to CMake in script mode.

When run in -P script mode, CMake sets this variable to the first command line argument. It then also sets CMAKE_ARGV1, CMAKE_ARGV2, … and so on, up to the number of command line arguments given. See also CMAKE_ARGC.

Cmake_Binary_Dir

The path to the top level of the build tree.

This is the full path to the top level of the current CMake build tree. For an in-source build, this would be the same as CMAKE_SOURCE_DIR.

When run in -P script mode, CMake sets the variables CMAKE_BINARY_DIR, CMAKE_SOURCE_DIR, CMAKE_CURRENT_BINARY_DIR and CMAKE_CURRENT_SOURCE_DIR to the current working directory.

Cmake_Build_Tool

This variable exists only for backwards compatibility. It contains the same value as CMAKE_MAKE_PROGRAM. Use that variable instead.

Cmake_Cache_Major_Version

Major version of CMake used to create the CMakeCache.txt file

This stores the major version of CMake used to write a CMake cache file. It is only different when a different version of CMake is run on a previously created cache file.

Cmake_Cache_Minor_Version

Minor version of CMake used to create the CMakeCache.txt file

This stores the minor version of CMake used to write a CMake cache file. It is only different when a different version of CMake is run on a previously created cache file.

Cmake_Cache_Patch_Version

Patch version of CMake used to create the CMakeCache.txt file

This stores the patch version of CMake used to write a CMake cache file. It is only different when a different version of CMake is run on a previously created cache file.

Cmake_Cachefile_Dir

The directory with the CMakeCache.txt file.

This is the full path to the directory that has the CMakeCache.txt file in it. This is the same as CMAKE_BINARY_DIR.

Cmake_Cfg_Intdir

Deprecated since version 3.21: This variable has poor support on Ninja Multi-Config, and predates the existence of the $<CONFIG> generator expression. Use $<CONFIG> instead.

Build-time reference to per-configuration output subdirectory.

For native build systems supporting multiple configurations in the build tree (such as Visual Studio Generators and Xcode), the value is a reference to a build-time variable specifying the name of the per-configuration output subdirectory. On Makefile Generators this evaluates to . because there is only one configuration in a build tree. Example values:

$(ConfigurationName) = Visual Studio 9
$(Configuration) = Visual Studio 10
$(CONFIGURATION) = Xcode
. = Make-based tools
. = Ninja
${CONFIGURATION} = Ninja Multi-Config

Since these values are evaluated by the native build system, this variable is suitable only for use in command lines that will be evaluated at build time. Example of intended usage:

add_executable(mytool mytool.c)
add_custom_command(
 OUTPUT out.txt
 COMMAND ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/mytool
 ${CMAKE_CURRENT_SOURCE_DIR}/in.txt out.txt
 DEPENDS mytool in.txt
 )
add_custom_target(drive ALL DEPENDS out.txt)

Note that CMAKE_CFG_INTDIR is no longer necessary for this purpose but has been left for compatibility with existing projects. Instead add_custom_command() recognizes executable target names in its COMMAND option, so ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/mytool can be replaced by just mytool.

This variable is read-only. Setting it is undefined behavior. In multi-configuration build systems the value of this variable is passed as the value of preprocessor symbol CMAKE_INTDIR to the compilation of all source files.

Cmake_Command

The full path to the cmake(1) executable.

This is the full path to the CMake executable cmake(1) which is useful from custom commands that want to use the cmake -E option for portable system commands. (e.g. /usr/local/bin/cmake)

Cmake_Cpack_Command

New in version 3.13.

Full path to cpack(1) command installed with CMake.

This is the full path to the CPack executable cpack(1) which is useful from custom commands that want to use the cmake(1) -E option for portable system commands.

Cmake_Crosscompiling

Intended to indicate whether CMake is cross compiling, but note limitations discussed below.

This variable will be set to true by CMake if the CMAKE_SYSTEM_NAME variable has been set manually (i.e. in a toolchain file or as a cache entry from the cmake command line). In most cases, manually setting CMAKE_SYSTEM_NAME will only be done when cross compiling, since it will otherwise be given the same value as CMAKE_HOST_SYSTEM_NAME if not manually set, which is correct for the non-cross-compiling case. In the event that CMAKE_SYSTEM_NAME is manually set to the same value as CMAKE_HOST_SYSTEM_NAME, then CMAKE_CROSSCOMPILING will still be set to true.

Another case to be aware of is that builds targeting Apple platforms other than macOS are handled differently to other cross compiling scenarios. Rather than relying on CMAKE_SYSTEM_NAME to select the target platform, Apple device builds use CMAKE_OSX_SYSROOT to select the appropriate SDK, which indirectly determines the target platform. Furthermore, when using the Xcode generator, developers can switch between device and simulator builds at build time rather than having a single choice at configure time, so the concept of whether the build is cross compiling or not is more complex. Therefore, the use of CMAKE_CROSSCOMPILING is not recommended for projects targeting Apple devices.

Cmake_Crosscompiling_Emulator

New in version 3.3.

This variable is only used when CMAKE_CROSSCOMPILING is on. It should point to a command on the host system that can run executable built for the target system.

If this variable contains a semicolon-separated list, then the first value is the command and remaining values are its arguments.

The command will be used to run try_run() generated executables, which avoids manual population of the TryRunResults.cmake file.

It is also used as the default value for the CROSSCOMPILING_EMULATOR target property of executables.

Cmake_Ctest_Command

Full path to ctest(1) command installed with CMake.

This is the full path to the CTest executable ctest(1) which is useful from custom commands that want to use the cmake(1) -E option for portable system commands.

Cmake_Current_Binary_Dir

The path to the binary directory currently being processed.

This the full path to the build directory that is currently being processed by cmake. Each directory added by add_subdirectory() will create a binary directory in the build tree, and as it is being processed this variable will be set. For in-source builds this is the current source directory being processed.

When run in -P script mode, CMake sets the variables CMAKE_BINARY_DIR, CMAKE_SOURCE_DIR, CMAKE_CURRENT_BINARY_DIR and CMAKE_CURRENT_SOURCE_DIR to the current working directory.

Cmake_Current_Function

New in version 3.17.

When executing code inside a function(), this variable contains the name of the current function. It can be useful for diagnostic or debug messages.

See also CMAKE_CURRENT_FUNCTION_LIST_DIR, CMAKE_CURRENT_FUNCTION_LIST_FILE and CMAKE_CURRENT_FUNCTION_LIST_LINE.

Cmake_Current_Function_List_Dir

New in version 3.17.

When executing code inside a function(), this variable contains the full directory of the listfile that defined the current function.

It is quite common practice in CMake for modules to use some additional files, such as templates to be copied in after substituting CMake variables. In such cases, a function needs to know where to locate those files in a way that doesn’t depend on where the function is called. Without CMAKE_CURRENT_FUNCTION_LIST_DIR, the code to do that would typically use the following pattern:

set(_THIS_MODULE_BASE_DIR "${CMAKE_CURRENT_LIST_DIR}")
function(foo)
 configure_file(
 "${_THIS_MODULE_BASE_DIR}/some.template.in"
 some.output
 )
endfunction()

Using CMAKE_CURRENT_FUNCTION_LIST_DIR inside the function instead eliminates the need for the extra variable which would otherwise be visible outside the function’s scope. The above example can be written in the more concise and more robust form:

function(foo)
 configure_file(
 "${CMAKE_CURRENT_FUNCTION_LIST_DIR}/some.template.in"
 some.output
 )
endfunction()

See also CMAKE_CURRENT_FUNCTION, CMAKE_CURRENT_FUNCTION_LIST_FILE and CMAKE_CURRENT_FUNCTION_LIST_LINE.

Cmake_Current_Function_List_File

New in version 3.17.

When executing code inside a function(), this variable contains the full path to the listfile that defined the current function.

See also CMAKE_CURRENT_FUNCTION, CMAKE_CURRENT_FUNCTION_LIST_DIR and CMAKE_CURRENT_FUNCTION_LIST_LINE.

Cmake_Current_Function_List_Line

New in version 3.17.

When executing code inside a function(), this variable contains the line number in the listfile where the current function was defined.

See also CMAKE_CURRENT_FUNCTION, CMAKE_CURRENT_FUNCTION_LIST_DIR and CMAKE_CURRENT_FUNCTION_LIST_FILE.

Cmake_Current_List_Dir

Full directory of the listfile currently being processed.

As CMake processes the listfiles in your project this variable will always be set to the directory where the listfile which is currently being processed (CMAKE_CURRENT_LIST_FILE) is located. The value has dynamic scope. When CMake starts processing commands in a source file it sets this variable to the directory where this file is located. When CMake finishes processing commands from the file it restores the previous value. Therefore the value of the variable inside a macro or function is the directory of the file invoking the bottom-most entry on the call stack, not the directory of the file containing the macro or function definition.

See also CMAKE_CURRENT_LIST_FILE.

Cmake_Current_List_File

Full path to the listfile currently being processed.

As CMake processes the listfiles in your project this variable will always be set to the one currently being processed. The value has dynamic scope. When CMake starts processing commands in a source file it sets this variable to the location of the file. When CMake finishes processing commands from the file it restores the previous value. Therefore the value of the variable inside a macro or function is the file invoking the bottom-most entry on the call stack, not the file containing the macro or function definition.

See also CMAKE_PARENT_LIST_FILE.

Cmake_Current_List_Line

The line number of the current file being processed.

This is the line number of the file currently being processed by cmake.

If CMake is currently processing deferred calls scheduled by the cmake_language(DEFER) command, this variable evaluates to DEFERRED instead of a specific line number.

Cmake_Current_Source_Dir

The path to the source directory currently being processed.

This the full path to the source directory that is currently being processed by cmake.

When run in -P script mode, CMake sets the variables CMAKE_BINARY_DIR, CMAKE_SOURCE_DIR, CMAKE_CURRENT_BINARY_DIR and CMAKE_CURRENT_SOURCE_DIR to the current working directory.

Cmake_Debug_Target_Properties

Enables tracing output for target properties.

This variable can be populated with a list of properties to generate debug output for when evaluating target properties. Currently it can only be used when evaluating:

•

AUTOUIC_OPTIONS

•

COMPILE_DEFINITIONS

•

COMPILE_FEATURES

•

COMPILE_OPTIONS

•

INCLUDE_DIRECTORIES

•

LINK_DIRECTORIES

•

LINK_OPTIONS

•

POSITION_INDEPENDENT_CODE

•

SOURCES

target properties and any other property listed in COMPATIBLE_INTERFACE_STRING and other COMPATIBLE_INTERFACE_ properties. It outputs an origin for each entry in the target property. Default is unset.

Cmake_Directory_Labels

New in version 3.10.

Specify labels for the current directory.

This is used to initialize the LABELS directory property.

Cmake_Dl_Libs

Name of library containing dlopen and dlclose.

The name of the library that has dlopen and dlclose in it, usually -ldl on most UNIX machines.

Cmake_Dotnet_Target_Framework

New in version 3.17.

Default value for DOTNET_TARGET_FRAMEWORK property of targets.

This variable is used to initialize the DOTNET_TARGET_FRAMEWORK property on all targets. See that target property for additional information.

Setting CMAKE_DOTNET_TARGET_FRAMEWORK may be necessary when working with C# and newer .NET framework versions to avoid referencing errors with the ALL_BUILD CMake target.

This variable is only evaluated for Visual Studio Generators VS 2010 and above.

Cmake_Dotnet_Target_Framework_Version

New in version 3.12.

Default value for DOTNET_TARGET_FRAMEWORK_VERSION property of targets.

This variable is used to initialize the DOTNET_TARGET_FRAMEWORK_VERSION property on all targets. See that target property for additional information. When set, CMAKE_DOTNET_TARGET_FRAMEWORK takes precednece over this variable. See that variable or the associated target property DOTNET_TARGET_FRAMEWORK for additional information.

Setting CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION may be necessary when working with C# and newer .NET framework versions to avoid referencing errors with the ALL_BUILD CMake target.

This variable is only evaluated for Visual Studio Generators VS 2010 and above.

Cmake_Edit_Command

Full path to cmake-gui(1) or ccmake(1). Defined only for Makefile Generators when not using an "extra" generator for an IDE.

This is the full path to the CMake executable that can graphically edit the cache. For example, cmake-gui(1) or ccmake(1).

Cmake_Executable_Suffix

The suffix for executables on this platform.

The suffix to use for the end of an executable filename if any, .exe on Windows.

CMAKE_EXECUTABLE_SUFFIX_<LANG> overrides this for language <LANG>.

CMAKE_EXECUTABLE_SUFFIX_<LANG>

The suffix to use for the end of an executable filename of <LANG> compiler target architecture, if any.

It overrides CMAKE_EXECUTABLE_SUFFIX for language <LANG>.

Cmake_Extra_Generator

The extra generator used to build the project. See cmake-generators(7).

When using the Eclipse, CodeBlocks, CodeLite, Kate or Sublime generators, CMake generates Makefiles (CMAKE_GENERATOR) and additionally project files for the respective IDE. This IDE project file generator is stored in CMAKE_EXTRA_GENERATOR (e.g. Eclipse CDT4).

Cmake_Extra_Shared_Library_Suffixes

Additional suffixes for shared libraries.

Extensions for shared libraries other than that specified by CMAKE_SHARED_LIBRARY_SUFFIX, if any. CMake uses this to recognize external shared library files during analysis of libraries linked by a target.

Cmake_Find_Debug_Mode

New in version 3.17.

Print extra find call information for the following commands to standard error:

•

find_program()

•

find_library()

•

find_file()

•

find_path()

•

find_package()

Output is designed for human consumption and not for parsing. Enabling this variable is equivalent to using cmake –debug-find with the added ability to enable debugging for a subset of find calls.

set(CMAKE_FIND_DEBUG_MODE TRUE)
find_program(...)
set(CMAKE_FIND_DEBUG_MODE FALSE)

Default is unset.

Cmake_Find_Package_Name

New in version 3.1.1.

Defined by the find_package() command while loading a find module to record the caller-specified package name. See command documentation for details.

Cmake_Find_Package_Sort_Direction

New in version 3.7.

The sorting direction used by CMAKE_FIND_PACKAGE_SORT_ORDER. It can assume one of the following values:

DEC

Default. Ordering is done in descending mode. The highest folder found will be tested first.

ASC

Ordering is done in ascending mode. The lowest folder found will be tested first.

If CMAKE_FIND_PACKAGE_SORT_ORDER is not set or is set to NONE this variable has no effect.

Cmake_Find_Package_Sort_Order

New in version 3.7.

The default order for sorting packages found using find_package(). It can assume one of the following values:

NONE

Default. No attempt is done to sort packages. The first valid package found will be selected.

NAME

Sort packages lexicographically before selecting one.

NATURAL

Sort packages using natural order (see strverscmp(3) manual), i.e. such that contiguous digits are compared as whole numbers.

Natural sorting can be employed to return the highest version when multiple versions of the same library are found by find_package(). For example suppose that the following libraries have been found:

•

libX-1.1.0

•

libX-1.2.9

•

libX-1.2.10

By setting NATURAL order we can select the one with the highest version number libX-1.2.10.

set(CMAKE_FIND_PACKAGE_SORT_ORDER NATURAL)
find_package(libX CONFIG)

The sort direction can be controlled using the CMAKE_FIND_PACKAGE_SORT_DIRECTION variable (by default decrescent, e.g. lib-B will be tested before lib-A).

Cmake_Generator

The generator used to build the project. See cmake-generators(7).

The name of the generator that is being used to generate the build files. (e.g. Unix Makefiles, Ninja, etc.)

The value of this variable should never be modified by project code. A generator may be selected via the cmake(1) -G option, interactively in cmake-gui(1), or via the CMAKE_GENERATOR environment variable.

Cmake_Generator_Instance

New in version 3.11.

Generator-specific instance specification provided by user.

Some CMake generators support selection of an instance of the native build system when multiple instances are available. If the user specifies an instance (e.g. by setting this cache entry or via the CMAKE_GENERATOR_INSTANCE environment variable), or after a default instance is chosen when a build tree is first configured, the value will be available in this variable.

The value of this variable should never be modified by project code. A toolchain file specified by the CMAKE_TOOLCHAIN_FILE variable may initialize CMAKE_GENERATOR_INSTANCE as a cache entry. Once a given build tree has been initialized with a particular value for this variable, changing the value has undefined behavior.

Instance specification is supported only on specific generators:

•

For the Visual Studio 15 2017 generator (and above) this specifies the absolute path to the VS installation directory of the selected VS instance.

See native build system documentation for allowed instance values.

Cmake_Generator_Platform

New in version 3.1.

Generator-specific target platform specification provided by user.

Some CMake generators support a target platform name to be given to the native build system to choose a compiler toolchain. If the user specifies a platform name (e.g. via the cmake(1) -A option or via the CMAKE_GENERATOR_PLATFORM environment variable) the value will be available in this variable.

The value of this variable should never be modified by project code. A toolchain file specified by the CMAKE_TOOLCHAIN_FILE variable may initialize CMAKE_GENERATOR_PLATFORM. Once a given build tree has been initialized with a particular value for this variable, changing the value has undefined behavior.

Platform specification is supported only on specific generators:

•

For Visual Studio Generators with VS 2005 and above this specifies the target architecture.

•

For Green Hills MULTI this specifies the target architecture.

See native build system documentation for allowed platform names.

Visual Studio Platform Selection

On Visual Studio Generators the selected platform name is provided in the CMAKE_VS_PLATFORM_NAME variable.

Cmake_Generator_Toolset

Native build system toolset specification provided by user.

Some CMake generators support a toolset specification to tell the native build system how to choose a compiler. If the user specifies a toolset (e.g. via the cmake(1) -T option or via the CMAKE_GENERATOR_TOOLSET environment variable) the value will be available in this variable.

The value of this variable should never be modified by project code. A toolchain file specified by the CMAKE_TOOLCHAIN_FILE variable may initialize CMAKE_GENERATOR_TOOLSET. Once a given build tree has been initialized with a particular value for this variable, changing the value has undefined behavior.

Toolset specification is supported only on specific generators:

•

Visual Studio Generators for VS 2010 and above

•

The Xcode generator for Xcode 3.0 and above

•

The Green Hills MULTI generator

See native build system documentation for allowed toolset names.

Visual Studio Toolset Selection

The Visual Studio Generators support toolset specification using one of these forms:

•

toolset

•

toolset[,key=value]*

•

key=value[,key=value]*

The toolset specifies the toolset name. The selected toolset name is provided in the CMAKE_VS_PLATFORM_TOOLSET variable.

The key=value pairs form a comma-separated list of options to specify generator-specific details of the toolset selection. Supported pairs are:

cuda=<version>|<path>

Specify the CUDA toolkit version to use or the path to a standalone CUDA toolkit directory. Supported by VS 2010 and above. The version can only be used with the CUDA toolkit VS integration globally installed. See the CMAKE_VS_PLATFORM_TOOLSET_CUDA and CMAKE_VS_PLATFORM_TOOLSET_CUDA_CUSTOM_DIR variables.

host=<arch>

Specify the host tools architecture as x64 or x86. Supported by VS 2013 and above. See the CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE variable.

version=<version>

Specify the toolset version to use. Supported by VS 2017 and above with the specified toolset installed. See the CMAKE_VS_PLATFORM_TOOLSET_VERSION variable.

VCTargetsPath=<path>

Specify an alternative VCTargetsPath value for Visual Studio project files. This allows use of VS platform extension configuration files (.props and .targets) that are not installed with VS.

Visual Studio Toolset Customization

These are unstable interfaces with no compatibility guarantees because they hook into undocumented internal CMake implementation details. Institutions may use these to internally maintain support for non-public Visual Studio platforms and toolsets, but must accept responsibility to make updates as changes are made to CMake.

Additional key=value pairs are available:

customFlagTableDir=<path>

New in version 3.21.

Specify the absolute path to a directory from which to load custom flag tables stored as JSON documents with file names of the form <platform>_<toolset>_<tool>.json or <platform>_<tool>.json, where <platform> is the CMAKE_VS_PLATFORM_NAME, <toolset> is the CMAKE_VS_PLATFORM_TOOLSET, and <tool> is the tool for which the flag table is meant. This naming pattern is an internal CMake implementation detail. The <tool> names are undocumented. The format of the .json flag table files is undocumented.

Cmake_Import_Library_Prefix

The prefix for import libraries that you link to.

The prefix to use for the name of an import library if used on this platform.

CMAKE_IMPORT_LIBRARY_PREFIX_<LANG> overrides this for language <LANG>.

Cmake_Import_Library_Suffix

The suffix for import libraries that you link to.

The suffix to use for the end of an import library filename if used on this platform.

CMAKE_IMPORT_LIBRARY_SUFFIX_<LANG> overrides this for language <LANG>.

Cmake_Job_Pool_Compile

This variable is used to initialize the JOB_POOL_COMPILE property on all the targets. See JOB_POOL_COMPILE for additional information.

Cmake_Job_Pool_Link

This variable is used to initialize the JOB_POOL_LINK property on all the targets. See JOB_POOL_LINK for additional information.

Cmake_Job_Pool_Precompile_Header

New in version 3.17.

This variable is used to initialize the JOB_POOL_PRECOMPILE_HEADER property on all the targets. See JOB_POOL_PRECOMPILE_HEADER for additional information.

Cmake_Job_Pools

New in version 3.11.

If the JOB_POOLS global property is not set, the value of this variable is used in its place. See JOB_POOLS for additional information.

CMAKE_<LANG>_COMPILER_AR

New in version 3.9.

A wrapper around ar adding the appropriate –plugin option for the compiler.

See also CMAKE_AR.

CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT

New in version 3.14.

Identification string of the compiler frontend variant.

Some compilers have multiple, different frontends for accepting command line options. (For example Clang originally only had a frontend compatible with the GNU compiler but since its port to Windows (Clang-Cl) it now also supports a frontend compatible with MSVC.) When CMake detects such a compiler it sets this variable to what would have been the CMAKE_<LANG>_COMPILER_ID for the compiler whose frontend it resembles.

NOTE: In other words, this variable describes what command line options and language extensions the compiler frontend expects.

CMAKE_<LANG>_COMPILER_RANLIB

New in version 3.9.

A wrapper around ranlib adding the appropriate –plugin option for the compiler.

See also CMAKE_RANLIB.

CMAKE_<LANG>_LINK_LIBRARY_SUFFIX

New in version 3.16.

Language-specific suffix for libraries that you link to.

The suffix to use for the end of a library filename, .lib on Windows.

Cmake_Link_Library_Suffix

The suffix for libraries that you link to.

The suffix to use for the end of a library filename, .lib on Windows.

Cmake_Link_Search_End_Static

New in version 3.4.

End a link line such that static system libraries are used.

Some linkers support switches such as -Bstatic and -Bdynamic to determine whether to use static or shared libraries for -lXXX options. CMake uses these options to set the link type for libraries whose full paths are not known or (in some cases) are in implicit link directories for the platform. By default CMake adds an option at the end of the library list (if necessary) to set the linker search type back to its starting type. This property switches the final linker search type to -Bstatic regardless of how it started.

This variable is used to initialize the target property LINK_SEARCH_END_STATIC for all targets. If set, its value is also used by the try_compile() command.

See also CMAKE_LINK_SEARCH_START_STATIC.

Cmake_Link_Search_Start_Static

New in version 3.4.

Assume the linker looks for static libraries by default.

Some linkers support switches such as -Bstatic and -Bdynamic to determine whether to use static or shared libraries for -lXXX options. CMake uses these options to set the link type for libraries whose full paths are not known or (in some cases) are in implicit link directories for the platform. By default the linker search type is assumed to be -Bdynamic at the beginning of the library list. This property switches the assumption to -Bstatic. It is intended for use when linking an executable statically (e.g. with the GNU -static option).

This variable is used to initialize the target property LINK_SEARCH_START_STATIC for all targets. If set, its value is also used by the try_compile() command.

See also CMAKE_LINK_SEARCH_END_STATIC.

Cmake_Major_Version

First version number component of the CMAKE_VERSION variable.

Cmake_Make_Program

Tool that can launch the native build system. The value may be the full path to an executable or just the tool name if it is expected to be in the PATH.

The tool selected depends on the CMAKE_GENERATOR used to configure the project:

•

The Makefile Generators set this to make, gmake, or a generator-specific tool (e.g. nmake for NMake Makefiles).

These generators store CMAKE_MAKE_PROGRAM in the CMake cache so that it may be edited by the user.

•

The Ninja generator sets this to ninja.

This generator stores CMAKE_MAKE_PROGRAM in the CMake cache so that it may be edited by the user.

•

The Xcode generator sets this to xcodebuild.

This generator prefers to lookup the build tool at build time rather than to store CMAKE_MAKE_PROGRAM in the CMake cache ahead of time. This is because xcodebuild is easy to find.

For compatibility with versions of CMake prior to 3.2, if a user or project explicitly adds CMAKE_MAKE_PROGRAM to the CMake cache then CMake will use the specified value.

•

The Visual Studio Generators set this to the full path to MSBuild.exe (VS >= 10), devenv.com (VS 7,8,9), or VCExpress.exe (VS Express 8,9). (See also variables CMAKE_VS_MSBUILD_COMMAND and CMAKE_VS_DEVENV_COMMAND.

These generators prefer to lookup the build tool at build time rather than to store CMAKE_MAKE_PROGRAM in the CMake cache ahead of time. This is because the tools are version-specific and can be located using the Windows Registry. It is also necessary because the proper build tool may depend on the project content (e.g. the Intel Fortran plugin to VS 10 and 11 requires devenv.com to build its .vfproj project files even though MSBuild.exe is normally preferred to support the CMAKE_GENERATOR_TOOLSET).

For compatibility with versions of CMake prior to 3.0, if a user or project explicitly adds CMAKE_MAKE_PROGRAM to the CMake cache then CMake will use the specified value if possible.

•

The Green Hills MULTI generator sets this to the full path to gbuild.exe(Windows) or gbuild(Linux) based upon the toolset being used.

Once the generator has initialized a particular value for this variable, changing the value has undefined behavior.

The CMAKE_MAKE_PROGRAM variable is set for use by project code. The value is also used by the cmake(1) –build and ctest(1) –build-and-test tools to launch the native build process.

Cmake_Match_Count

New in version 3.2.

The number of matches with the last regular expression.

When a regular expression match is used, CMake fills in CMAKE_MATCH_<n> variables with the match contents. The CMAKE_MATCH_COUNT variable holds the number of match expressions when these are filled.

CMAKE_MATCH_<n>

New in version 3.9.

Capture group <n> matched by the last regular expression, for groups 0 through 9. Group 0 is the entire match. Groups 1 through 9 are the subexpressions captured by () syntax.

When a regular expression match is used, CMake fills in CMAKE_MATCH_<n> variables with the match contents. The CMAKE_MATCH_COUNT variable holds the number of match expressions when these are filled.

Cmake_Minimum_Required_Version

The <min> version of CMake given to the most recent call to the cmake_minimum_required(VERSION) command in the current variable scope or any parent variable scope.

Cmake_Minor_Version

Second version number component of the CMAKE_VERSION variable.

Cmake_Netrc

New in version 3.11.

This variable is used to initialize the NETRC option for the file(DOWNLOAD) and file(UPLOAD) commands. See those commands for additional information.

This variable is also used by the ExternalProject and FetchContent modules for internal calls to file(DOWNLOAD).

The local option takes precedence over this variable.

Cmake_Netrc_File

New in version 3.11.

This variable is used to initialize the NETRC_FILE option for the file(DOWNLOAD) and file(UPLOAD) commands. See those commands for additional information.

This variable is also used by the ExternalProject and FetchContent modules for internal calls to file(DOWNLOAD).

The local option takes precedence over this variable.

Cmake_Parent_List_File

Full path to the CMake file that included the current one.

While processing a CMake file loaded by include() or find_package() this variable contains the full path to the file including it. The top of the include stack is always the CMakeLists.txt for the current directory. See also CMAKE_CURRENT_LIST_FILE.

Cmake_Patch_Version

Third version number component of the CMAKE_VERSION variable.

Cmake_Project_Description

New in version 3.9.

The description of the top level project.

This variable holds the description of the project as specified in the top level CMakeLists.txt file by a project() command. In the event that the top level CMakeLists.txt contains multiple project() calls, the most recently called one from that top level CMakeLists.txt will determine the value that CMAKE_PROJECT_DESCRIPTION contains. For example, consider the following top level CMakeLists.txt:

cmake_minimum_required(VERSION 3.0)
project(First DESCRIPTION "I am First")
project(Second DESCRIPTION "I am Second")
add_subdirectory(sub)
project(Third DESCRIPTION "I am Third")

And sub/CMakeLists.txt with the following contents:

project(SubProj DESCRIPTION "I am SubProj")
message("CMAKE_PROJECT_DESCRIPTION = ${CMAKE_PROJECT_DESCRIPTION}")

The most recently seen project() command from the top level CMakeLists.txt would be project(Second …), so this will print:

CMAKE_PROJECT_DESCRIPTION = I am Second

To obtain the description from the most recent call to project() in the current directory scope or above, see the PROJECT_DESCRIPTION variable.

Cmake_Project_Homepage_Url

New in version 3.12.

The homepage URL of the top level project.

This variable holds the homepage URL of the project as specified in the top level CMakeLists.txt file by a project() command. In the event that the top level CMakeLists.txt contains multiple project() calls, the most recently called one from that top level CMakeLists.txt will determine the value that CMAKE_PROJECT_HOMEPAGE_URL contains. For example, consider the following top level CMakeLists.txt:

cmake_minimum_required(VERSION 3.0)
project(First HOMEPAGE_URL "http://first.example.com")
project(Second HOMEPAGE_URL "http://second.example.com")
add_subdirectory(sub)
project(Third HOMEPAGE_URL "http://third.example.com")

And sub/CMakeLists.txt with the following contents:

project(SubProj HOMEPAGE_URL "http://subproj.example.com")
message("CMAKE_PROJECT_HOMEPAGE_URL = ${CMAKE_PROJECT_HOMEPAGE_URL}")

The most recently seen project() command from the top level CMakeLists.txt would be project(Second …), so this will print:

CMAKE_PROJECT_HOMEPAGE_URL = http://second.example.com

To obtain the homepage URL from the most recent call to project() in the current directory scope or above, see the PROJECT_HOMEPAGE_URL variable.

Cmake_Project_Name

The name of the top level project.

This variable holds the name of the project as specified in the top level CMakeLists.txt file by a project() command. In the event that the top level CMakeLists.txt contains multiple project() calls, the most recently called one from that top level CMakeLists.txt will determine the name that CMAKE_PROJECT_NAME contains. For example, consider the following top level CMakeLists.txt:

cmake_minimum_required(VERSION 3.0)
project(First)
project(Second)
add_subdirectory(sub)
project(Third)

And sub/CMakeLists.txt with the following contents:

project(SubProj)
message("CMAKE_PROJECT_NAME = ${CMAKE_PROJECT_NAME}")

The most recently seen project() command from the top level CMakeLists.txt would be project(Second), so this will print:

CMAKE_PROJECT_NAME = Second

To obtain the name from the most recent call to project() in the current directory scope or above, see the PROJECT_NAME variable.

Cmake_Project_Version

New in version 3.12.

The version of the top level project.

This variable holds the version of the project as specified in the top level CMakeLists.txt file by a project() command. In the event that the top level CMakeLists.txt contains multiple project() calls, the most recently called one from that top level CMakeLists.txt will determine the value that CMAKE_PROJECT_VERSION contains. For example, consider the following top level CMakeLists.txt:

cmake_minimum_required(VERSION 3.0)
project(First VERSION 1.2.3)
project(Second VERSION 3.4.5)
add_subdirectory(sub)
project(Third VERSION 6.7.8)

And sub/CMakeLists.txt with the following contents:

project(SubProj VERSION 1)
message("CMAKE_PROJECT_VERSION = ${CMAKE_PROJECT_VERSION}")

The most recently seen project() command from the top level CMakeLists.txt would be project(Second …), so this will print:

CMAKE_PROJECT_VERSION = 3.4.5

To obtain the version from the most recent call to project() in the current directory scope or above, see the PROJECT_VERSION variable.

Cmake_Project_Version_Major

New in version 3.12.

The major version of the top level project.

This variable holds the major version of the project as specified in the top level CMakeLists.txt file by a project() command. Please see CMAKE_PROJECT_VERSION documentation for the behavior when multiple project() commands are used in the sources.

Cmake_Project_Version_Minor

New in version 3.12.

The minor version of the top level project.

This variable holds the minor version of the project as specified in the top level CMakeLists.txt file by a project() command. Please see CMAKE_PROJECT_VERSION documentation for the behavior when multiple project() commands are used in the sources.

Cmake_Project_Version_Patch

New in version 3.12.

The patch version of the top level project.

This variable holds the patch version of the project as specified in the top level CMakeLists.txt file by a project() command. Please see CMAKE_PROJECT_VERSION documentation for the behavior when multiple project() commands are used in the sources.

Cmake_Project_Version_Tweak

New in version 3.12.

The tweak version of the top level project.

This variable holds the tweak version of the project as specified in the top level CMakeLists.txt file by a project() command. Please see CMAKE_PROJECT_VERSION documentation for the behavior when multiple project() commands are used in the sources.

Cmake_Ranlib

Name of randomizing tool for static libraries.

This specifies name of the program that randomizes libraries on UNIX, not used on Windows, but may be present.

Cmake_Root

Install directory for running cmake.

This is the install root for the running CMake and the Modules directory can be found here. This is commonly used in this format: ${CMAKE_ROOT}/Modules

Cmake_Rule_Messages

New in version 3.13.

Specify whether to report a message for each make rule.

If set in the cache it is used to initialize the value of the RULE_MESSAGES property. Users may disable the option in their local build tree to disable granular messages and report only as each target completes in Makefile builds.

Cmake_Script_Mode_File

Full path to the cmake(1) -P script file currently being processed.

When run in cmake(1) -P script mode, CMake sets this variable to the full path of the script file. When run to configure a CMakeLists.txt file, this variable is not set.

Cmake_Shared_Library_Prefix

The prefix for shared libraries that you link to.

The prefix to use for the name of a shared library, lib on UNIX.

CMAKE_SHARED_LIBRARY_PREFIX_<LANG> overrides this for language <LANG>.

Cmake_Shared_Library_Suffix

The suffix for shared libraries that you link to.

The suffix to use for the end of a shared library filename, .dll on Windows.

CMAKE_SHARED_LIBRARY_SUFFIX_<LANG> overrides this for language <LANG>.

Cmake_Shared_Module_Prefix

The prefix for loadable modules that you link to.

The prefix to use for the name of a loadable module on this platform.

CMAKE_SHARED_MODULE_PREFIX_<LANG> overrides this for language <LANG>.

Cmake_Shared_Module_Suffix

The suffix for shared libraries that you link to.

The suffix to use for the end of a loadable module filename on this platform

CMAKE_SHARED_MODULE_SUFFIX_<LANG> overrides this for language <LANG>.

Cmake_Sizeof_Void_P

Size of a void pointer.

This is set to the size of a pointer on the target machine, and is determined by a try compile. If a 64-bit size is found, then the library search path is modified to look for 64-bit libraries first.

Cmake_Skip_Install_Rules

Whether to disable generation of installation rules.

If TRUE, CMake will neither generate installation rules nor will it generate cmake_install.cmake files. This variable is FALSE by default.

Cmake_Skip_Rpath

If true, do not add run time path information.

If this is set to TRUE, then the rpath information is not added to compiled executables. The default is to add rpath information if the platform supports it. This allows for easy running from the build tree. To omit RPATH in the install step, but not the build step, use CMAKE_SKIP_INSTALL_RPATH instead.

Cmake_Source_Dir

The path to the top level of the source tree.

This is the full path to the top level of the current CMake source tree. For an in-source build, this would be the same as CMAKE_BINARY_DIR.

When run in -P script mode, CMake sets the variables CMAKE_BINARY_DIR, CMAKE_SOURCE_DIR, CMAKE_CURRENT_BINARY_DIR and CMAKE_CURRENT_SOURCE_DIR to the current working directory.

Cmake_Static_Library_Prefix

The prefix for static libraries that you link to.

The prefix to use for the name of a static library, lib on UNIX.

CMAKE_STATIC_LIBRARY_PREFIX_<LANG> overrides this for language <LANG>.

Cmake_Static_Library_Suffix

The suffix for static libraries that you link to.

The suffix to use for the end of a static library filename, .lib on Windows.

CMAKE_STATIC_LIBRARY_SUFFIX_<LANG> overrides this for language <LANG>.

CMAKE_Swift_MODULE_DIRECTORY

New in version 3.15.

Swift module output directory.

This variable is used to initialize the Swift_MODULE_DIRECTORY property on all the targets. See the target property for additional information.

CMAKE_Swift_NUM_THREADS

New in version 3.15.1.

Number of threads for parallel compilation for Swift targets.

This variable controls the number of parallel jobs that the swift driver creates for building targets. If not specified, it will default to the number of logical CPUs on the host.

Cmake_Toolchain_File

Path to toolchain file supplied to cmake(1).

This variable is specified on the command line when cross-compiling with CMake. It is the path to a file which is read early in the CMake run and which specifies locations for compilers and toolchain utilities, and other target platform and compiler related information.

Relative paths are allowed and are interpreted first as relative to the build directory, and if not found, relative to the source directory.

This is initialized by the CMAKE_TOOLCHAIN_FILE environment variable if it is set when a new build tree is first created.

Cmake_Tweak_Version

Defined to 0 for compatibility with code written for older CMake versions that may have defined higher values.

NOTE: In CMake versions 2.8.2 through 2.8.12, this variable holds the fourth version number component of the CMAKE_VERSION variable.

Cmake_Verbose_Makefile

Enable verbose output from Makefile builds.

This variable is a cache entry initialized (to FALSE) by the project() command. Users may enable the option in their local build tree to get more verbose output from Makefile builds and show each command line as it is launched.

Cmake_Version

The CMake version string as three non-negative integer components separated by . and possibly followed by – and other information. The first two components represent the feature level and the third component represents either a bug-fix level or development date.

Release versions and release candidate versions of CMake use the format:

<major>.<minor>.<patch>[-rc<n>]

where the <patch> component is less than 20000000. Development versions of CMake use the format:

<major>.<minor>.<date>[-<id>]

where the <date> component is of format CCYYMMDD and <id> may contain arbitrary text. This represents development as of a particular date following the <major>.<minor> feature release.

Individual component values are also available in variables:

•

CMAKE_MAJOR_VERSION

•

CMAKE_MINOR_VERSION

•

CMAKE_PATCH_VERSION

•

CMAKE_TWEAK_VERSION

Use the if() command VERSION_LESS, VERSION_GREATER, VERSION_EQUAL, VERSION_LESS_EQUAL, or VERSION_GREATER_EQUAL operators to compare version string values against CMAKE_VERSION using a component-wise test. Version component values may be 10 or larger so do not attempt to compare version strings as floating-point numbers.

NOTE: CMake versions 2.8.2 through 2.8.12 used three components for the feature level. Release versions represented the bug-fix level in a fourth component, i.e. <major>.<minor>.<patch>[.<tweak>][-rc<n>]. Development versions represented the development date in the fourth component, i.e. <major>.<minor>.<patch>.<date>[-<id>].

CMake versions prior to 2.8.2 used three components for the feature level and had no bug-fix component. Release versions used an even-valued second component, i.e. <major>.<even-minor>.<patch>[-rc<n>]. Development versions used an odd-valued second component with the development date as the third component, i.e. <major>.<odd-minor>.<date>.

The CMAKE_VERSION variable is defined by CMake 2.6.3 and higher. Earlier versions defined only the individual component variables.

Cmake_Vs_Devenv_Command

The generators for Visual Studio 9 2008 and above set this variable to the devenv.com command installed with the corresponding Visual Studio version. Note that this variable may be empty on Visual Studio Express editions because they do not provide this tool.

This variable is not defined by other generators even if devenv.com is installed on the computer.

The CMAKE_VS_MSBUILD_COMMAND is also provided for Visual Studio 10 2010 and above. See also the CMAKE_MAKE_PROGRAM variable.

Cmake_Vs_Msbuild_Command

The generators for Visual Studio 10 2010 and above set this variable to the MSBuild.exe command installed with the corresponding Visual Studio version.

This variable is not defined by other generators even if MSBuild.exe is installed on the computer.

The CMAKE_VS_DEVENV_COMMAND is also provided for the non-Express editions of Visual Studio. See also the CMAKE_MAKE_PROGRAM variable.

CMAKE_VS_NsightTegra_VERSION

New in version 3.1.

When using a Visual Studio generator with the CMAKE_SYSTEM_NAME variable set to Android, this variable contains the version number of the installed NVIDIA Nsight Tegra Visual Studio Edition.

Cmake_Vs_Platform_Name

New in version 3.1.

Visual Studio target platform name used by the current generator.

VS 8 and above allow project files to specify a target platform. CMake provides the name of the chosen platform in this variable. See the CMAKE_GENERATOR_PLATFORM variable for details.

See also the CMAKE_VS_PLATFORM_NAME_DEFAULT variable.

Cmake_Vs_Platform_Name_Default

New in version 3.14.3.

Default for the Visual Studio target platform name for the current generator without considering the value of the CMAKE_GENERATOR_PLATFORM variable. For Visual Studio Generators for VS 2017 and below this is always Win32. For VS 2019 and above this is based on the host platform.

See also the CMAKE_VS_PLATFORM_NAME variable.

Cmake_Vs_Platform_Toolset

Visual Studio Platform Toolset name.

VS 10 and above use MSBuild under the hood and support multiple compiler toolchains. CMake may specify a toolset explicitly, such as v110 for VS 11 or Windows7.1SDK for 64-bit support in VS 10 Express. CMake provides the name of the chosen toolset in this variable.

See the CMAKE_GENERATOR_TOOLSET variable for details.

Cmake_Vs_Platform_Toolset_Cuda

New in version 3.9.

NVIDIA CUDA Toolkit version whose Visual Studio toolset to use.

The Visual Studio Generators for VS 2010 and above support using a CUDA toolset provided by a CUDA Toolkit. The toolset version number may be specified by a field in CMAKE_GENERATOR_TOOLSET of the form cuda=8.0. Or it is automatically detected if a path to a standalone CUDA directory is specified in the form cuda=C:\path o