# cmake-variables - Man Page

## Name

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

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

Note that this variable only has limited support on Ninja Multi-Config. It is recommended that you use the $<CONFIG> generator expression instead. 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.

### 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() ### 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. ### 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. ### 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_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. ### 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_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_ranlib New in version 3.9. A wrapper around ranlib adding the appropriate --plugin option for the compiler. See also Cmake_ranlib. ### 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. ### 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 file(DOWNLOAD) and file(UPLOAD) commands and the module ExternalProject. See those commands for additional information. 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 file(DOWNLOAD) and file(UPLOAD) commands and the module ExternalProject. See those commands for additional information. 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")
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)
project(Third VERSION 6.7.8)

And sub/CMakeLists.txt with the following contents:

project(SubProj VERSION 1)

### 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 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 initialise the Swift_MODULE_DIRECTORY property on all the targets.  See the target property for additional information.

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.

### 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:

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.

### 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.

### 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\to\cuda. If none is specified CMake will choose a default version. CMake provides the selected CUDA toolset version in this variable. The value may be empty if no CUDA Toolkit with Visual Studio integration is installed.

### Cmake_vs_platform_toolset_cuda_custom_dir

New in version 3.16.

Path to standalone NVIDIA CUDA Toolkit (eg. extracted from installer).

The Visual Studio Generators for VS 2010 and above support using a standalone (non-installed) NVIDIA CUDA toolkit.  The path may be specified by a field in Cmake_generator_toolset of the form cuda=C:\path\to\cuda.  The given directory must at least contain a folder .\nvcc and must provide Visual Studio integration files in path .\CUDAVisualStudioIntegration\extras\ visual_studio_integration\MSBuildExtensions\. One can create a standalone CUDA toolkit directory by either opening a installer with 7zip or copying the files that are extracted by the running installer. The value may be empty if no path to a standalone CUDA Toolkit was specified.

### Cmake_vs_platform_toolset_host_architecture

New in version 3.8.

Visual Studio preferred tool architecture.

The Visual Studio Generators for VS 2013 and above support using either the 32-bit or 64-bit host toolchains by specifying a host=x86 or host=x64 value in the Cmake_generator_toolset option. CMake provides the selected toolchain architecture preference in this variable (x86, x64, or empty).

### Cmake_vs_platform_toolset_version

New in version 3.12.

Visual Studio Platform Toolset version.

The Visual Studio Generators for VS 2017 and above allow to select minor versions of the same toolset. The toolset version number may be specified by a field in Cmake_generator_toolset of the form version=14.11. If none is specified CMake will choose a default toolset. The value may be empty if no minor version was selected and the default is used.

If the value is not empty, it is the version number that MSBuild uses in its Microsoft.VCToolsVersion.*.props file names.

New in version 3.19.7: VS 16.9's toolset may also be specified as 14.28.16.9 because VS 16.10 uses the file name Microsoft.VCToolsVersion.14.28.16.9.props.

### Three-Component MSVC Toolset Versions

New in version 3.19.7.

The version= field may be given a three-component toolset version such as 14.28.29910, and CMake will convert it to the name used by MSBuild Microsoft.VCToolsVersion.*.props files.  This is useful to distinguish between VS 16.8's 14.28.29333 toolset and VS 16.9's 14.28.29910 toolset.  It also matches vcvarsall's -vcvars_ver= behavior.

### Cmake_vs_windows_target_platform_version

New in version 3.4.

Visual Studio Windows Target Platform Version.

When targeting Windows 10 and above Visual Studio 2015 and above support specification of a target Windows version to select a corresponding SDK. The Cmake_system_version variable may be set to specify a version.  Otherwise CMake computes a default version based on the Windows SDK versions available.  The chosen Windows target version number is provided in CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.  If no Windows 10 SDK is available this value will be empty.

One may set a CMAKE_WINDOWS_KITS_10_DIR environment variable to an absolute path to tell CMake to look for Windows 10 SDKs in a custom location.  The specified directory is expected to contain Include/10.0.* directories.

### Cmake_vs_windows_target_platform_version_maximum

New in version 3.19.

Override the Windows 10 SDK Maximum Version for VS 2015 and beyond.

The CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM variable may be set to a false value (e.g. OFF, FALSE, or 0) or the SDK version to use as the maximum (e.g. 10.0.14393.0).  If unset, the default depends on which version of Visual Studio is targeted by the current generator.

This can be used in conjunction with Cmake_system_version, which CMake uses to select Cmake_vs_windows_target_platform_version.

### Cmake_xcode_build_system

New in version 3.19.

Xcode build system selection.

The Xcode generator defines this variable to indicate which variant of the Xcode build system will be used.  The value is the version of Xcode in which the corresponding build system first became mature enough for use by CMake.  The possible values are:

1

The original Xcode build system. This is the default when using Xcode 11.x or below.

12

The Xcode "new build system" introduced by Xcode 10. It became mature enough for use by CMake in Xcode 12. This is the default when using Xcode 12.x or above.

The CMAKE_XCODE_BUILD_SYSTEM variable is informational and should not be modified by project code.  See the Xcode Build System Selection documentation section to select the Xcode build system.

### Cmake_xcode_platform_toolset

Xcode compiler selection.

Xcode supports selection of a compiler from one of the installed toolsets.  CMake provides the name of the chosen toolset in this variable, if any is explicitly selected (e.g.  via the cmake(1) -T option).

### <Project-Name>_binary_dir

Top level binary directory for the named project.

A variable is created with the name used in the project() command, and is the binary directory for the project.  This can be useful when add_subdirectory() is used to connect several projects.

### <Project-Name>_description

New in version 3.12.

Value given to the DESCRIPTION option of the most recent call to the project() command with project name <PROJECT-NAME>, if any.

### <Project-Name>_homepage_url

New in version 3.12.

Value given to the HOMEPAGE_URL option of the most recent call to the project() command with project name <PROJECT-NAME>, if any.

### <Project-Name>_source_dir

Top level source directory for the named project.

A variable is created with the name used in the project() command, and is the source directory for the project.  This can be useful when add_subdirectory() is used to connect several projects.

### <Project-Name>_version

Value given to the VERSION option of the most recent call to the project() command with project name <PROJECT-NAME>, if any.

### <Project-Name>_version_major

First version number component of the <PROJECT-NAME>_VERSION variable as set by the project() command.

### <Project-Name>_version_minor

Second version number component of the <PROJECT-NAME>_VERSION variable as set by the project() command.

### <Project-Name>_version_patch

Third version number component of the <PROJECT-NAME>_VERSION variable as set by the project() command.

### <Project-Name>_version_tweak

Fourth version number component of the <PROJECT-NAME>_VERSION variable as set by the project() command.

### Project_binary_dir

Full path to build directory for project.

This is the binary directory of the most recent project() command.

### Project_description

New in version 3.9.

Short project description given to the project command.

This is the description given to the most recently called project() command in the current directory scope or above.  To obtain the description of the top level project, see the Cmake_project_description variable.

### Project_homepage_url

New in version 3.12.

The homepage URL of the project.

This is the homepage URL given to the most recently called project() command in the current directory scope or above.  To obtain the homepage URL of the top level project, see the Cmake_project_homepage_url variable.

### Project_name

Name of the project given to the project command.

This is the name given to the most recently called project() command in the current directory scope or above.  To obtain the name of the top level project, see the Cmake_project_name variable.

### Project_source_dir

This is the source directory of the last call to the project() command made in the current directory scope or one of its parents. Note, it is not affected by calls to project() made within a child directory scope (i.e. from within a call to add_subdirectory() from the current scope).

### Project_version

Value given to the VERSION option of the most recent call to the project() command, if any.

### Project_version_major

First version number component of the Project_version variable as set by the project() command.

### Project_version_minor

Second version number component of the Project_version variable as set by the project() command.

### Project_version_patch

Third version number component of the Project_version variable as set by the project() command.

### Project_version_tweak

Fourth version number component of the Project_version variable as set by the project() command.

## Variables That Change Behavior

### Build_shared_libs

Global flag to cause add_library() to create shared libraries if on.

If present and true, this will cause all libraries to be built shared unless the library was explicitly added as a static library.  This variable is often added to projects as an option() so that each user of a project can decide if they want to build the project using shared or static libraries.

### Cmake_absolute_destination_files

List of files which have been installed using an ABSOLUTE DESTINATION path.

This variable is defined by CMake-generated cmake_install.cmake scripts.  It can be used (read-only) by programs or scripts that source those install scripts.  This is used by some CPack generators (e.g.  RPM).

### Cmake_appbundle_path

Semicolon-separated list of directories specifying a search path for macOS application bundles used by the find_program(), and find_package() commands.

### Cmake_automoc_relaxed_mode

Deprecated since version 3.15.

Switch between strict and relaxed automoc mode.

By default, AUTOMOC behaves exactly as described in the documentation of the AUTOMOC target property.  When set to TRUE, it accepts more input and tries to find the correct input file for moc even if it differs from the documented behaviour.  In this mode it e.g.  also checks whether a header file is intended to be processed by moc when a "foo.moc" file has been included.

Relaxed mode has to be enabled for KDE4 compatibility.

### Cmake_backwards_compatibility

Deprecated.  See CMake Policy CMP0001 documentation.

### Cmake_build_type

Specifies the build type on single-configuration generators.

This statically specifies what build type (configuration) will be built in this build tree.  Possible values are empty, Debug, Release, RelWithDebInfo, MinSizeRel, ...  This variable is only meaningful to single-configuration generators (such as Makefile Generators and Ninja) i.e.  those which choose a single configuration when CMake runs to generate a build tree as opposed to multi-configuration generators which offer selection of the build configuration within the generated build environment.  There are many per-config properties and variables (usually following clean SOME_VAR_<CONFIG> order conventions), such as CMAKE_C_FLAGS_<CONFIG>, specified as uppercase: CMAKE_C_FLAGS_[DEBUG|RELEASE|RELWITHDEBINFO|MINSIZEREL|...].  For example, in a build tree configured to build type Debug, CMake will see to having CMAKE_C_FLAGS_DEBUG settings get added to the CMAKE_C_FLAGS settings.  See also Cmake_configuration_types.

Note that configuration names are case-insensitive.  The value of this variable will be the same as it is specified when invoking CMake. For instance, if -DCMAKE_BUILD_TYPE=ReLeAsE is specified, then the value of CMAKE_BUILD_TYPE will be ReLeAsE.

### Cmake_clang_vfs_overlay

New in version 3.19.

When cross compiling for windows with clang-cl, this variable can be an absolute path pointing to a clang virtual file system yaml file, which will enable clang-cl to resolve windows header names on a case sensitive file system.

### Cmake_codeblocks_compiler_id

New in version 3.11.

Change the compiler id in the generated CodeBlocks project files.

CodeBlocks uses its own compiler id string which differs from CMAKE_<LANG>_COMPILER_ID.  If this variable is left empty, CMake tries to recognize the CodeBlocks compiler id automatically. Otherwise the specified string is used in the CodeBlocks project file. See the CodeBlocks documentation for valid compiler id strings.

Other IDEs like QtCreator that also use the CodeBlocks generator may ignore this setting.

### Cmake_codeblocks_exclude_external_files

New in version 3.10.

Change the way the CodeBlocks generator creates project files.

If this variable evaluates to ON the generator excludes from the project file any files that are located outside the project root.

### Cmake_codelite_use_targets

New in version 3.7.

Change the way the CodeLite generator creates projectfiles.

If this variable evaluates to ON at the end of the top-level CMakeLists.txt file, the generator creates projectfiles based on targets rather than projects.

### Cmake_color_makefile

Enables color output when using the Makefile Generators.

When enabled, the generated Makefiles will produce colored output. Default is ON.

### Cmake_configuration_types

Specifies the available build types on multi-config generators.

This specifies what build types (configurations) will be available such as Debug, Release, RelWithDebInfo etc.  This has reasonable defaults on most platforms, but can be extended to provide other build types.  See also Cmake_build_type for details of managing configuration data, and Cmake_cfg_intdir.

### Cmake_depends_in_project_only

New in version 3.6.

When set to TRUE in a directory, the build system produced by the Makefile Generators is set up to only consider dependencies on source files that appear either in the source or in the binary directories.  Changes to source files outside of these directories will not cause rebuilds.

This should be used carefully in cases where some source files are picked up through external headers during the build.

### CMAKE_DISABLE_FIND_PACKAGE_<PackageName>

Variable for disabling find_package() calls.

Every non-REQUIRED find_package() call in a project can be disabled by setting the variable CMAKE_DISABLE_FIND_PACKAGE_<PackageName> to TRUE. This can be used to build a project without an optional package, although that package is installed.

This switch should be used during the initial CMake run.  Otherwise if the package has already been found in a previous CMake run, the variables which have been stored in the cache will still be there.  In that case it is recommended to remove the cache variables for this package from the cache using the cache editor or cmake(1) -U

New in version 3.6.

This cache variable is used by the Eclipse project generator.  See cmake-generators(7).

The Eclipse project generator generates so-called linked resources e.g. to the subproject root dirs in the source tree or to the source files of targets. This can be disabled by setting this variable to FALSE.

### Cmake_eclipse_generate_source_project

New in version 3.6.

This cache variable is used by the Eclipse project generator.  See cmake-generators(7).

If this variable is set to TRUE, the Eclipse project generator will generate an Eclipse project in Cmake_source_dir . This project can then be used in Eclipse e.g. for the version control functionality. CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT defaults to FALSE; so nothing is written into the source directory.

### Cmake_eclipse_make_arguments

New in version 3.6.

This cache variable is used by the Eclipse project generator.  See cmake-generators(7).

This variable holds arguments which are used when Eclipse invokes the make tool. By default it is initialized to hold flags to enable parallel builds (using -j typically).

### Cmake_eclipse_resource_encoding

New in version 3.16.

This cache variable tells the Eclipse CDT4 project generator to set the resource encoding to the given value in generated project files. If no value is given, no encoding will be set.

### Cmake_eclipse_version

New in version 3.6.

This cache variable is used by the Eclipse project generator.  See cmake-generators(7).

When using the Eclipse project generator, CMake tries to find the Eclipse executable and detect the version of it. Depending on the version it finds, some features are enabled or disabled. If CMake doesn't find Eclipse, it assumes the oldest supported version, Eclipse Callisto (3.2).

### Cmake_error_deprecated

Whether to issue errors for deprecated functionality.

If TRUE, use of deprecated functionality will issue fatal errors. If this variable is not set, CMake behaves as if it were set to FALSE.

### Cmake_error_on_absolute_install_destination

Ask cmake_install.cmake script to error out as soon as a file with absolute INSTALL DESTINATION is encountered.

The fatal error is emitted before the installation of the offending file takes place.  This variable is used by CMake-generated cmake_install.cmake scripts.  If one sets this variable to ON while running the script, it may get fatal error messages from the script.

### Cmake_execute_process_command_echo

New in version 3.15.

If this variable is set to STDERR, STDOUT or NONE then commands in execute_process() calls will be printed to either stderr or stdout or not at all.

### Cmake_export_compile_commands

New in version 3.5.

Enable/Disable output of compile commands during generation.

If enabled, generates a compile_commands.json file containing the exact compiler calls for all translation units of the project in machine-readable form.  The format of the JSON file looks like:

[
{
"directory": "/home/user/development/project",
"command": "/usr/bin/c++ ... -c ../foo/foo.cc",
"file": "../foo/foo.cc"
},

...

{
"directory": "/home/user/development/project",
"command": "/usr/bin/c++ ... -c ../foo/bar.cc",
"file": "../foo/bar.cc"
}
]

This is initialized by the CMAKE_EXPORT_COMPILE_COMMANDS environment variable, and initializes the EXPORT_COMPILE_COMMANDS target property for all targets.

Note:

This option is implemented only by Makefile Generators and the Ninja.  It is ignored on other generators.

This option currently does not work well in combination with the UNITY_BUILD target property or the Cmake_unity_build variable.

### Cmake_export_package_registry

New in version 3.15.

Enables the export(PACKAGE) command when CMP0090 is set to NEW.

The export(PACKAGE) command does nothing by default.  In some cases it is desirable to write to the user package registry, so the CMAKE_EXPORT_PACKAGE_REGISTRY variable may be set to enable it.

If CMP0090 is not set to NEW this variable does nothing, and the Cmake_export_no_package_registry variable controls the behavior instead.

### Cmake_export_no_package_registry

New in version 3.1.

Disable the export(PACKAGE) command when CMP0090 is not set to NEW.

In some cases, for example for packaging and for system wide installations, it is not desirable to write the user package registry. If the CMAKE_EXPORT_NO_PACKAGE_REGISTRY variable is enabled, the export(PACKAGE) command will do nothing.

If CMP0090 is set to NEW this variable does nothing, and the Cmake_export_package_registry variable controls the behavior instead.

### Cmake_find_appbundle

New in version 3.4.

This variable affects how find_* commands choose between macOS Application Bundles and unix-style package components.

On Darwin or systems supporting macOS Application Bundles, the CMAKE_FIND_APPBUNDLE variable can be set to empty or one of the following:

FIRST

Try to find application bundles before standard programs. This is the default on Darwin.

LAST

Try to find application bundles after standard programs.

ONLY

Only try to find application bundles.

NEVER

Never try to find application bundles.

### Cmake_find_framework

New in version 3.4.

This variable affects how find_* commands choose between macOS Frameworks and unix-style package components.

On Darwin or systems supporting macOS Frameworks, the CMAKE_FIND_FRAMEWORK variable can be set to empty or one of the following:

FIRST

Try to find frameworks before standard libraries or headers. This is the default on Darwin.

LAST

Try to find frameworks after standard libraries or headers.

ONLY

Only try to find frameworks.

NEVER

Never try to find frameworks.

### Cmake_find_library_custom_lib_suffix

New in version 3.9.

Specify a <suffix> to tell the find_library() command to search in a lib<suffix> directory before each lib directory that would normally be searched.

This overrides the behavior of related global properties:

• FIND_LIBRARY_USE_LIB32_PATHS
• FIND_LIBRARY_USE_LIB64_PATHS
• FIND_LIBRARY_USE_LIBX32_PATHS

### Cmake_find_library_prefixes

Prefixes to prepend when looking for libraries.

This specifies what prefixes to add to library names when the find_library() command looks for libraries.  On Unix systems this is typically lib, meaning that when trying to find the foo library it will look for libfoo.

### Cmake_find_library_suffixes

Suffixes to append when looking for libraries.

This specifies what suffixes to add to library names when the find_library() command looks for libraries.  On Windows systems this is typically .lib and .dll, meaning that when trying to find the foo library it will look for foo.dll etc.

### Cmake_find_no_install_prefix

Exclude the values of the Cmake_install_prefix and Cmake_staging_prefix variables from Cmake_system_prefix_path.  CMake adds these project-destination prefixes to Cmake_system_prefix_path by default in order to support building a series of dependent packages and installing them into a common prefix.  Set CMAKE_FIND_NO_INSTALL_PREFIX to TRUE to suppress this behavior.

The Cmake_system_prefix_path is initialized on the first call to a project() or enable_language() command.  Therefore one must set CMAKE_FIND_NO_INSTALL_PREFIX before this in order to take effect.  A user may set the variable as a cache entry on the command line to achieve this.

Note that the prefix(es) may still be searched for other reasons, such as being the same prefix as the CMake installation, or for being a built-in system prefix.

### Cmake_find_package_no_package_registry

New in version 3.1.

Deprecated since version 3.16: Use the Cmake_find_use_package_registry variable instead.

By default this variable is not set. If neither Cmake_find_use_package_registry nor CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY is set, then find_package() will use the User Package Registry unless the NO_CMAKE_PACKAGE_REGISTRY option is provided.

CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY is ignored if Cmake_find_use_package_registry is set.

In some cases, for example to locate only system wide installations, it is not desirable to use the User Package Registry when searching for packages. If the CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY variable is TRUE, all the find_package() commands will skip the User Package Registry as if they were called with the NO_CMAKE_PACKAGE_REGISTRY argument.

### Cmake_find_package_no_system_package_registry

New in version 3.1.

Deprecated since version 3.16: Use the Cmake_find_use_system_package_registry variable instead.

By default this variable is not set. If neither Cmake_find_use_system_package_registry nor CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY is set, then find_package() will use the System Package Registry unless the NO_CMAKE_SYSTEM_PACKAGE_REGISTRY option is provided.

CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY is ignored if Cmake_find_use_system_package_registry is set.

In some cases, it is not desirable to use the System Package Registry when searching for packages. If the CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY variable is TRUE, all the find_package() commands will skip the System Package Registry as if they were called with the NO_CMAKE_SYSTEM_PACKAGE_REGISTRY argument.

### Cmake_find_package_prefer_config

New in version 3.15.

Tell find_package() to try "Config" mode before "Module" mode if no mode was specified.

The command find_package() operates without an explicit mode when the reduced signature is used without the MODULE option. In this case, by default, CMake first tries Module mode by searching for a Find<pkg>.cmake module.  If it fails, CMake then searches for the package using Config mode.

Set CMAKE_FIND_PACKAGE_PREFER_CONFIG to TRUE to tell find_package() to first search using Config mode before falling back to Module mode.

This variable may be useful when a developer has compiled a custom version of a common library and wishes to link it to a dependent project.  If this variable is set to TRUE, it would prevent a dependent project's call to find_package() from selecting the default library located by the system's Find<pkg>.cmake module before finding the developer's custom built library.

Once this variable is set, it is the responsibility of the exported <pkg>Config.cmake files to provide the same result variables as the Find<pkg>.cmake modules so that dependent projects can use them interchangeably.

### Cmake_find_package_warn_no_module

Tell find_package() to warn if called without an explicit mode.

If find_package() is called without an explicit mode option (MODULE, CONFIG, or NO_MODULE) and no Find<pkg>.cmake module is in Cmake_module_path then CMake implicitly assumes that the caller intends to search for a package configuration file.  If no package configuration file is found then the wording of the failure message must account for both the case that the package is really missing and the case that the project has a bug and failed to provide the intended Find module.  If instead the caller specifies an explicit mode option then the failure message can be more specific.

Set CMAKE_FIND_PACKAGE_WARN_NO_MODULE to TRUE to tell find_package() to warn when it implicitly assumes Config mode.  This helps developers enforce use of an explicit mode in all calls to find_package() within a project.

This variable has no effect if Cmake_find_package_prefer_config is set to TRUE.

### Cmake_find_root_path

Semicolon-separated list of root paths to search on the filesystem.

This variable is most useful when cross-compiling. CMake uses the paths in this list as alternative roots to find filesystem items with find_package(), find_library() etc.

### Cmake_find_root_path_mode_include

This variable controls whether the Cmake_find_root_path and Cmake_sysroot are used by find_file() and find_path().

If set to ONLY, then only the roots in Cmake_find_root_path will be searched. If set to NEVER, then the roots in Cmake_find_root_path will be ignored and only the host system root will be used. If set to BOTH, then the host system paths and the paths in Cmake_find_root_path will be searched.

### Cmake_find_root_path_mode_library

This variable controls whether the Cmake_find_root_path and Cmake_sysroot are used by find_library().

If set to ONLY, then only the roots in Cmake_find_root_path will be searched. If set to NEVER, then the roots in Cmake_find_root_path will be ignored and only the host system root will be used. If set to BOTH, then the host system paths and the paths in Cmake_find_root_path will be searched.

### Cmake_find_root_path_mode_package

This variable controls whether the Cmake_find_root_path and Cmake_sysroot are used by find_package().

If set to ONLY, then only the roots in Cmake_find_root_path will be searched. If set to NEVER, then the roots in Cmake_find_root_path will be ignored and only the host system root will be used. If set to BOTH, then the host system paths and the paths in Cmake_find_root_path will be searched.

### Cmake_find_root_path_mode_program

This variable controls whether the Cmake_find_root_path and Cmake_sysroot are used by find_program().

If set to ONLY, then only the roots in Cmake_find_root_path will be searched. If set to NEVER, then the roots in Cmake_find_root_path will be ignored and only the host system root will be used. If set to BOTH, then the host system paths and the paths in Cmake_find_root_path will be searched.

### Cmake_find_use_cmake_environment_path

New in version 3.16.

Controls the default behavior of the following commands for whether or not to search paths provided by cmake-specific environment variables:

• find_program()
• find_library()
• find_file()
• find_path()
• find_package()

This is useful in cross-compiling environments.

By default this variable is not set, which is equivalent to it having a value of TRUE.  Explicit options given to the above commands take precedence over this variable.

### Cmake_find_use_cmake_path

New in version 3.16.

Controls the default behavior of the following commands for whether or not to search paths provided by cmake-specific cache variables:

• find_program()
• find_library()
• find_file()
• find_path()
• find_package()

This is useful in cross-compiling environments.

By default this variable is not set, which is equivalent to it having a value of TRUE.  Explicit options given to the above commands take precedence over this variable.

### Cmake_find_use_cmake_system_path

New in version 3.16.

Controls the default behavior of the following commands for whether or not to search paths provided by platform-specific cmake variables:

• find_program()
• find_library()
• find_file()
• find_path()
• find_package()

This is useful in cross-compiling environments.

By default this variable is not set, which is equivalent to it having a value of TRUE.  Explicit options given to the above commands take precedence over this variable.

### Cmake_find_use_package_registry

New in version 3.16.

Controls the default behavior of the find_package() command for whether or not to search paths provided by the User Package Registry.

By default this variable is not set and the behavior will fall back to that determined by the deprecated Cmake_find_package_no_package_registry variable.  If that is also not set, then find_package() will use the User Package Registry unless the NO_CMAKE_PACKAGE_REGISTRY option is provided.

This variable takes precedence over Cmake_find_package_no_package_registry when both are set.

In some cases, for example to locate only system wide installations, it is not desirable to use the User Package Registry when searching for packages.  If the CMAKE_FIND_USE_PACKAGE_REGISTRY variable is FALSE, all the find_package() commands will skip the User Package Registry as if they were called with the NO_CMAKE_PACKAGE_REGISTRY argument.

See also Disabling the Package Registry and the Cmake_find_use_cmake_path, Cmake_find_use_cmake_environment_path, Cmake_find_use_cmake_system_path, Cmake_find_use_system_environment_path, Cmake_find_use_system_package_registry, and Cmake_find_use_package_root_path variables.

### Cmake_find_use_package_root_path

New in version 3.16.

Controls the default behavior of the following commands for whether or not to search paths provided by <PackageName>_ROOT variables:

• find_program()
• find_library()
• find_file()
• find_path()
• find_package()

By default this variable is not set, which is equivalent to it having a value of TRUE.  Explicit options given to the above commands take precedence over this variable.

### Cmake_find_use_system_environment_path

New in version 3.16.

Controls the default behavior of the following commands for whether or not to search paths provided by standard system environment variables:

• find_program()
• find_library()
• find_file()
• find_path()
• find_package()

This is useful in cross-compiling environments.

By default this variable is not set, which is equivalent to it having a value of TRUE.  Explicit options given to the above commands take precedence over this variable.

### Cmake_find_use_system_package_registry

New in version 3.16.

Controls searching the System Package Registry by the find_package() command.

By default this variable is not set and the behavior will fall back to that determined by the deprecated Cmake_find_package_no_system_package_registry variable. If that is also not set, then find_package() will use the System Package Registry unless the NO_CMAKE_SYSTEM_PACKAGE_REGISTRY option is provided.

This variable takes precedence over Cmake_find_package_no_system_package_registry when both are set.

In some cases, for example to locate only user specific installations, it is not desirable to use the System Package Registry when searching for packages. If the CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY variable is FALSE, all the find_package() commands will skip the System Package Registry as if they were called with the NO_CMAKE_SYSTEM_PACKAGE_REGISTRY argument.

### Cmake_framework_path

Semicolon-separated list of directories specifying a search path for macOS frameworks used by the find_library(), find_package(), find_path(), and find_file() commands.

### Cmake_ignore_path

Semicolon-separated list of directories to be ignored by the find_program(), find_library(), find_file(), and find_path() commands.  This is useful in cross-compiling environments where some system directories contain incompatible but possibly linkable libraries.  For example, on cross-compiled cluster environments, this allows a user to ignore directories containing libraries meant for the front-end machine.

By default this is empty; it is intended to be set by the project. Note that CMAKE_IGNORE_PATH takes a list of directory names, not a list of prefixes.  To ignore paths under prefixes (bin, include, lib, etc.), specify them explicitly.

### Cmake_include_directories_before

Whether to append or prepend directories by default in include_directories().

This variable affects the default behavior of the include_directories() command.  Setting this variable to ON is equivalent to using the BEFORE option in all uses of that command.

### Cmake_include_directories_project_before

Whether to force prepending of project include directories.

This variable affects the order of include directories generated in compiler command lines.  If set to ON, it causes the Cmake_source_dir and the Cmake_binary_dir to appear first.

### Cmake_include_path

Semicolon-separated list of directories specifying a search path for the find_file() and find_path() commands.  By default it is empty, it is intended to be set by the project.  See also Cmake_system_include_path and Cmake_prefix_path.

### Cmake_install_default_component_name

Default component used in install() commands.

If an install() command is used without the COMPONENT argument, these files will be grouped into a default component.  The name of this default install component will be taken from this variable.  It defaults to Unspecified.

### Cmake_install_default_directory_permissions

New in version 3.11.

Default permissions for directories created implicitly during installation of files by install() and file(INSTALL).

If make install is invoked and directories are implicitly created they get permissions set by CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS variable or platform specific default permissions if the variable is not set.

Implicitly created directories are created if they are not explicitly installed by install() command but are needed to install a file on a certain path. Example of such locations are directories created due to the setting of Cmake_install_prefix.

Expected content of the CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS variable is a list of permissions that can be used by install() command PERMISSIONS section.

Example usage:

set(CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
OWNER_WRITE
OWNER_EXECUTE
)

### Cmake_install_message

New in version 3.1.

Specify verbosity of installation script code generated by the install() command (using the file(INSTALL) command). For paths that are newly installed or updated, installation may print lines like:

-- Installing: /some/destination/path

For paths that are already up to date, installation may print lines like:

-- Up-to-date: /some/destination/path

The CMAKE_INSTALL_MESSAGE variable may be set to control which messages are printed:

ALWAYS

Print both Installing and Up-to-date messages.

LAZY

Print Installing but not Up-to-date messages.

NEVER

Print neither Installing nor Up-to-date messages.

Other values have undefined behavior and may not be diagnosed.

If this variable is not set, the default behavior is ALWAYS.

### Cmake_install_prefix

Install directory used by install().

If make install is invoked or INSTALL is built, this directory is prepended onto all install directories.  This variable defaults to /usr/local on Unix and c:/Program Files/${Project_name} on Windows. See Cmake_install_prefix_initialized_to_default for how a project might choose its own default. On Unix one can use the DESTDIR mechanism in order to relocate the whole installation. See DESTDIR for more information. The installation prefix is also added to Cmake_system_prefix_path so that find_package(), find_program(), find_library(), find_path(), and find_file() will search the prefix for other software. Note: Use the GNUInstallDirs module to provide GNU-style options for the layout of directories within the installation. ### Cmake_install_prefix_initialized_to_default New in version 3.7.1. CMake sets this variable to a TRUE value when the Cmake_install_prefix has just been initialized to its default value, typically on the first run of CMake within a new build tree. This can be used by project code to change the default without overriding a user-provided value: if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) set(CMAKE_INSTALL_PREFIX "/my/default" CACHE PATH "..." FORCE) endif() ### Cmake_library_path Semicolon-separated list of directories specifying a search path for the find_library() command. By default it is empty, it is intended to be set by the project. See also Cmake_system_library_path and Cmake_prefix_path. ### Cmake_mfc_flag Use the MFC library for an executable or dll. Enables the use of the Microsoft Foundation Classes (MFC). It should be set to 1 for the static MFC library, and 2 for the shared MFC library. This is used in Visual Studio project files. Usage example: add_definitions(-D_AFXDLL) set(CMAKE_MFC_FLAG 2) add_executable(CMakeSetup WIN32${SRCS})

Contents of CMAKE_MFC_FLAG may use generator expressions.

### Cmake_maximum_recursion_depth

New in version 3.14.

Maximum recursion depth for CMake scripts. It is intended to be set on the command line with -DCMAKE_MAXIMUM_RECURSION_DEPTH=<x>, or within CMakeLists.txt by projects that require a large recursion depth. Projects that set this variable should provide the user with a way to override it. For example:

# About to perform deeply recursive actions
if(NOT CMAKE_MAXIMUM_RECURSION_DEPTH)
set(CMAKE_MAXIMUM_RECURSION_DEPTH 2000)
endif()

If it is not set, or is set to a non-integer value, a sensible default limit is used. If the recursion limit is reached, the script terminates immediately with a fatal error.

Calling any of the following commands increases the recursion depth:

• include()
• find_package()
• try_compile()
• ctest_run_script() (unless NEW_PROCESS is specified)
• User-defined function()'s and macro()'s (note that function() and macro() themselves don't increase recursion depth)
• Reading or writing variables that are being watched by a variable_watch()

### Cmake_message_context

New in version 3.17.

When enabled by the cmake --log-context command line option or the Cmake_message_context_show variable, the message() command converts the CMAKE_MESSAGE_CONTEXT list into a dot-separated string surrounded by square brackets and prepends it to each line for messages of log levels NOTICE and below.

For logging contexts to work effectively, projects should generally APPEND and POP_BACK an item to the current value of CMAKE_MESSAGE_CONTEXT rather than replace it. Projects should not assume the message context at the top of the source tree is empty, as there are scenarios where the context might have already been set (e.g. hierarchical projects).

WARNING:

Valid context names are restricted to anything that could be used as a CMake variable name.  All names that begin with an underscore or the string cmake_ are also reserved for use by CMake and should not be used by projects.

Example:

function(bar)
list(APPEND CMAKE_MESSAGE_CONTEXT "bar")
message(VERBOSE "bar VERBOSE message")
endfunction()

function(baz)
list(APPEND CMAKE_MESSAGE_CONTEXT "baz")
message(DEBUG "baz DEBUG message")
endfunction()

function(foo)
list(APPEND CMAKE_MESSAGE_CONTEXT "foo")
bar()
message(TRACE "foo TRACE message")
baz()
endfunction()

list(APPEND CMAKE_MESSAGE_CONTEXT "top")

message(VERBOSE "Before foo")
foo()
message(VERBOSE "After foo")

list(POP_BACK CMAKE_MESSAGE_CONTEXT)

Which results in the following output:

-- [top] Before foo
-- [top.foo.bar] bar VERBOSE message
-- [top.foo] foo TRACE message
-- [top.foo.baz] baz DEBUG message
-- [top] After foo

### Cmake_message_context_show

New in version 3.17.

Setting this variable to true enables showing a context with each line logged by the message() command (see Cmake_message_context for how the context itself is specified).

This variable is an alternative to providing the --log-context option on the cmake command line.  Whereas the command line option will apply only to that one CMake run, setting CMAKE_MESSAGE_CONTEXT_SHOW to true as a cache variable will ensure that subsequent CMake runs will continue to show the message context.

Projects should not set CMAKE_MESSAGE_CONTEXT_SHOW.  It is intended for users so that they may control whether or not to include context with messages.

### Cmake_message_indent

New in version 3.16.

The message() command joins the strings from this list and for log levels of NOTICE and below, it prepends the resultant string to each line of the message.

Example:

list(APPEND listVar one two three)

message(VERBOSE [[Collected items in the "listVar":]])
list(APPEND CMAKE_MESSAGE_INDENT "  ")

foreach(item IN LISTS listVar)

### Executable_output_path

Old executable location variable.

The target property RUNTIME_OUTPUT_DIRECTORY supercedes this variable for a target if it is set.  Executable targets are otherwise placed in this directory.

### Library_output_path

Old library location variable.

The target properties ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and RUNTIME_OUTPUT_DIRECTORY supersede this variable for a target if they are set.  Library targets are otherwise placed in this directory.

## Variables for Languages

### Cmake_compiler_is_gnucc

New in version 3.7.

True if the C compiler is GNU. Use CMAKE_C_COMPILER_ID instead.

### Cmake_compiler_is_gnucxx

New in version 3.7.

True if the C++ (CXX) compiler is GNU. Use CMAKE_CXX_COMPILER_ID instead.

### Cmake_compiler_is_gnug77

New in version 3.7.

True if the Fortran compiler is GNU. Use CMAKE_Fortran_COMPILER_ID instead.

### Cmake_cuda_architectures

New in version 3.18.

Default value for CUDA_ARCHITECTURES property of targets.

Initialized by the CUDAARCHS environment variable if set. Otherwise as follows depending on CMAKE_CUDA_COMPILER_ID:

• For Clang: the oldest architecture that works.
• For NVIDIA: the default architecture chosen by the compiler. See policy CMP0104.

Users are encouraged to override this, as the default varies across compilers and compiler versions.

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

### Examples

cmake_minimum_required(VERSION)

if(NOT DEFINED CMAKE_CUDA_ARCHITECTURES)
set(CMAKE_CUDA_ARCHITECTURES 75)
endif()

project(example LANGUAGES CUDA)

Cmake_cuda_architectures will default to 75 unless overridden by the user.

### Cmake_cuda_compile_features

New in version 3.17.

List of features known to the CUDA compiler

These features are known to be available for use with the CUDA compiler. This list is a subset of the features listed in the CMAKE_CUDA_KNOWN_FEATURES global property.

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_cuda_extensions

New in version 3.8.

Default value for CUDA_EXTENSIONS property of targets.

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

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_cuda_host_compiler

New in version 3.10.

When CMAKE_CUDA_COMPILER_ID is NVIDIA, CMAKE_CUDA_HOST_COMPILER selects the compiler executable to use when compiling host code for CUDA language files. This maps to the nvcc -ccbin option.

The CMAKE_CUDA_HOST_COMPILER variable may be set explicitly before CUDA is first enabled by a project() or enable_language() command. This can be done via -DCMAKE_CUDA_HOST_COMPILER=... on the command line or in a toolchain file.  Or, one may set the CUDAHOSTCXX environment variable to provide a default value.

Once the CUDA language is enabled, the CMAKE_CUDA_HOST_COMPILER variable is read-only and changes to it are undefined behavior.

Note:

Since CMAKE_CUDA_HOST_COMPILER is meaningful only when the CMAKE_CUDA_COMPILER_ID is NVIDIA, it does not make sense to set CMAKE_CUDA_HOST_COMPILER without also setting CMAKE_CUDA_COMPILER to NVCC.

### Cmake_cuda_standard

New in version 3.8.

Default value for CUDA_STANDARD property of targets.

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

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_cuda_standard_required

New in version 3.8.

Default value for CUDA_STANDARD_REQUIRED property of targets.

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

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_cuda_toolkit_include_directories

New in version 3.8.

When the CUDA language has been enabled, this provides a semicolon-separated list of include directories provided by the CUDA Toolkit.  The value may be useful for C++ source files to include CUDA headers.

### Cmake_cxx_compile_features

New in version 3.1.

List of features known to the C++ compiler

These features are known to be available for use with the C++ compiler. This list is a subset of the features listed in the CMAKE_CXX_KNOWN_FEATURES global property.

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_cxx_extensions

New in version 3.1.

Default value for CXX_EXTENSIONS property of targets.

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

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_cxx_standard

New in version 3.1.

Default value for CXX_STANDARD property of targets.

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

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_cxx_standard_required

New in version 3.1.

Default value for CXX_STANDARD_REQUIRED property of targets.

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

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_c_compile_features

New in version 3.1.

List of features known to the C compiler

These features are known to be available for use with the C compiler. This list is a subset of the features listed in the CMAKE_C_KNOWN_FEATURES global property.

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_c_extensions

New in version 3.1.

Default value for C_EXTENSIONS property of targets.

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

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_c_standard

New in version 3.1.

Default value for C_STANDARD property of targets.

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

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### Cmake_c_standard_required

New in version 3.1.

Default value for C_STANDARD_REQUIRED property of targets.

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

See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

### CMAKE_Fortran_MODDIR_DEFAULT

Fortran default module output directory.

Most Fortran compilers write .mod files to the current working directory.  For those that do not, this is set to . and used when the Fortran_MODULE_DIRECTORY target property is not set.

### CMAKE_Fortran_MODDIR_FLAG

Fortran flag for module output directory.

This stores the flag needed to pass the value of the Fortran_MODULE_DIRECTORY target property to the compiler.

### CMAKE_Fortran_MODOUT_FLAG

Fortran flag to enable module output.

Most Fortran compilers write .mod files out by default.  For others, this stores the flag needed to enable module output.

New in version 3.19.

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

New in version 3.19.2.

Output suffix to be used for ISPC generated headers.

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

### Cmake_ispc_instruction_sets

New in version 3.19.

Default value for ISPC_INSTRUCTION_SETS property of targets.

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

### Cmake_<Lang>_android_toolchain_machine

New in version 3.7.1.

When Cross Compiling for Android this variable contains the toolchain binutils machine name (e.g. gcc -dumpmachine).  The binutils typically have a <machine>- prefix on their name.

### Cmake_<Lang>_android_toolchain_prefix

New in version 3.7.

When Cross Compiling for Android this variable contains the absolute path prefixing the toolchain GNU compiler and its binutils.

For example, the path to the linker is:

${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}ld${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}

### Cmake_<Lang>_android_toolchain_suffix

New in version 3.7.

When Cross Compiling for Android this variable contains the host platform suffix of the toolchain GNU compiler and its binutils.

### Cmake_<Lang>_archive_append

Rule variable to append to a static archive.

This is a rule variable that tells CMake how to append to a static archive.  It is used in place of CMAKE_<LANG>_CREATE_STATIC_LIBRARY on some platforms in order to support large object counts.  See also CMAKE_<LANG>_ARCHIVE_CREATE and CMAKE_<LANG>_ARCHIVE_FINISH.

### Cmake_<Lang>_archive_create

Rule variable to create a new static archive.

This is a rule variable that tells CMake how to create a static archive.  It is used in place of CMAKE_<LANG>_CREATE_STATIC_LIBRARY on some platforms in order to support large object counts.  See also CMAKE_<LANG>_ARCHIVE_APPEND and CMAKE_<LANG>_ARCHIVE_FINISH.

### Cmake_<Lang>_archive_finish

Rule variable to finish an existing static archive.

This is a rule variable that tells CMake how to finish a static archive.  It is used in place of CMAKE_<LANG>_CREATE_STATIC_LIBRARY on some platforms in order to support large object counts.  See also CMAKE_<LANG>_ARCHIVE_CREATE and CMAKE_<LANG>_ARCHIVE_APPEND.

### Cmake_<Lang>_byte_order

New in version 3.20.

Byte order of <LANG> compiler target architecture, if known. If defined and not empty, the value is one of:

BIG_ENDIAN

The target architecture is Big Endian.

LITTLE_ENDIAN

The target architecture is Little Endian.

This is defined for languages C, CXX, OBJC, OBJCXX, and CUDA.

If Cmake_osx_architectures specifies multiple architectures, the value of CMAKE_<LANG>_BYTE_ORDER is non-empty only if all architectures share the same byte order.

### Cmake_<Lang>_compiler

The full path to the compiler for LANG.

This is the command that will be used as the <LANG> compiler.  Once set, you can not change this variable.

### Usage

This variable can be set by the user during the first time a build tree is configured.

If a non-full path value is supplied then CMake will resolve the full path of the compiler.

The variable could be set in a user supplied toolchain file or via -D on the command line.

Note:

Options that are required to make the compiler work correctly can be included as items in a list; they can not be changed.

#set within user supplied toolchain file
set(CMAKE_C_COMPILER /full/path/to/qcc --arg1 --arg2)

or

$cmake ... -DCMAKE_C_COMPILER='qcc;--arg1;--arg2' ### Cmake_<Lang>_compiler_external_toolchain The external toolchain for cross-compiling, if supported. Some compiler toolchains do not ship their own auxiliary utilities such as archivers and linkers. The compiler driver may support a command-line argument to specify the location of such tools. CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN may be set to a path to the external toolchain and will be passed to the compiler driver if supported. This variable may only be set in a toolchain file specified by the Cmake_toolchain_file variable. ### Cmake_<Lang>_compiler_id Compiler identification string. A short string unique to the compiler vendor. Possible values include: Absoft = Absoft Fortran (absoft.com) ADSP = Analog VisualDSP++ (analog.com) AppleClang = Apple Clang (apple.com) ARMCC = ARM Compiler (arm.com) ARMClang = ARM Compiler based on Clang (arm.com) Bruce = Bruce C Compiler CCur = Concurrent Fortran (ccur.com) Clang = LLVM Clang (clang.llvm.org) Cray = Cray Compiler (cray.com) Embarcadero, Borland = Embarcadero (embarcadero.com) Flang = Flang LLVM Fortran Compiler G95 = G95 Fortran (g95.org) GNU = GNU Compiler Collection (gcc.gnu.org) GHS = Green Hills Software (www.ghs.com) HP = Hewlett-Packard Compiler (hp.com) IAR = IAR Systems (iar.com) Intel = Intel Compiler (intel.com) IntelLLVM = Intel LLVM-Based Compiler (intel.com) MSVC = Microsoft Visual Studio (microsoft.com) NVHPC = NVIDIA HPC SDK Compiler (nvidia.com) NVIDIA = NVIDIA CUDA Compiler (nvidia.com) OpenWatcom = Open Watcom (openwatcom.org) PGI = The Portland Group (pgroup.com) PathScale = PathScale (pathscale.com) SDCC = Small Device C Compiler (sdcc.sourceforge.net) SunPro = Oracle Solaris Studio (oracle.com) TI = Texas Instruments (ti.com) TinyCC = Tiny C Compiler (tinycc.org) XL, VisualAge, zOS = IBM XL (ibm.com) XLClang = IBM Clang-based XL (ibm.com) This variable is not guaranteed to be defined for all compilers or languages. ### Cmake_<Lang>_compiler_loaded Defined to true if the language is enabled. When language <LANG> is enabled by project() or enable_language() this variable is defined to 1. ### Cmake_<Lang>_compiler_predefines_command New in version 3.10. Command that outputs the compiler pre definitions. See AUTOMOC which uses CMAKE_CXX_COMPILER_PREDEFINES_COMMAND to generate the AUTOMOC_COMPILER_PREDEFINES. ### Cmake_<Lang>_compiler_target The target for cross-compiling, if supported. Some compiler drivers are inherently cross-compilers, such as clang and QNX qcc. These compiler drivers support a command-line argument to specify the target to cross-compile for. This variable may only be set in a toolchain file specified by the Cmake_toolchain_file variable. ### Cmake_<Lang>_compiler_version Compiler version string. Compiler version in major[.minor[.patch[.tweak]]] format. This variable is not guaranteed to be defined for all compilers or languages. For example CMAKE_C_COMPILER_VERSION and CMAKE_CXX_COMPILER_VERSION might indicate the respective C and C++ compiler version. ### Cmake_<Lang>_compile_object Rule variable to compile a single object file. This is a rule variable that tells CMake how to compile a single object file for the language <LANG>. ### Cmake_<Lang>_create_shared_library Rule variable to create a shared library. This is a rule variable that tells CMake how to create a shared library for the language <LANG>. This rule variable is a ; delimited list of commands to run to perform the linking step. ### Cmake_<Lang>_create_shared_module Rule variable to create a shared module. This is a rule variable that tells CMake how to create a shared library for the language <LANG>. This rule variable is a ; delimited list of commands to run. ### Cmake_<Lang>_create_static_library Rule variable to create a static library. This is a rule variable that tells CMake how to create a static library for the language <LANG>. ### Cmake_<Lang>_flags Flags for all build types. <LANG> flags used regardless of the value of Cmake_build_type. This is initialized for each language from environment variables: • CMAKE_C_FLAGS: Initialized by the CFLAGS environment variable. • CMAKE_CXX_FLAGS: Initialized by the CXXFLAGS environment variable. • CMAKE_CUDA_FLAGS: Initialized by the CUDAFLAGS environment variable. • CMAKE_Fortran_FLAGS: Initialized by the FFLAGS environment variable. ### Cmake_<Lang>_flags_<Config> New in version 3.11. Flags for language <LANG> when building for the <CONFIG> configuration. ### Cmake_<Lang>_flags_<Config>_init New in version 3.11. Value used to initialize the CMAKE_<LANG>_FLAGS_<CONFIG> cache entry the first time a build tree is configured for language <LANG>. This variable is meant to be set by a toolchain file. CMake may prepend or append content to the value based on the environment and target platform. See also CMAKE_<LANG>_FLAGS_INIT. ### Cmake_<Lang>_flags_debug This variable is the Debug variant of the CMAKE_<LANG>_FLAGS_<CONFIG> variable. ### Cmake_<Lang>_flags_debug_init New in version 3.7. This variable is the Debug variant of the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable. ### Cmake_<Lang>_flags_init New in version 3.7. Value used to initialize the CMAKE_<LANG>_FLAGS cache entry the first time a build tree is configured for language <LANG>. This variable is meant to be set by a toolchain file. CMake may prepend or append content to the value based on the environment and target platform. For example, the contents of a xxxFLAGS environment variable will be prepended, where xxx will be language-specific but not necessarily the same as <LANG> (e.g. CXXFLAGS for CXX, FFLAGS for Fortran, and so on). See also the configuration-specific CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable. ### Cmake_<Lang>_flags_minsizerel This variable is the MinSizeRel variant of the CMAKE_<LANG>_FLAGS_<CONFIG> variable. ### Cmake_<Lang>_flags_minsizerel_init New in version 3.7. This variable is the MinSizeRel variant of the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable. ### Cmake_<Lang>_flags_release This variable is the Release variant of the CMAKE_<LANG>_FLAGS_<CONFIG> variable. ### Cmake_<Lang>_flags_release_init New in version 3.7. This variable is the Release variant of the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable. ### Cmake_<Lang>_flags_relwithdebinfo This variable is the RelWithDebInfo variant of the CMAKE_<LANG>_FLAGS_<CONFIG> variable. ### Cmake_<Lang>_flags_relwithdebinfo_init New in version 3.7. This variable is the RelWithDebInfo variant of the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable. ### Cmake_<Lang>_ignore_extensions File extensions that should be ignored by the build. This is a list of file extensions that may be part of a project for a given language but are not compiled. ### Cmake_<Lang>_implicit_include_directories Directories implicitly searched by the compiler for header files. CMake does not explicitly specify these directories on compiler command lines for language <LANG>. This prevents system include directories from being treated as user include directories on some compilers, which is important for C, CXX, and CUDA to avoid overriding standard library headers. This value is not used for Fortran because it has no standard library headers and some compilers do not search their implicit include directories for module .mod files. ### Cmake_<Lang>_library_architecture Target architecture library directory name detected for <LANG>. If the <LANG> compiler passes to the linker an architecture-specific system library search directory such as <prefix>/lib/<arch> this variable contains the <arch> name if/as detected by CMake. ### Cmake_<Lang>_linker_preference Preference value for linker language selection. The "linker language" for executable, shared library, and module targets is the language whose compiler will invoke the linker. The LINKER_LANGUAGE target property sets the language explicitly. Otherwise, the linker language is that whose linker preference value is highest among languages compiled and linked into the target. See also the CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES variable. ### Cmake_<Lang>_linker_preference_propagates True if CMAKE_<LANG>_LINKER_PREFERENCE propagates across targets. This is used when CMake selects a linker language for a target. Languages compiled directly into the target are always considered. A language compiled into static libraries linked by the target is considered if this variable is true. ### Cmake_<Lang>_linker_wrapper_flag New in version 3.13. Defines the syntax of compiler driver option to pass options to the linker tool. It will be used to translate the LINKER: prefix in the link options (see add_link_options() and target_link_options()). This variable holds a semicolon-separated list of tokens. If a space (i.e. " ") is specified as last token, flag and LINKER: arguments will be specified as separate arguments to the compiler driver. The CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP variable can be specified to manage concatenation of arguments. For example, for Clang we have: set (CMAKE_C_LINKER_WRAPPER_FLAG "-Xlinker" " ") Specifying "LINKER:-z,defs" will be transformed in -Xlinker -z -Xlinker defs. For GNU GCC: set (CMAKE_C_LINKER_WRAPPER_FLAG "-Wl,") set (CMAKE_C_LINKER_WRAPPER_FLAG_SEP ",") Specifying "LINKER:-z,defs" will be transformed in -Wl,-z,defs. And for SunPro: set (CMAKE_C_LINKER_WRAPPER_FLAG "-Qoption" "ld" " ") set (CMAKE_C_LINKER_WRAPPER_FLAG_SEP ",") Specifying "LINKER:-z,defs" will be transformed in -Qoption ld -z,defs. ### Cmake_<Lang>_linker_wrapper_flag_sep New in version 3.13. This variable is used with CMAKE_<LANG>_LINKER_WRAPPER_FLAG variable to format LINKER: prefix in the link options (see add_link_options() and target_link_options()). When specified, arguments of the LINKER: prefix will be concatenated using this value as separator. ### Cmake_<Lang>_output_extension Extension for the output of a compile for a single file. This is the extension for an object file for the given <LANG>. For example .obj for C on Windows. ### Cmake_<Lang>_simulate_id Identification string of "simulated" compiler. Some compilers simulate other compilers to serve as drop-in replacements. When CMake detects such a compiler it sets this variable to what would have been the CMAKE_<LANG>_COMPILER_ID for the simulated compiler. ### Cmake_<Lang>_simulate_version Version string of "simulated" compiler. Some compilers simulate other compilers to serve as drop-in replacements. When CMake detects such a compiler it sets this variable to what would have been the CMAKE_<LANG>_COMPILER_VERSION for the simulated compiler. ### Cmake_<Lang>_sizeof_data_ptr Size of pointer-to-data types for language <LANG>. This holds the size (in bytes) of pointer-to-data types in the target platform ABI. It is defined for languages C and CXX (C++). ### Cmake_<Lang>_source_file_extensions Extensions of source files for the given language. This is the list of extensions for a given language's source files. ### Cmake_<Lang>_standard_include_directories New in version 3.6. Include directories to be used for every source file compiled with the <LANG> compiler. This is meant for specification of system include directories needed by the language for the current platform. The directories always appear at the end of the include path passed to the compiler. This variable should not be set by project code. It is meant to be set by CMake's platform information modules for the current toolchain, or by a toolchain file when used with Cmake_toolchain_file. See also CMAKE_<LANG>_STANDARD_LIBRARIES. ### Cmake_<Lang>_standard_libraries New in version 3.6. Libraries linked into every executable and shared library linked for language <LANG>. This is meant for specification of system libraries needed by the language for the current platform. This variable should not be set by project code. It is meant to be set by CMake's platform information modules for the current toolchain, or by a toolchain file when used with Cmake_toolchain_file. See also CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES. ### Cmake_objc_extensions New in version 3.16. Default value for OBJC_EXTENSIONS property of targets. This variable is used to initialize the OBJC_EXTENSIONS property on all targets. See that target property for additional information. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers. ### Cmake_objc_standard New in version 3.16. Default value for OBJC_STANDARD property of targets. This variable is used to initialize the OBJC_STANDARD property on all targets. See that target property for additional information. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers. ### Cmake_objc_standard_required New in version 3.16. Default value for OBJC_STANDARD_REQUIRED property of targets. This variable is used to initialize the OBJC_STANDARD_REQUIRED property on all targets. See that target property for additional information. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers. ### Cmake_objcxx_extensions New in version 3.16. Default value for OBJCXX_EXTENSIONS property of targets. This variable is used to initialize the OBJCXX_EXTENSIONS property on all targets. See that target property for additional information. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers. ### Cmake_objcxx_standard New in version 3.16. Default value for OBJCXX_STANDARD property of targets. This variable is used to initialize the OBJCXX_STANDARD property on all targets. See that target property for additional information. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers. ### Cmake_objcxx_standard_required New in version 3.16. Default value for OBJCXX_STANDARD_REQUIRED property of targets. This variable is used to initialize the OBJCXX_STANDARD_REQUIRED property on all targets. See that target property for additional information. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers. ### CMAKE_Swift_LANGUAGE_VERSION New in version 3.7. Set to the Swift language version number. If not set, the oldest legacy version known to be available in the host Xcode version is assumed: • Swift 4.0 for Xcode 10.2 and above. • Swift 3.0 for Xcode 8.3 and above. • Swift 2.3 for Xcode 8.2 and below. ### Cmake_user_make_rules_override_<Lang> Specify a CMake file that overrides platform information for <LANG>. This is a language-specific version of Cmake_user_make_rules_override loaded only when enabling language <LANG>. ## Variables for Ctest ### Ctest_binary_directory New in version 3.1. Specify the CTest BuildDirectory setting in a ctest(1) dashboard client script. ### Ctest_build_command New in version 3.1. Specify the CTest MakeCommand setting in a ctest(1) dashboard client script. ### Ctest_build_name New in version 3.1. Specify the CTest BuildName setting in a ctest(1) dashboard client script. ### Ctest_bzr_command New in version 3.1. Specify the CTest BZRCommand setting in a ctest(1) dashboard client script. ### Ctest_bzr_update_options New in version 3.1. Specify the CTest BZRUpdateOptions setting in a ctest(1) dashboard client script. ### Ctest_change_id New in version 3.4. Specify the CTest ChangeId setting in a ctest(1) dashboard client script. This setting allows CTest to pass arbitrary information about this build up to CDash. One use of this feature is to allow CDash to post comments on your pull request if anything goes wrong with your build. ### Ctest_checkout_command New in version 3.1. Tell the ctest_start() command how to checkout or initialize the source directory in a ctest(1) dashboard client script. ### Ctest_configuration_type New in version 3.1. Specify the CTest DefaultCTestConfigurationType setting in a ctest(1) dashboard client script. If the configuration type is set via -C <cfg> from the command line then this variable is populated accordingly. ### Ctest_configure_command New in version 3.1. Specify the CTest ConfigureCommand setting in a ctest(1) dashboard client script. ### Ctest_coverage_command New in version 3.1. Specify the CTest CoverageCommand setting in a ctest(1) dashboard client script. ### Cobertura Using Cobertura as the coverage generation within your multi-module Java project can generate a series of XML files. The Cobertura Coverage parser expects to read the coverage data from a single XML file which contains the coverage data for all modules. Cobertura has a program with the ability to merge given cobertura.ser files and then another program to generate a combined XML file from the previous merged file. For command line testing, this can be done by hand prior to CTest looking for the coverage files. For script builds, set the Ctest_coverage_command variable to point to a file which will perform these same steps, such as a .sh or .bat file. set(CTEST_COVERAGE_COMMAND .../run-coverage-and-consolidate.sh) where the run-coverage-and-consolidate.sh script is perhaps created by the configure_file() command and might contain the following code: #!/usr/bin/env bash CoberturaFiles="$(find "/path/to/source" -name "cobertura.ser")"
SourceDirs="$(find "/path/to/source" -name "java" -type d)" cobertura-merge --datafile coberturamerge.ser$CoberturaFiles
cobertura-report --datafile coberturamerge.ser --destination . \
--format xml $SourceDirs The script uses find to capture the paths to all of the cobertura.ser files found below the project's source directory. It keeps the list of files and supplies it as an argument to the cobertura-merge program. The --datafile argument signifies where the result of the merge will be kept. The combined coberturamerge.ser file is then used to generate the XML report using the cobertura-report program. The call to the cobertura-report program requires some named arguments. --datafila path to the merged .ser file --destination path to put the output files(s) --format file format to write output in: xml or html The rest of the supplied arguments consist of the full paths to the /src/main/java directories of each module within the source tree. These directories are needed and should not be forgotten. ### Ctest_coverage_extra_flags New in version 3.1. Specify the CTest CoverageExtraFlags setting in a ctest(1) dashboard client script. ### Ctest_curl_options New in version 3.1. Specify the CTest CurlOptions setting in a ctest(1) dashboard client script. ### Ctest_custom_coverage_exclude A list of regular expressions which will be used to exclude files by their path from coverage output by the ctest_coverage() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_error_exception A list of regular expressions which will be used to exclude when detecting error messages in build outputs by the ctest_test() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_error_match A list of regular expressions which will be used to detect error messages in build outputs by the ctest_test() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_error_post_context The number of lines to include as context which follow an error message by the ctest_test() command. The default is 10. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_error_pre_context The number of lines to include as context which precede an error message by the ctest_test() command. The default is 10. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_maximum_failed_test_output_size When saving a failing test's output, this is the maximum size, in bytes, that will be collected by the ctest_test() command. Defaults to 307200 (300 KiB). It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_maximum_number_of_errors The maximum number of errors in a single build step which will be detected. After this, the ctest_test() command will truncate the output. Defaults to 50. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_maximum_number_of_warnings The maximum number of warnings in a single build step which will be detected. After this, the ctest_test() command will truncate the output. Defaults to 50. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_maximum_passed_test_output_size When saving a passing test's output, this is the maximum size, in bytes, that will be collected by the ctest_test() command. Defaults to 1024 (1 KiB). It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_memcheck_ignore A list of regular expressions to use to exclude tests during the ctest_memcheck() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_post_memcheck A list of commands to run at the end of the ctest_memcheck() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_post_test A list of commands to run at the end of the ctest_test() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_pre_memcheck A list of commands to run at the start of the ctest_memcheck() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_pre_test A list of commands to run at the start of the ctest_test() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_tests_ignore A list of regular expressions to use to exclude tests during the ctest_test() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_warning_exception A list of regular expressions which will be used to exclude when detecting warning messages in build outputs by the ctest_build() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_custom_warning_match A list of regular expressions which will be used to detect warning messages in build outputs by the ctest_build() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_cvs_checkout New in version 3.1. Deprecated. Use Ctest_checkout_command instead. ### Ctest_cvs_command New in version 3.1. Specify the CTest CVSCommand setting in a ctest(1) dashboard client script. ### Ctest_cvs_update_options New in version 3.1. Specify the CTest CVSUpdateOptions setting in a ctest(1) dashboard client script. ### Ctest_drop_location New in version 3.1. Specify the CTest DropLocation setting in a ctest(1) dashboard client script. ### Ctest_drop_method New in version 3.1. Specify the CTest DropMethod setting in a ctest(1) dashboard client script. ### Ctest_drop_site New in version 3.1. Specify the CTest DropSite setting in a ctest(1) dashboard client script. ### Ctest_drop_site_cdash New in version 3.1. Specify the CTest IsCDash setting in a ctest(1) dashboard client script. ### Ctest_drop_site_password New in version 3.1. Specify the CTest DropSitePassword setting in a ctest(1) dashboard client script. ### Ctest_drop_site_user New in version 3.1. Specify the CTest DropSiteUser setting in a ctest(1) dashboard client script. ### Ctest_extra_coverage_glob New in version 3.4. A list of regular expressions which will be used to find files which should be covered by the ctest_coverage() command. It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation. ### Ctest_git_command New in version 3.1. Specify the CTest GITCommand setting in a ctest(1) dashboard client script. ### Ctest_git_init_submodules New in version 3.6. Specify the CTest GITInitSubmodules setting in a ctest(1) dashboard client script. ### Ctest_git_update_custom New in version 3.1. Specify the CTest GITUpdateCustom setting in a ctest(1) dashboard client script. ### Ctest_git_update_options New in version 3.1. Specify the CTest GITUpdateOptions setting in a ctest(1) dashboard client script. ### Ctest_hg_command New in version 3.1. Specify the CTest HGCommand setting in a ctest(1) dashboard client script. ### Ctest_hg_update_options New in version 3.1. Specify the CTest HGUpdateOptions setting in a ctest(1) dashboard client script. ### Ctest_labels_for_subprojects New in version 3.10. Specify the CTest LabelsForSubprojects setting in a ctest(1) dashboard client script. ### Ctest_memorycheck_command New in version 3.1. Specify the CTest MemoryCheckCommand setting in a ctest(1) dashboard client script. ### Ctest_memorycheck_command_options New in version 3.1. Specify the CTest MemoryCheckCommandOptions setting in a ctest(1) dashboard client script. ### Ctest_memorycheck_sanitizer_options New in version 3.1. Specify the CTest MemoryCheckSanitizerOptions setting in a ctest(1) dashboard client script. CTest prepends correct sanitizer options *_OPTIONS environment variable to executed command. CTests adds its own log_path to sanitizer options, don't provide your own log_path. ### Ctest_memorycheck_suppressions_file New in version 3.1. Specify the CTest MemoryCheckSuppressionFile setting in a ctest(1) dashboard client script. ### Ctest_memorycheck_type New in version 3.1. Specify the CTest MemoryCheckType setting in a ctest(1) dashboard client script. Valid values are Valgrind, Purify, BoundsChecker, DrMemory, CudaSanitizer, ThreadSanitizer, AddressSanitizer, LeakSanitizer, MemorySanitizer and UndefinedBehaviorSanitizer. ### Ctest_nightly_start_time New in version 3.1. Specify the CTest NightlyStartTime setting in a ctest(1) dashboard client script. Note that this variable must always be set for a nightly build in a dashboard script. It is needed so that nightly builds can be properly grouped together in CDash. ### Ctest_p4_client New in version 3.1. Specify the CTest P4Client setting in a ctest(1) dashboard client script. ### Ctest_p4_command New in version 3.1. Specify the CTest P4Command setting in a ctest(1) dashboard client script. ### Ctest_p4_options New in version 3.1. Specify the CTest P4Options setting in a ctest(1) dashboard client script. ### Ctest_p4_update_options New in version 3.1. Specify the CTest P4UpdateOptions setting in a ctest(1) dashboard client script. ### Ctest_resource_spec_file New in version 3.18. Specify the CTest ResourceSpecFile setting in a ctest(1) dashboard client script. This can also be used to specify the resource spec file from a CMake build. If no RESOURCE_SPEC_FILE is passed to ctest_test(), and CTEST_RESOURCE_SPEC_FILE is not specified in the dashboard script, the value of this variable from the build is used. ### Ctest_run_current_script New in version 3.11. Setting this to 0 prevents ctest(1) from being run again when it reaches the end of a script run by calling ctest -S. ### Ctest_scp_command New in version 3.1. Legacy option. Not used. ### Ctest_site New in version 3.1. Specify the CTest Site setting in a ctest(1) dashboard client script. ### Ctest_submit_url New in version 3.14. Specify the CTest SubmitURL setting in a ctest(1) dashboard client script. ### Ctest_source_directory New in version 3.1. Specify the CTest SourceDirectory setting in a ctest(1) dashboard client script. ### Ctest_svn_command New in version 3.1. Specify the CTest SVNCommand setting in a ctest(1) dashboard client script. ### Ctest_svn_options New in version 3.1. Specify the CTest SVNOptions setting in a ctest(1) dashboard client script. ### Ctest_svn_update_options New in version 3.1. Specify the CTest SVNUpdateOptions setting in a ctest(1) dashboard client script. ### Ctest_test_load New in version 3.4. Specify the TestLoad setting in the CTest Test Step of a ctest(1) dashboard client script. This sets the default value for the TEST_LOAD option of the ctest_test() command. ### Ctest_test_timeout New in version 3.1. Specify the CTest TimeOut setting in a ctest(1) dashboard client script. ### Ctest_trigger_site New in version 3.1. Legacy option. Not used. ### Ctest_update_command New in version 3.1. Specify the CTest UpdateCommand setting in a ctest(1) dashboard client script. ### Ctest_update_options New in version 3.1. Specify the CTest UpdateOptions setting in a ctest(1) dashboard client script. ### Ctest_update_version_only New in version 3.1. Specify the CTest UpdateVersionOnly setting in a ctest(1) dashboard client script. ### Ctest_update_version_override New in version 3.15. Specify the CTest UpdateVersionOverride setting in a ctest(1) dashboard client script. ### Ctest_use_launchers New in version 3.1. Specify the CTest UseLaunchers setting in a ctest(1) dashboard client script. ## Variables for Cpack ### Cpack_absolute_destination_files List of files which have been installed using an ABSOLUTE DESTINATION path. This variable is a Read-Only variable which is set internally by CPack during installation and before packaging using Cmake_absolute_destination_files defined in cmake_install.cmake scripts. The value can be used within CPack project configuration file and/or CPack<GEN>.cmake file of <GEN> generator. ### Cpack_component_include_toplevel_directory Boolean toggle to include/exclude top level directory (component case). Similar usage as Cpack_include_toplevel_directory but for the component case. See Cpack_include_toplevel_directory documentation for the detail. ### Cpack_error_on_absolute_install_destination Ask CPack to error out as soon as a file with absolute INSTALL DESTINATION is encountered. The fatal error is emitted before the installation of the offending file takes place. Some CPack generators, like NSIS, enforce this internally. This variable triggers the definition of Cmake_error_on_absolute_install_destination when CPack runs. ### Cpack_include_toplevel_directory Boolean toggle to include/exclude top level directory. When preparing a package CPack installs the item under the so-called top level directory. The purpose of is to include (set to 1 or ON or TRUE) the top level directory in the package or not (set to 0 or OFF or FALSE). Each CPack generator has a built-in default value for this variable. E.g. Archive generators (ZIP, TGZ, ...) includes the top level whereas RPM or DEB don't. The user may override the default value by setting this variable. There is a similar variable Cpack_component_include_toplevel_directory which may be used to override the behavior for the component packaging case which may have different default value for historical (now backward compatibility) reason. ### Cpack_install_default_directory_permissions New in version 3.11. Default permissions for implicitly created directories during packaging. This variable serves the same purpose during packaging as the Cmake_install_default_directory_permissions variable serves during installation (e.g. make install). If include(CPack) is used then by default this variable is set to the content of Cmake_install_default_directory_permissions. ### Cpack_packaging_install_prefix The prefix used in the built package. Each CPack generator has a default value (like /usr). This default value may be overwritten from the CMakeLists.txt or the cpack(1) command line by setting an alternative value. Example: set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") This is not the same purpose as Cmake_install_prefix which is used when installing from the build tree without building a package. ### Cpack_set_destdir Boolean toggle to make CPack use DESTDIR mechanism when packaging. DESTDIR means DESTination DIRectory. It is commonly used by makefile users in order to install software at non-default location. It is a basic relocation mechanism that should not be used on Windows (see Cmake_install_prefix documentation). It is usually invoked like this: make DESTDIR=/home/john install which will install the concerned software using the installation prefix, e.g. /usr/local prepended with the DESTDIR value which finally gives /home/john/usr/local. When preparing a package, CPack first installs the items to be packaged in a local (to the build tree) directory by using the same DESTDIR mechanism. Nevertheless, if CPACK_SET_DESTDIR is set then CPack will set DESTDIR before doing the local install. The most noticeable difference is that without CPACK_SET_DESTDIR, CPack uses Cpack_packaging_install_prefix as a prefix whereas with CPACK_SET_DESTDIR set, CPack will use Cmake_install_prefix as a prefix. Manually setting CPACK_SET_DESTDIR may help (or simply be necessary) if some install rules uses absolute DESTINATION (see CMake install() command). However, starting with CPack/CMake 2.8.3 RPM and DEB installers tries to handle DESTDIR automatically so that it is seldom necessary for the user to set it. ### Cpack_warn_on_absolute_install_destination Ask CPack to warn each time a file with absolute INSTALL DESTINATION is encountered. This variable triggers the definition of Cmake_warn_on_absolute_install_destination when CPack runs cmake_install.cmake scripts. ## Variable Expansion Operators ### Cache New in version 3.13. Operator to read cache variables. Use the syntax$CACHE{VAR} to read cache entry VAR. See the cmake-language(7) variables documentation for more complete documentation of the interaction of normal variables and cache entries.

When evaluating Variable References of the form ${VAR}, CMake first searches for a normal variable with that name, and if not found CMake will search for a cache entry with that name. The$CACHE{VAR} syntax can be used to do direct cache lookup and ignore any existing normal variable.

See the set() and unset() commands to see how to write or remove cache variables.

### Env

Use the syntax \$ENV{VAR} to read environment variable VAR.

To test whether an environment variable is defined, use the signature if(DEFINED ENV{<name>}) of the if() command.

See the set() and unset() commands to see how to write or remove environment variables.

## Internal Variables

CMake has many internal variables.  Most of them are undocumented. Some of them, however, were at some point described as normal variables, and therefore may be encountered in legacy code. They are subject to change, and not recommended for use in project code.

### Cmake_home_directory

Path to top of source tree. Same as Cmake_source_dir.

This is an internal cache entry used to locate the source directory when loading a CMakeCache.txt from a build tree.  It should not be used in project code.  The variable Cmake_source_dir has the same value and should be preferred.

### Cmake_internal_platform_abi

An internal variable subject to change.

This is used in determining the compiler ABI and is subject to change.

### Cmake_<Lang>_compiler_abi

An internal variable subject to change.

This is used in determining the compiler ABI and is subject to change.

### Cmake_<Lang>_compiler_architecture_id

New in version 3.10.

An internal variable subject to change.

This is used to identify the variant of a compiler based on its target architecture.  For some compilers this is needed to determine the correct usage.

### Cmake_<Lang>_compiler_version_internal

New in version 3.10.

An internal variable subject to change.

This is used to identify the variant of a compiler based on an internal version number.  For some compilers this is needed to determine the correct usage.

### Cmake_<Lang>_platform_id

An internal variable subject to change.

This is used in determining the platform and is subject to change.

### Cmake_not_using_config_flags

Skip _BUILD_TYPE flags if true.

This is an internal flag used by the generators in CMake to tell CMake to skip the _BUILD_TYPE flags.

### CMAKE_VS_INTEL_Fortran_PROJECT_VERSION

When generating for Visual Studio 9 2008 or greater with the Intel Fortran plugin installed, this specifies the .vfproj project file format version.  This is intended for internal use by CMake and should not be used by project code.

## Referenced By

May 30, 2021 3.20.3 CMake