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 cmake -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¶

This variable is used internally by CMake, and may not be set during the first configuration of a build tree. When it is set, it has the same value as CMAKE_BINARY_DIR. Use that variable instead.

CMAKE_CFG_INTDIR¶

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

Build-time reference to per-configuration output subdirectory.

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

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

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

add_executable(mytool mytool.c)
add_custom_command(


  OUTPUT out.txt


  COMMAND ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/mytool


          ${CMAKE_CURRENT_SOURCE_DIR}/in.txt out.txt


  DEPENDS mytool in.txt


  )
add_custom_target(drive ALL DEPENDS out.txt)

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

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

CMAKE_COMMAND¶

The full path to the cmake(1) executable.

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

CMAKE_CPACK_COMMAND¶

Added in version 3.13.

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

This is the full path to the CPack executable cpack(1) that can be used for custom commands or tests to invoke CPack commands.

CMAKE_CROSSCOMPILING¶

This variable is set by CMake to indicate whether it 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, if not manually set, it will be given the same value as CMAKE_HOST_SYSTEM_NAME, 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¶

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

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

Added in version 3.28: This variable can be initialized via an CMAKE_CROSSCOMPILING_EMULATOR environment variable.

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

This variable is also used as the default value for the CROSSCOMPILING_EMULATOR target property of executables. However, while generator expressions are supported by the target property (since CMake 3.29), they are not supported by this variable's try_run() functionality.

CMAKE_CTEST_COMMAND¶

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

This is the full path to the CTest executable ctest(1) that can be used for custom commands or tests to invoke CTest commands.

CMAKE_CURRENT_BINARY_DIR¶

The path to the binary directory currently being processed.

This is 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 cmake -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¶

Added in version 3.17.

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

See also CMAKE_CURRENT_FUNCTION_LIST_DIR, CMAKE_CURRENT_FUNCTION_LIST_FILE and CMAKE_CURRENT_FUNCTION_LIST_LINE.

CMAKE_CURRENT_FUNCTION_LIST_DIR¶

Added in version 3.17.

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

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

set(_THIS_MODULE_BASE_DIR "${CMAKE_CURRENT_LIST_DIR}")
function(foo)


  configure_file(


    "${_THIS_MODULE_BASE_DIR}/some.template.in"


    some.output


  )
endfunction()

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

function(foo)


  configure_file(


    "${CMAKE_CURRENT_FUNCTION_LIST_DIR}/some.template.in"


    some.output


  )
endfunction()

See also CMAKE_CURRENT_FUNCTION, CMAKE_CURRENT_FUNCTION_LIST_FILE and CMAKE_CURRENT_FUNCTION_LIST_LINE.

CMAKE_CURRENT_FUNCTION_LIST_FILE¶

Added in version 3.17.

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

See also CMAKE_CURRENT_FUNCTION, CMAKE_CURRENT_FUNCTION_LIST_DIR and CMAKE_CURRENT_FUNCTION_LIST_LINE.

CMAKE_CURRENT_FUNCTION_LIST_LINE¶

Added in version 3.17.

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

See also CMAKE_CURRENT_FUNCTION, CMAKE_CURRENT_FUNCTION_LIST_DIR and CMAKE_CURRENT_FUNCTION_LIST_FILE.

CMAKE_CURRENT_LIST_DIR¶

Full directory of the listfile currently being processed.

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

See also CMAKE_CURRENT_LIST_FILE.

CMAKE_CURRENT_LIST_FILE¶

Full path to the listfile currently being processed.

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

See also CMAKE_PARENT_LIST_FILE.

CMAKE_CURRENT_LIST_LINE¶

The line number of the current file being processed.

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

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

CMAKE_CURRENT_SOURCE_DIR¶

The path to the source directory currently being processed.

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

When run in cmake -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:

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¶

Added 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_SDK¶

Added in version 3.23.

Default value for DOTNET_SDK property of targets.

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

CMAKE_DOTNET_TARGET_FRAMEWORK¶

Added 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¶

Added 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 and Ninja Generators when not using any Extra Generators.

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 the target 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>.

See the CMAKE_HOST_EXECUTABLE_SUFFIX variable for the executable suffix on the host platform.

CMAKE_EXECUTABLE_SUFFIX_<LANG>¶

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

It overrides CMAKE_EXECUTABLE_SUFFIX for language <LANG>.

CMAKE_EXTRA_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¶

Added in version 3.17.

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

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¶

Added 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_REDIRECTS_DIR¶

Added in version 3.24.

This read-only variable specifies a directory that the find_package() command will check first before searching anywhere else for a module or config package file. A config package file in this directory will always be found in preference to any other Find module file or config package file.

The primary purpose of this variable is to facilitate integration between find_package() and FetchContent_MakeAvailable(). The latter command may create files in the CMAKE_FIND_PACKAGE_REDIRECTS_DIR directory when it populates a dependency. This allows subsequent calls to find_package() for the same dependency to reuse the populated contents instead of trying to satisfy the dependency from somewhere external to the build. Projects may also want to write files into this directory in some situations (see Integrating With find_package() for examples).

The directory that CMAKE_FIND_PACKAGE_REDIRECTS_DIR points to will always be erased and recreated empty at the start of every CMake run. Any files written into this directory during the CMake run will be lost the next time CMake configures the project.

CMAKE_FIND_PACKAGE_REDIRECTS_DIR is only set in CMake project mode. It is not set when CMake is run in script mode (i.e. cmake -P).

CMAKE_FIND_PACKAGE_SORT_DIRECTION¶

Added in version 3.7.

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

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

CMAKE_FIND_PACKAGE_SORT_ORDER¶

Added in version 3.7.

The default order for sorting directories which match a search path containing a glob expression found using find_package(). It can assume one of the following values:

Natural sorting can be employed to return the highest version when multiple versions of the same library are available to be found by find_package(). For example suppose that the following libraries have package configuration files on disk, in a directory of the same name, with all such directories residing in the same parent directory:

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 descending, 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 -G option, interactively in cmake-gui(1), or via the CMAKE_GENERATOR environment variable.

CMAKE_GENERATOR_INSTANCE¶

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

Visual Studio Instance Selection¶

Visual Studio Generators support instance specification for Visual Studio 2017 and above. The CMAKE_GENERATOR_INSTANCE variable may be set as a cache entry selecting an instance of Visual Studio via one of the following forms:

The location specifies the absolute path to the top-level directory of the VS installation.

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

Added in version 3.23: A portable VS instance, which is not known to the Visual Studio Installer, may be specified by providing both location and version=.

If the value of CMAKE_GENERATOR_INSTANCE is not specified explicitly by the user or a toolchain file, CMake queries the Visual Studio Installer to locate VS instances, chooses one, and sets the variable as a cache entry to hold the value persistently. If an environment variable of the form VS##0COMNTOOLS, where ## the Visual Studio major version number, is set and points to the Common7/Tools directory within one of the VS instances, that instance will be used. Otherwise, if more than one VS instance is installed we do not define which one is chosen by default.

The VS version build number of the selected VS instance is provided in the CMAKE_VS_VERSION_BUILD_NUMBER variable.

CMAKE_GENERATOR_PLATFORM¶

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

See native build system documentation for allowed platform names.

Visual Studio Platform Selection¶

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

The platform specifies the target platform (VS target architecture), such as x64, ARM64, or Win32. The selected platform name is provided in the CMAKE_VS_PLATFORM_NAME variable.

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

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

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:

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:

Visual Studio Toolset Customization¶

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

Additional key=value pairs are available:

CMAKE_IMPORT_LIBRARY_PREFIX¶

The prefix for import libraries that you link to.

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

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

CMAKE_IMPORT_LIBRARY_SUFFIX¶

The suffix for import libraries that you link to.

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

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

CMAKE_JOB_POOL_COMPILE¶

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

CMAKE_JOB_POOL_LINK¶

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

CMAKE_JOB_POOL_PRECOMPILE_HEADER¶

Added 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¶

Added 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¶

Added in version 3.9.

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

See also CMAKE_AR.

CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT¶

Added in version 3.14.

Identification string of the compiler frontend variant.

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

NOTE:

Changed in version 3.26: This variable is set for GNU, MSVC, and AppleClang compilers that have only one frontend variant.

CMAKE_<LANG>_COMPILER_LINKER¶

Added in version 3.29.

The full path to the linker for LANG.

This is the command that will be used as the <LANG> linker.

This variable is not guaranteed to be defined for all linkers or languages.

NOTE:

CMAKE_<LANG>_COMPILER_LINKER_FRONTEND_VARIANT¶

Added in version 3.29.

Identification string of the linker frontend variant.

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

NOTE:

CMAKE_<LANG>_COMPILER_LINKER_ID¶

Added in version 3.29.

Linker identification string.

A short string unique to the linker vendor. Possible values include:

This variable is not guaranteed to be defined for all linkers or languages.

CMAKE_<LANG>_COMPILER_LINKER_VERSION¶

Added in version 3.29.

Linker version string.

Linker version in major[.minor[.patch[.tweak]]] format. This variable is not guaranteed to be defined for all linkers or languages.

CMAKE_<LANG>_COMPILER_RANLIB¶

Added in version 3.9.

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

See also CMAKE_RANLIB.

CMAKE_<LANG>_LINK_LIBRARY_SUFFIX¶

Added in version 3.16.

Language-specific suffix for libraries that you link to.

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

CMAKE_LINK_LIBRARY_SUFFIX¶

The suffix for libraries that you link to.

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

CMAKE_LINK_SEARCH_END_STATIC¶

Added in version 3.4.

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

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

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

See also CMAKE_LINK_SEARCH_START_STATIC.

CMAKE_LINK_SEARCH_START_STATIC¶

Added in version 3.4.

Assume the linker looks for static libraries by default.

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

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

See also CMAKE_LINK_SEARCH_END_STATIC.

CMAKE_MAJOR_VERSION¶

First version number component of the CMAKE_VERSION variable.

CMAKE_MAKE_PROGRAM¶

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

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

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

CMAKE_MATCH_COUNT¶

Added 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>¶

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

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

CMAKE_MINIMUM_REQUIRED_VERSION¶

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

CMAKE_MINOR_VERSION¶

Second version number component of the CMAKE_VERSION variable.

CMAKE_NETRC¶

Added in version 3.11.

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

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

The local option takes precedence over this variable.

CMAKE_NETRC_FILE¶

Added in version 3.11.

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

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

The local option takes precedence over this variable.

CMAKE_PARENT_LIST_FILE¶

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

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

CMAKE_PATCH_VERSION¶

Third version number component of the CMAKE_VERSION variable.

CMAKE_PROJECT_DESCRIPTION¶

Added 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¶

Added 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 "https://first.example.com")
project(Second HOMEPAGE_URL "https://second.example.com")
add_subdirectory(sub)
project(Third HOMEPAGE_URL "https://third.example.com")

And sub/CMakeLists.txt with the following contents:

project(SubProj HOMEPAGE_URL "https://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 = https://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¶

Added in version 3.12.

The version of the top level project.

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

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

And sub/CMakeLists.txt with the following contents:

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

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

CMAKE_PROJECT_VERSION = 3.4.5

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

CMAKE_PROJECT_VERSION_MAJOR¶

Added in version 3.12.

The major version of the top level project.

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

CMAKE_PROJECT_VERSION_MINOR¶

Added in version 3.12.

The minor version of the top level project.

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

CMAKE_PROJECT_VERSION_PATCH¶

Added in version 3.12.

The patch version of the top level project.

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

CMAKE_PROJECT_VERSION_TWEAK¶

Added in version 3.12.

The tweak version of the top level project.

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

CMAKE_RANLIB¶

Name of randomizing tool for static libraries.

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

CMAKE_ROOT¶

Install directory for running cmake.

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

CMAKE_RULE_MESSAGES¶

Added 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 -P script file currently being processed.

When run in cmake -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_LIBRARY_ARCHIVE_SUFFIX¶

Added in version 3.31.

The suffix for archived shared libraries that you link to.

The suffix to use for the end of a archive containing a shared library, .a on AIX.

CMAKE_SHARED_MODULE_PREFIX¶

The prefix for loadable modules that you link to.

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

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

CMAKE_SHARED_MODULE_SUFFIX¶

The suffix for shared libraries that you link to.

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

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

CMAKE_SIZEOF_VOID_P¶

Size of a void pointer.

This is set to the size of a pointer on the target machine, and is determined when a compiled language is enabled. 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. To omit RPATH in the build step, use CMAKE_SKIP_BUILD_RPATH.

For more information on RPATH handling see the INSTALL_RPATH and BUILD_RPATH target properties.

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 cmake -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_COMPILATION_MODE¶

Added in version 3.29.

Specify how Swift compiles a target. This variable is used to initialize the Swift_COMPILATION_MODE property on targets as they are created.

The allowed values are:

Use generator expressions to support per-configuration specification. For example, the code:

set(CMAKE_Swift_COMPILATION_MODE


  "$<IF:$<CONFIG:Release>,wholemodule,incremental>")

sets the default Swift compilation mode to wholemodule mode when building a release configuration and to incremental mode in other configurations.

If this variable is not set then the Swift_COMPILATION_MODE target property will not be set automatically. If that property is unset then CMake uses the default value incremental to build the Swift source files.

NOTE:

CMAKE_Swift_MODULE_DIRECTORY¶

Added in version 3.15.

Swift module output directory.

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

CMAKE_Swift_NUM_THREADS¶

Added 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_TEST_LAUNCHER¶

Added in version 3.29.

This variable is used to initialize the TEST_LAUNCHER target property of executable targets as they are created. It is used to specify a launcher for running tests, added by the add_test() command, that run an executable target.

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

This variable can be initialized via an CMAKE_TEST_LAUNCHER environment variable.

CMAKE_TOOLCHAIN_FILE¶

Path to toolchain file supplied to cmake(1).

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

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

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

See the CMAKE_PROJECT_TOP_LEVEL_INCLUDES variable for setting other things not directly related to the toolchain.

CMAKE_TWEAK_VERSION¶

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

NOTE:

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_VS_DEVENV_COMMAND¶

The Visual Studio Generators set this variable to the devenv.com command installed with the corresponding Visual Studio version.

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

See also the CMAKE_VS_MSBUILD_COMMAND and CMAKE_MAKE_PROGRAM variables.

CMAKE_VS_MSBUILD_COMMAND¶

The Visual Studio Generators 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.

See also the CMAKE_VS_DEVENV_COMMAND and CMAKE_MAKE_PROGRAM variables.

CMAKE_VS_NsightTegra_VERSION¶

Added 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_NUGET_PACKAGE_RESTORE¶

Added in version 3.23.

When using a Visual Studio generator, this cache variable controls if msbuild should automatically attempt to restore NuGet packages prior to a build. NuGet packages can be defined using the VS_PACKAGE_REFERENCES property on a target. If no package references are defined, this setting will do nothing.

The command line option --resolve-package-references can be used alternatively to control the resolve behavior globally. This option will take precedence over the cache variable.

Targets that use the DOTNET_SDK are required to run a restore before building. Disabling this option may cause the build to fail in such projects.

This setting is stored as a cache entry. Default value is ON.

See also the VS_PACKAGE_REFERENCES property.

CMAKE_VS_PLATFORM_NAME¶

Added in version 3.1.

Visual Studio target platform name used by the current generator.

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

See also the CMAKE_VS_PLATFORM_NAME_DEFAULT variable.

CMAKE_VS_PLATFORM_NAME_DEFAULT¶

Added in version 3.14.3.

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

See also the CMAKE_VS_PLATFORM_NAME variable.

CMAKE_VS_PLATFORM_TOOLSET¶

Visual Studio Platform Toolset name.

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

See the CMAKE_GENERATOR_TOOLSET variable for details.

CMAKE_VS_PLATFORM_TOOLSET_CUDA¶

Added 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¶

Added 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 the nvcc compiler in path .\bin and must provide Visual Studio integration files in path .\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_FORTRAN¶

Added in version 3.29.

Fortran compiler to be used by Visual Studio projects.

Visual Studio Generators support selecting among Fortran compilers that have the required Visual Studio Integration feature installed. The compiler may be specified by a field in CMAKE_GENERATOR_TOOLSET of the form fortran=.... CMake provides the selected Fortran compiler in this variable. The value may be empty if the field was not specified.

CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE¶

Added 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, ARM64 or empty).

CMAKE_VS_PLATFORM_TOOLSET_VERSION¶

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

Added 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¶

Added 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_TARGET_FRAMEWORK_IDENTIFIER¶

Added in version 3.22.

Visual Studio target framework identifier.

In some cases, the Visual Studio Generators may use an explicit value for the MSBuild TargetFrameworkIdentifier setting in .csproj files. CMake provides the chosen value in this variable.

See also CMAKE_VS_TARGET_FRAMEWORK_VERSION and CMAKE_VS_TARGET_FRAMEWORK_TARGETS_VERSION.

CMAKE_VS_TARGET_FRAMEWORK_TARGETS_VERSION¶

Added in version 3.22.

Visual Studio target framework targets version.

In some cases, the Visual Studio Generators may use an explicit value for the MSBuild TargetFrameworkTargetsVersion setting in .csproj files. CMake provides the chosen value in this variable.

See also CMAKE_VS_TARGET_FRAMEWORK_VERSION and CMAKE_VS_TARGET_FRAMEWORK_IDENTIFIER.

CMAKE_VS_TARGET_FRAMEWORK_VERSION¶

Added in version 3.22.

Visual Studio target framework version.

In some cases, the Visual Studio Generators may use an explicit value for the MSBuild TargetFrameworkVersion setting in .csproj files. CMake provides the chosen value in this variable.

See the CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION variable and DOTNET_TARGET_FRAMEWORK_VERSION target property to specify custom TargetFrameworkVersion values for project targets.

See also CMAKE_VS_TARGET_FRAMEWORK_IDENTIFIER and CMAKE_VS_TARGET_FRAMEWORK_TARGETS_VERSION.

CMAKE_VS_USE_DEBUG_LIBRARIES¶

Added in version 3.30.

Indicate to Visual Studio Generators what configurations are considered debug configurations. This controls the UseDebugLibraries setting in each configuration of a .vcxproj file.

The "Use Debug Libraries" setting in Visual Studio projects, despite its specific-sounding name, is a general-purpose indicator of what configurations are considered debug configurations. In standalone projects, this may affect MSBuild's default selection of MSVC runtime library, optimization flags, runtime checks, and similar settings. In CMake projects those settings are typically generated explicitly based on the project's specification, e.g., the MSVC runtime library is controlled by CMAKE_MSVC_RUNTIME_LIBRARY. However, the UseDebugLibraries indicator is useful for reference by both humans and tools, and may also affect the behavior of platform-specific SDKs.

Set CMAKE_VS_USE_DEBUG_LIBRARIES to a true or false value to indicate whether each configuration is considered a debug configuration. The value may also be the empty string ("") in which case no UseDebugLibraries will be added explicitly by CMake, and MSBuild will use its default value, false.

Use generator expressions for per-configuration specification. For example, the code:

set(CMAKE_VS_USE_DEBUG_LIBRARIES "$<CONFIG:Debug,Custom>")

indicates that all following targets consider their "Debug" and "Custom" configurations to be debug configurations, and their other configurations to be non-debug configurations.

This variable is used to initialize the VS_USE_DEBUG_LIBRARIES property on all targets as they are created. It is also propagated by calls to the try_compile() command into its test project.

If this variable is not set then the VS_USE_DEBUG_LIBRARIES property will not be set automatically. If that property is not set then CMake generates UseDebugLibraries using heuristics to determine which configurations are debug configurations. See policy CMP0162.

CMAKE_VS_VERSION_BUILD_NUMBER¶

Added in version 3.26.

Visual Studio version.

Visual Studio Generators for VS 2017 and above set this variable to the Visual Studio version build number in the format <major>.<minor>.<date>.<build>.

The components are:

<major>.<minor>

<date>

<build>

The build number is reported by vswhere as installationVersion. For example, VS 16.11.10 has build number 16.11.32126.315.

See also the CMAKE_GENERATOR_INSTANCE variable.

CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION¶

Added in version 3.27.

Tell Visual Studio Generators to use the given Windows Target Platform Minimum Version.

This variable is used to initialize the VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION property on all targets when they are created. See that target property for additional information.

CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION¶

Added in version 3.4.

Visual Studio Windows Target Platform Version.

When targeting Windows 10 and above, Visual Studio Generators for VS 2015 and above support specification of a Windows SDK version:

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.

See also CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM.

CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM¶

Added 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 to exclude Windows SDK versions from consideration for CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.

CMAKE_WINDOWS_KMDF_VERSION¶

Added in version 3.31.

Specify the Kernel-Mode Drive Framework target version.

A toolchain file that sets CMAKE_SYSTEM_NAME to WindowsKernelModeDriver must also set CMAKE_WINDOWS_KMDF_VERSION to specify the KMDF target version.

CMAKE_XCODE_BUILD_SYSTEM¶

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

The CMAKE_XCODE_BUILD_SYSTEM variable is informational and should not be modified by project code. See the Toolset and 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 -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¶

Added 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¶

Added 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>_IS_TOP_LEVEL¶

Added in version 3.21.

A boolean variable indicating whether the named project was called in a top level CMakeLists.txt file.

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

The variable value will be true in:

The variable value will be false in:

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

See also the component-wise version variables <PROJECT-NAME>_VERSION_MAJOR, <PROJECT-NAME>_VERSION_MINOR, <PROJECT-NAME>_VERSION_PATCH, and <PROJECT-NAME>_VERSION_TWEAK.

<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¶

Added 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¶

Added 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_IS_TOP_LEVEL¶

Added in version 3.21.

A boolean variable indicating whether the most recently called project() command in the current scope or above was in the top level CMakeLists.txt file.

Some modules should only be included as part of the top level CMakeLists.txt file to not cause unintended side effects in the build tree, and this variable can be used to conditionally execute such code. For example, consider the CTest module, which creates targets and options:

project(MyProject)
...
if(PROJECT_IS_TOP_LEVEL)


  include(CTest)
endif()

The variable value will be true in:

The variable value will be false in:

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.

See also the component-wise version variables PROJECT_VERSION_MAJOR, PROJECT_VERSION_MINOR, PROJECT_VERSION_PATCH, and PROJECT_VERSION_TWEAK.

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.

BUILD_SHARED_LIBS¶

Tell add_library() to default to SHARED libraries, instead of STATIC libraries, when called with no explicit library type.

Calls to add_library() without any explicit library type check the current BUILD_SHARED_LIBS variable value. If it is true, then the default library type is SHARED. Otherwise, the default is STATIC.

For example, the code:

add_library(example ${sources})

behaves as if written

if(BUILD_SHARED_LIBS)


  add_library(example SHARED ${sources})
else()


  add_library(example STATIC ${sources})
endif()

CMake does not define BUILD_SHARED_LIBS by default, but projects often create a cache entry for it using the option() command:

option(BUILD_SHARED_LIBS "Build using shared libraries" ON)

This provides a switch that users can control, e.g., with cmake -D. If adding such an option to the project, do so in the top level CMakeLists.txt file, before any add_library() calls. Note that if bringing external dependencies directly into the build, such as with FetchContent or a direct call to add_subdirectory(), and one of those dependencies has such a call to option(BUILD_SHARED_LIBS ...), the top level project must also call option(BUILD_SHARED_LIBS ...) before bringing in its dependencies. Failure to do so can lead to different behavior between the first and subsequent CMake runs.

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_ADD_CUSTOM_COMMAND_DEPENDS_EXPLICIT_ONLY¶

Added in version 3.27.

Whether to enable the DEPENDS_EXPLICIT_ONLY option by default in add_custom_command().

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

See also CMAKE_OPTIMIZE_DEPENDENCIES.

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.

There is also an environment variable CMAKE_APPBUNDLE_PATH, which is used as an additional list of search directories.

CMAKE_BUILD_TYPE¶

Specifies the build type on single-configuration generators (e.g. Makefile Generators or Ninja). Typical values include Debug, Release, RelWithDebInfo and MinSizeRel, but custom build types can also be defined.

This variable is initialized by the first project() or enable_language() command called in a project when a new build tree is first created. If the CMAKE_BUILD_TYPE environment variable is set, its value is used. Otherwise, a toolchain-specific default is chosen when a language is enabled. The default value is often an empty string, but this is usually not desirable and one of the other standard build types is usually more appropriate.

Depending on the situation, the value of this variable may be treated case-sensitively or case-insensitively. See Build Configurations for discussion of this and other related topics.

For multi-config generators, see CMAKE_CONFIGURATION_TYPES.

CMAKE_CLANG_VFS_OVERLAY¶

Added 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¶

Added 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¶

Added 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¶

Added 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_DIAGNOSTICS¶

Added in version 3.24.

Enable color diagnostics throughout.

This variable uses three states: ON, OFF and not defined.

When not defined:

When ON:

When OFF:

If the CMAKE_COLOR_DIAGNOSTICS environment variable is set, its value is used. Otherwise, CMAKE_COLOR_DIAGNOSTICS is not defined by default.

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 (configurations) on multi-config generators (e.g. Visual Studio, Xcode, or Ninja Multi-Config) as a semicolon-separated list. Typical entries include Debug, Release, RelWithDebInfo and MinSizeRel, but custom build types can also be defined.

This variable is initialized by the first project() or enable_language() command called in a project when a new build tree is first created. If the CMAKE_CONFIGURATION_TYPES environment variable is set, its value is used. Otherwise, the default value is generator-specific.

Depending on the situation, the values in this variable may be treated case-sensitively or case-insensitively. See Build Configurations for discussion of this and other related topics.

For single-config generators, see CMAKE_BUILD_TYPE.

CMAKE_DEPENDS_IN_PROJECT_ONLY¶

Added 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 -U.

Note that this variable can lead to inconsistent results within the project. Consider the case where a dependency is requested via find_package() from two different places within the project. If the first call does not have the REQUIRED keyword, it will not find the dependency when CMAKE_DISABLE_FIND_PACKAGE_<PackageName> is set to true for that dependency. The project will proceed under the assumption that the dependency isn't available. If the second call elsewhere in the project does have the REQUIRED keyword, it can succeed. Two different parts of the same project have then seen opposite results for the same dependency.

See also the CMAKE_REQUIRE_FIND_PACKAGE_<PackageName> variable.

CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES¶

Added 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¶

Added 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¶

Added 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¶

Added 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¶

Added 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¶

Added 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_BUILD_DATABASE¶

Added in version 3.31.

NOTE:

Enable/Disable output of module compile commands during the build.

If enabled, generates a build_database.json file containing the information necessary to compile a target's C++ module sources with any tooling. The format of the JSON file looks like:

{


  "version": 1,


  "revision": 0,


  "sets": [


    {


      "family-name" : "export_build_database",


      "name" : "export_build_database@Debug",


      "translation-units" : [


        {


          "arguments": [


            "/path/to/compiler",


            "...",


          ],


          "baseline-arguments" :


          [


            "...",


          ],


          "local-arguments" :


          [


            "...",


          ],


          "object": "CMakeFiles/target.dir/source.cxx.o",


          "private": true,


          "provides": {


            "importable": "path/to/bmi"


          },


          "requires" : [],


          "source": "path/to/source.cxx",


          "work-directory": "/path/to/working/directory"


        }


      ],


      "visible-sets" : []


    }


  ]
}

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

NOTE:

When supported and enabled, numerous targets are created in order to make it possible to build a file containing just the commands that are needed for the tool in question.

CMAKE_EXPORT_COMPILE_COMMANDS¶

Added 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",


    "output": "../foo.dir/foo.cc.o"


  },


  ...


  {


    "directory": "/home/user/development/project",


    "command": "/usr/bin/c++ ... -c ../foo/bar.cc",


    "file": "../foo/bar.cc",


    "output": "../foo.dir/bar.cc.o"


  }
]

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

NOTE:

CMAKE_EXPORT_PACKAGE_REGISTRY¶

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

See also Disabling the Package Registry.

CMAKE_EXPORT_NO_PACKAGE_REGISTRY¶

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

See also Disabling the Package Registry.

CMAKE_FIND_APPBUNDLE¶

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

CMAKE_FIND_FRAMEWORK¶

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

CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX¶

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

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, depending on the compiler, .dll.lib, .dll.a, .a (e.g. rustc, GCC, or Clang), so when it tries to find the foo library, it will look for [<prefix>]foo[.dll].lib and/or [<prefix>]foo[.dll].a, depending on the compiler used and the <prefix> specified in the CMAKE_FIND_LIBRARY_PREFIXES.

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_PREFER_CONFIG¶

Added 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_RESOLVE_SYMLINKS¶

Added in version 3.14.

Set to TRUE to tell find_package() calls to resolve symbolic links in the value of <PackageName>_DIR.

This is helpful in use cases where the package search path points at a proxy directory in which symlinks to the real package locations appear. This is not enabled by default because there are also common use cases in which the symlinks should be preserved.

CMAKE_FIND_PACKAGE_TARGETS_GLOBAL¶

Added in version 3.24.

Setting to TRUE promotes all IMPORTED targets discovered by find_package() to a GLOBAL scope.

Setting this to TRUE is akin to specifying GLOBAL as an argument to find_package(). Default value is OFF.

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¶

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

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.

See also the CMAKE_FIND_USE_CMAKE_PATH, CMAKE_FIND_USE_CMAKE_SYSTEM_PATH, CMAKE_FIND_USE_INSTALL_PREFIX, CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH, CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY, CMAKE_FIND_USE_PACKAGE_REGISTRY, and CMAKE_FIND_USE_PACKAGE_ROOT_PATH variables.

CMAKE_FIND_USE_CMAKE_PATH¶

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

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.

See also the CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH, CMAKE_FIND_USE_CMAKE_SYSTEM_PATH, CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH, CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY, CMAKE_FIND_USE_PACKAGE_REGISTRY, and CMAKE_FIND_USE_PACKAGE_ROOT_PATH variables.

CMAKE_FIND_USE_CMAKE_SYSTEM_PATH¶

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

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.

See also the CMAKE_FIND_USE_CMAKE_PATH, CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH, CMAKE_FIND_USE_INSTALL_PREFIX, CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH, CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY, CMAKE_FIND_USE_PACKAGE_REGISTRY, and CMAKE_FIND_USE_PACKAGE_ROOT_PATH variables.

CMAKE_FIND_USE_INSTALL_PREFIX¶

Added in version 3.24.

Controls the default behavior of the following commands for whether or not to search the locations in the CMAKE_INSTALL_PREFIX and CMAKE_STAGING_PREFIX variables.

This is useful in cross-compiling environments.

Due to backwards compatibility with CMAKE_FIND_NO_INSTALL_PREFIX, the behavior of the find command change based on if this variable exists.

By default this variable is not defined. Explicit options given to the above commands take precedence over this variable.

See also the CMAKE_FIND_USE_CMAKE_PATH, CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH, CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH, CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY, CMAKE_FIND_USE_PACKAGE_REGISTRY, and CMAKE_FIND_USE_PACKAGE_ROOT_PATH variables.

CMAKE_FIND_USE_PACKAGE_REGISTRY¶

Added 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_INSTALL_PREFIX, 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¶

Added in version 3.16.

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

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.

See also the CMAKE_FIND_USE_CMAKE_PATH, CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH, CMAKE_FIND_USE_INSTALL_PREFIX, CMAKE_FIND_USE_CMAKE_SYSTEM_PATH, CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH, CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY, and CMAKE_FIND_USE_PACKAGE_REGISTRY variables.

CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH¶

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

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.

See also the CMAKE_FIND_USE_CMAKE_PATH, CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH, CMAKE_FIND_USE_INSTALL_PREFIX, CMAKE_FIND_USE_CMAKE_SYSTEM_PATH, CMAKE_FIND_USE_PACKAGE_REGISTRY, CMAKE_FIND_USE_PACKAGE_ROOT_PATH, and CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY variables.

CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY¶

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

See also Disabling the Package Registry.

See also the CMAKE_FIND_USE_CMAKE_PATH, CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH, CMAKE_FIND_USE_INSTALL_PREFIX, CMAKE_FIND_USE_CMAKE_SYSTEM_PATH, CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH, CMAKE_FIND_USE_PACKAGE_REGISTRY, and CMAKE_FIND_USE_PACKAGE_ROOT_PATH variables.

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.

There is also an environment variable CMAKE_FRAMEWORK_PATH, which is used as an additional list of search directories.

CMAKE_IGNORE_PATH¶

Semicolon-separated list of directories to be ignored by the various find...() commands.

For find_program(), find_library(), find_file(), and find_path(), any file found in one of the listed directories will be ignored. The listed directories do not apply recursively, so any subdirectories to be ignored must also be explicitly listed. CMAKE_IGNORE_PATH does not affect the search prefixes used by these four commands. To ignore individual paths under a search prefix (e.g. bin, include, lib, etc.), each path must be listed in CMAKE_IGNORE_PATH as a full absolute path. CMAKE_IGNORE_PREFIX_PATH provides a more appropriate way to ignore a whole search prefix.

find_package() is also affected by CMAKE_IGNORE_PATH, but only for Config mode searches. Any <Name>Config.cmake or <name>-config.cmake file found in one of the specified directories will be ignored. In addition, any search prefix found in CMAKE_IGNORE_PATH will be skipped for backward compatibility reasons, but new code should prefer to use CMAKE_IGNORE_PREFIX_PATH to ignore prefixes instead.

Ignoring search locations can be 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, CMAKE_IGNORE_PATH is empty. It is intended to be set by the project or the end user.

See also the following variables:

CMAKE_IGNORE_PREFIX_PATH¶

Added in version 3.23.

Semicolon-separated list of search prefixes to be ignored by the find_program(), find_library(), find_file(), and find_path() commands. The prefixes are also ignored by the Config mode of the find_package() command (Module mode is unaffected). To ignore specific directories instead, see CMAKE_IGNORE_PATH.

Ignoring search locations can be 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, CMAKE_IGNORE_PREFIX_PATH is empty. It is intended to be set by the project or the end user.

See also the following variables:

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.

There is also an environment variable CMAKE_INCLUDE_PATH, which is used as an additional list of search directories.

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¶

Added 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_READ


     OWNER_WRITE


     OWNER_EXECUTE


     GROUP_READ


   )

CMAKE_INSTALL_MESSAGE¶

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

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 as follows:

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 to a staging area. See the DESTDIR environment variable 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. This behavior can be disabled by setting the CMAKE_FIND_NO_INSTALL_PREFIX to TRUE before the first project() invocation.

NOTE:

The CMAKE_INSTALL_PREFIX may be defined when configuring a build tree to set its installation prefix. Or, when using the cmake(1) command-line tool's --install mode, one may specify a different prefix using the --prefix option:

cmake --install . --prefix /my/install/prefix

CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT¶

Added 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 and the CMAKE_INSTALL_PREFIX environment variable is not set on the first run of CMake. 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_property(CACHE CMAKE_INSTALL_PREFIX PROPERTY VALUE "/my/default")
endif()

CMAKE_KATE_FILES_MODE¶

Added in version 3.27.

This cache variable is used by the Kate project generator and controls to what mode the files entry in the project file will be set. See cmake-generators(7).

Possible values are AUTO, SVN, GIT, HG, FOSSIL and LIST.

When set to LIST, CMake will put the list of source files known to CMake in the project file. When set to SVN, GIT, HG or FOSSIL, CMake will set the generated project accordingly to Subversion, git, Mercurial or Fossil, and Kate will then use the respective command line tool to retrieve the list of files in the project. When unset or set to AUTO, CMake will try to detect whether the source directory is part of a git or svn checkout or not, and put the respective entry into the project file.

CMAKE_KATE_MAKE_ARGUMENTS¶

Added in version 3.0.

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

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

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.

There is also an environment variable CMAKE_LIBRARY_PATH, which is used as an additional list of search directories.

See also CMAKE_SYSTEM_LIBRARY_PATH and CMAKE_PREFIX_PATH.

CMAKE_LINK_DIRECTORIES_BEFORE¶

Added in version 3.13.

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

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

CMAKE_LINK_LIBRARIES_ONLY_TARGETS¶

Added in version 3.23.

Set this variable to initialize the LINK_LIBRARIES_ONLY_TARGETS property of non-imported targets when they are created. Setting it to true enables an additional check that all items named by target_link_libraries() that can be target names are actually names of existing targets. See the target property documentation for details.

CMAKE_MAXIMUM_RECURSION_DEPTH¶

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

See also the CMAKE_MAXIMUM_RECURSION_DEPTH environment variable.

CMAKE_MESSAGE_CONTEXT¶

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

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¶

Added 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¶

Added 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)


  message(VERBOSE ${item})
endforeach()
list(POP_BACK CMAKE_MESSAGE_INDENT)
message(VERBOSE "No more indent")

Which results in the following output:

-- Collected items in the "listVar":
--   one
--   two
--   three
-- No more indent

CMAKE_MESSAGE_LOG_LEVEL¶

Added in version 3.17.

When set, this variable specifies the logging level used by the message() command. Valid values are the same as those for the --log-level command line option of the cmake(1) program. If this variable is set and the --log-level command line option is given, the command line option takes precedence.

The main advantage to using this variable is to make a log level persist between CMake runs. Setting it as a cache variable will ensure that subsequent CMake runs will continue to use the chosen log level.

Projects should not set this variable, it is intended for users so that they may control the log level according to their own needs.

Added in version 3.25: See the cmake_language() cmake_language command for a way to query the current message logging level.

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_MODULE_PATH¶

Semicolon-separated list of directories, represented using forward slashes, specifying a search path for CMake modules to be loaded by the include() or find_package() commands before checking the default modules that come with CMake. By default it is empty. It is intended to be set by the project.

It's fairly common for a project to have a directory containing various *.cmake files to assist in development. Adding the directory to the CMAKE_MODULE_PATH simplifies loading them. For example, a project's top-level CMakeLists.txt file may contain:

list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
include(Foo) # Loads ${CMAKE_CURRENT_SOURCE_DIR}/cmake/Foo.cmake
find_package(Bar) # Loads ${CMAKE_CURRENT_SOURCE_DIR}/cmake/FindBar.cmake

CMAKE_POLICY_DEFAULT_CMP<NNNN>¶

Default for CMake Policy CMP<NNNN> when it is otherwise left unset.

Commands cmake_minimum_required(VERSION) and cmake_policy(VERSION) by default leave policies introduced after the given version unset. Set CMAKE_POLICY_DEFAULT_CMP<NNNN> to OLD or NEW to specify the default for policy CMP<NNNN>, where <NNNN> is the policy number.

This variable should not be set by a project in CMake code as a way to set its own policies; use cmake_policy(SET) instead. This variable is meant to externally set policies for which a project has not itself been updated:

CMAKE_POLICY_WARNING_CMP<NNNN>¶

Explicitly enable or disable the warning when CMake Policy CMP<NNNN> has not been set explicitly by cmake_policy() or implicitly by cmake_minimum_required(). This is meaningful only for the policies that do not warn by default:

This variable should not be set by a project in CMake code. Project developers running CMake may set this variable in their cache to enable the warning (e.g. -DCMAKE_POLICY_WARNING_CMP<NNNN>=ON). Alternatively, running cmake(1) with the --debug-output, --trace, or --trace-expand option will also enable the warning.

CMAKE_PREFIX_PATH¶

Semicolon-separated list of directories specifying installation prefixes to be searched by the find_package(), find_program(), find_library(), find_file(), and find_path() commands. Each command will add appropriate subdirectories (like bin, lib, or include) as specified in its own documentation.

By default this is empty. It is intended to be set by the project.

There is also an environment variable CMAKE_PREFIX_PATH, which is used as an additional list of search prefixes.

See also CMAKE_SYSTEM_PREFIX_PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, CMAKE_PROGRAM_PATH, and CMAKE_IGNORE_PATH.

CMAKE_PROGRAM_PATH¶

Semicolon-separated list of directories specifying a search path for the find_program() command. By default it is empty, it is intended to be set by the project.

There is also an environment variable CMAKE_PROGRAM_PATH, which is used as an additional list of search directories.

See also CMAKE_SYSTEM_PROGRAM_PATH and CMAKE_PREFIX_PATH.

CMAKE_PROJECT_INCLUDE¶

Added in version 3.15.

A CMake language file to be included as the last step of all project() command calls. This is intended for injecting custom code into project builds without modifying their source. See Code Injection for a more detailed discussion of files potentially included during a project() call.

Added in version 3.29: This variable can be a semicolon-separated list of CMake language files to be included sequentially. It can also now refer to module names to be found in CMAKE_MODULE_PATH or as a builtin CMake module.

See also the CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE, CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE, CMAKE_PROJECT_INCLUDE_BEFORE, and CMAKE_PROJECT_TOP_LEVEL_INCLUDES variables.

CMAKE_PROJECT_INCLUDE_BEFORE¶

Added in version 3.15.

A CMake language file to be included as the first step of all project() command calls. This is intended for injecting custom code into project builds without modifying their source. See Code Injection for a more detailed discussion of files potentially included during a project() call.

Added in version 3.29: This variable can be a semicolon-separated list of CMake language files to be included sequentially. It can also now refer to module names to be found in CMAKE_MODULE_PATH or as a builtin CMake module.

See also the CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE, CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE, CMAKE_PROJECT_INCLUDE, and CMAKE_PROJECT_TOP_LEVEL_INCLUDES variables.

CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE¶

A CMake language file to be included as the last step of any project() command calls that specify <PROJECT-NAME> as the project name. This is intended for injecting custom code into project builds without modifying their source. See Code Injection for a more detailed discussion of files potentially included during a project() call.

Added in version 3.29: This variable can be a semicolon-separated list of CMake language files to be included sequentially. It can also now refer to module names to be found in CMAKE_MODULE_PATH or as a builtin CMake module.

See also the CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE, CMAKE_PROJECT_INCLUDE, CMAKE_PROJECT_INCLUDE_BEFORE, and CMAKE_PROJECT_TOP_LEVEL_INCLUDES variables.

CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE¶

Added in version 3.17.

A CMake language file to be included as the first step of any project() command calls that specify <PROJECT-NAME> as the project name. This is intended for injecting custom code into project builds without modifying their source. See Code Injection for a more detailed discussion of files potentially included during a project() call.

Added in version 3.29: This variable can be a semicolon-separated list of CMake language files to be included sequentially. It can also now refer to module names to be found in CMAKE_MODULE_PATH or as a builtin CMake module.

See also the CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE, CMAKE_PROJECT_INCLUDE, CMAKE_PROJECT_INCLUDE_BEFORE, and CMAKE_PROJECT_TOP_LEVEL_INCLUDES variables.

CMAKE_PROJECT_TOP_LEVEL_INCLUDES¶

Added in version 3.24.

Semicolon-separated list of CMake language files to include as part of the very first project() call. The files will be included immediately after the toolchain file has been read (if one is specified) and platform variables have been set, but before any languages have been enabled. Therefore, language-specific variables, including things like CMAKE_<LANG>_COMPILER, might not be set. See Code Injection for a more detailed discussion of files potentially included during a project() call.

Added in version 3.29: This variable can also now refer to module names to be found in CMAKE_MODULE_PATH or builtin to CMake.

This variable is intended for specifying files that perform one-time setup for the build. It provides an injection point for things like configuring package managers, adding logic the user shares between projects (e.g. defining their own custom build types), and so on. It is primarily for users to add things specific to their environment, but not for specifying the toolchain details (use CMAKE_TOOLCHAIN_FILE for that).

By default, this variable is empty. It is intended to be set by the user.

See also:

CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>¶

Added in version 3.22.

Variable for making find_package() call REQUIRED.

Every non-REQUIRED find_package() call in a project can be turned into REQUIRED by setting the variable CMAKE_REQUIRE_FIND_PACKAGE_<PackageName> to TRUE. This can be used to assert assumptions about build environment and to ensure the build will fail early if they do not hold.

Note that setting this variable to true breaks some commonly used patterns. Multiple calls to find_package() are sometimes used to obtain a different search order to the default. For example, projects can force checking a known path for a particular package first before searching any of the other default search paths:

find_package(something PATHS /some/local/path NO_DEFAULT_PATH)
find_package(something)

In the above, the first call looks for the something package in a specific directory. If CMAKE_REQUIRE_FIND_PACKAGE_something is set to true, then this first call must succeed, otherwise a fatal error occurs. The second call never gets a chance to provide a fall-back to using the default search locations.

A similar pattern is used even by some of CMake's own Find modules to search for a config package first:

find_package(something CONFIG QUIET)
if(NOT something_FOUND)


  # Fall back to searching using typical Find module logic...
endif()

Again, if CMAKE_REQUIRE_FIND_PACKAGE_something is true, the first call must succeed. It effectively means a config package must be found for the dependency, and the Find module logic is never used.

See also the CMAKE_DISABLE_FIND_PACKAGE_<PackageName> variable.

CMAKE_SKIP_INSTALL_ALL_DEPENDENCY¶

Don't make the install target depend on the all target.

By default, the install target depends on the all target. This has the effect, that when make install is invoked or INSTALL is built, first the all target is built, then the installation starts. If CMAKE_SKIP_INSTALL_ALL_DEPENDENCY is set to TRUE, this dependency is not created, so the installation process will start immediately, independent from whether the project has been completely built or not.

See also CMAKE_SKIP_TEST_ALL_DEPENDENCY.

CMAKE_SKIP_TEST_ALL_DEPENDENCY¶

Added in version 3.29.

Control whether the test target depends on the all target.

If this variable is not defined, or is set to TRUE, then the test (or RUN_TESTS) target does not depend on the all (or ALL_BUILD) target. When the test target is built, e.g., via make test, the test process will start immediately, regardless of whether the project has been completely built or not.

If CMAKE_SKIP_TEST_ALL_DEPENDENCY is explicitly set to FALSE, then the test target will depend on the all target. When the test target is built, e.g., via make test, the all target will be built first, and then the tests will run.

See also CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.

CMAKE_STAGING_PREFIX¶

This variable may be set to a path to install to when cross-compiling. This can be useful if the path in CMAKE_SYSROOT is read-only, or otherwise should remain pristine.

The CMAKE_STAGING_PREFIX location is also used as a search prefix by the find_* commands. This can be controlled by setting the CMAKE_FIND_NO_INSTALL_PREFIX variable.

If any RPATH/RUNPATH entries passed to the linker contain the CMAKE_STAGING_PREFIX, the matching path fragments are replaced with the CMAKE_INSTALL_PREFIX.

CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS¶

Added in version 3.8.

This variable contains a list of env vars as a list of tokens with the syntax var=value.

Example:

set(CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS


   "FOO=FOO1\;FOO2\;FOON"


   "BAR=BAR1\;BAR2\;BARN"


   "BAZ=BAZ1\;BAZ2\;BAZN"


   "FOOBAR=FOOBAR1\;FOOBAR2\;FOOBARN"


   "VALID="


   )

In case of malformed variables CMake will fail:

set(CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS


    "THIS_IS_NOT_VALID"


    )

CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE¶

Added in version 3.8.

If this variable evaluates to ON at the end of the top-level CMakeLists.txt file, the Sublime Text 2 extra generator excludes the build tree from the .sublime-project if it is inside the source tree.

CMAKE_SUPPRESS_REGENERATION¶

Added in version 3.12.

If CMAKE_SUPPRESS_REGENERATION is OFF, which is default, then CMake adds a special target on which all other targets depend that checks the build system and optionally re-runs CMake to regenerate the build system when the target specification source changes.

If this variable evaluates to ON at the end of the top-level CMakeLists.txt file, CMake will not add the regeneration target to the build system or perform any build system checks.

CMAKE_SYSROOT¶

Path to pass to the compiler in the --sysroot flag.

The CMAKE_SYSROOT content is passed to the compiler in the --sysroot flag, if supported. The path is also stripped from the RPATH/RUNPATH if necessary on installation. The CMAKE_SYSROOT is also used to prefix paths searched by the find_* commands.

This variable may only be set in a toolchain file specified by the CMAKE_TOOLCHAIN_FILE variable.

See also the CMAKE_SYSROOT_COMPILE and CMAKE_SYSROOT_LINK variables.

CMAKE_SYSROOT_COMPILE¶

Added in version 3.9.

Path to pass to the compiler in the --sysroot flag when compiling source files. This is the same as CMAKE_SYSROOT but is used only for compiling sources and not linking.

This variable may only be set in a toolchain file specified by the CMAKE_TOOLCHAIN_FILE variable.

CMAKE_SYSROOT_LINK¶

Added in version 3.9.

Path to pass to the compiler in the --sysroot flag when linking. This is the same as CMAKE_SYSROOT but is used only for linking and not compiling sources.

This variable may only be set in a toolchain file specified by the CMAKE_TOOLCHAIN_FILE variable.

CMAKE_SYSTEM_APPBUNDLE_PATH¶

Added in version 3.4.

Search path for macOS application bundles used by the find_program(), and find_package() commands. By default it contains the standard directories for the current system. It is not intended to be modified by the project, use CMAKE_APPBUNDLE_PATH for this.

CMAKE_SYSTEM_FRAMEWORK_PATH¶

Added in version 3.4.

Search path for macOS frameworks used by the find_library(), find_package(), find_path(), and find_file() commands. By default it contains the standard directories for the current system. It is not intended to be modified by the project, use CMAKE_FRAMEWORK_PATH for this.

CMAKE_SYSTEM_IGNORE_PATH¶

Semicolon-separated list of directories to be ignored by the various find...() commands.

For find_program(), find_library(), find_file(), and find_path(), any file found in one of the listed directories will be ignored. The listed directories do not apply recursively, so any subdirectories to be ignored must also be explicitly listed. CMAKE_SYSTEM_IGNORE_PATH does not affect the search prefixes used by these four commands. To ignore individual paths under a search prefix (e.g. bin, include, lib, etc.), each path must be listed in CMAKE_SYSTEM_IGNORE_PATH as a full absolute path. CMAKE_SYSTEM_IGNORE_PREFIX_PATH provides a more appropriate way to ignore a whole search prefix.

find_package() is also affected by CMAKE_SYSTEM_IGNORE_PATH, but only for Config mode searches. Any <Name>Config.cmake or <name>-config.cmake file found in one of the specified directories will be ignored. In addition, any search prefix found in CMAKE_SYSTEM_IGNORE_PATH will be skipped for backward compatibility reasons, but new code should prefer to use CMAKE_SYSTEM_IGNORE_PREFIX_PATH to ignore prefixes instead.

Ignoring search locations can be 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.

CMAKE_SYSTEM_IGNORE_PATH is populated by CMake as part of its platform and toolchain setup. Its purpose is to ignore locations containing incompatible binaries meant for the host rather than the target platform. The project or end user should not modify this variable, they should use CMAKE_IGNORE_PATH instead.

See also the following variables:

CMAKE_SYSTEM_IGNORE_PREFIX_PATH¶

Added in version 3.23.

Semicolon-separated list of search prefixes to be ignored by the find_program(), find_library(), find_file(), and find_path() commands. The prefixes are also ignored by the Config mode of the find_package() command (Module mode is unaffected). To ignore specific directories instead, see CMAKE_SYSTEM_IGNORE_PATH.

Ignoring search locations can be 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.

CMAKE_SYSTEM_IGNORE_PREFIX_PATH is populated by CMake as part of its platform and toolchain setup. Its purpose is to ignore locations containing incompatible binaries meant for the host rather than the target platform. The project or end user should not modify this variable, they should use CMAKE_IGNORE_PREFIX_PATH instead.

See also the following variables:

CMAKE_SYSTEM_INCLUDE_PATH¶

Semicolon-separated list of directories specifying a search path for the find_file() and find_path() commands. By default this contains the standard directories for the current system. It is not intended to be modified by the project; use CMAKE_INCLUDE_PATH for this. See also CMAKE_SYSTEM_PREFIX_PATH.

CMAKE_SYSTEM_LIBRARY_PATH¶

Semicolon-separated list of directories specifying a search path for the find_library() command. By default this contains the standard directories for the current system. It is not intended to be modified by the project; use CMAKE_LIBRARY_PATH for this. See also CMAKE_SYSTEM_PREFIX_PATH.

CMAKE_SYSTEM_PREFIX_PATH¶

Semicolon-separated list of directories specifying installation prefixes to be searched by the find_package(), find_program(), find_library(), find_file(), and find_path() commands. Each command will add appropriate subdirectories (like bin, lib, or include) as specified in its own documentation.

By default this contains the system directories for the current system, the CMAKE_INSTALL_PREFIX, and the CMAKE_STAGING_PREFIX. The installation and staging prefixes may be excluded by setting the CMAKE_FIND_NO_INSTALL_PREFIX variable before the first project() invocation.

The system directories that are contained in CMAKE_SYSTEM_PREFIX_PATH are locations that typically include installed software. An example being /usr/local for UNIX based platforms. In addition to standard platform locations, CMake will also add values to CMAKE_SYSTEM_PREFIX_PATH based on environment variables. The environment variables and search locations that CMake uses may evolve over time, as platforms and their conventions also evolve. The following provides an indicative list of environment variables and locations that CMake searches, but they are subject to change:

CMAKE_SYSTEM_PREFIX_PATH is not intended to be modified by the project; use CMAKE_PREFIX_PATH for this.

See also CMAKE_SYSTEM_INCLUDE_PATH, CMAKE_SYSTEM_LIBRARY_PATH, CMAKE_SYSTEM_PROGRAM_PATH, and CMAKE_SYSTEM_IGNORE_PATH.

CMAKE_SYSTEM_PROGRAM_PATH¶

Semicolon-separated list of directories specifying a search path for the find_program() command. By default this contains the standard directories for the current system. It is not intended to be modified by the project; use CMAKE_PROGRAM_PATH for this. See also CMAKE_SYSTEM_PREFIX_PATH.

CMAKE_TLS_CAINFO¶

Specify the default value for the file(DOWNLOAD) and file(UPLOAD) commands' TLS_CAINFO options. It is unset by default.

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

CMAKE_TLS_VERIFY¶

Specify the default value for the file(DOWNLOAD) and file(UPLOAD) commands' TLS_VERIFY options. If this variable is not set, the commands check the CMAKE_TLS_VERIFY environment variable. If neither is set, the default is on.

Changed in version 3.31: The default is on. Previously, the default was off. Users may set the CMAKE_TLS_VERIFY environment variable to 0 to restore the old default.

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

TLS verification can help provide confidence that one is connecting to the desired server. When downloading known content, one should also use file hashes to verify it.

set(CMAKE_TLS_VERIFY TRUE)

CMAKE_TLS_VERSION¶

Added in version 3.30.

Specify the default value for the file(DOWNLOAD) and file(UPLOAD) commands' TLS_VERSION option. If this variable is not set, the commands check the CMAKE_TLS_VERSION environment variable. If neither is set, the default is TLS 1.2.

Changed in version 3.31: The default is TLS 1.2. Previously, no minimum version was enforced by default.

The value may be one of:

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

CMAKE_USER_MAKE_RULES_OVERRIDE¶

Specify a CMake file that overrides platform information.

CMake loads the specified file while enabling support for each language from either the project() or enable_language() commands. It is loaded after CMake's builtin compiler and platform information modules have been loaded but before the information is used. The file may set platform information variables to override CMake's defaults. See CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG> for the language-specific version of this variable.

This feature is intended for use only in overriding information variables that must be set before CMake builds its first test project to check that the compiler for a language works. It should not be used to load a file in cases that a normal include() will work. Use it only as a last resort for behavior that cannot be achieved any other way. For example, one may set the CMAKE_C_FLAGS_INIT variable to change the default value used to initialize the CMAKE_C_FLAGS variable before it is cached. The override file should NOT be used to set anything that could be set after languages are enabled, such as variables like CMAKE_RUNTIME_OUTPUT_DIRECTORY that affect the placement of binaries. Information set in the file will be used for try_compile() and try_run() builds too.

CMAKE_WARN_DEPRECATED¶

Whether to issue warnings for deprecated functionality.

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

When running cmake(1), this option can be enabled with the -Wdeprecated option, or disabled with the -Wno-deprecated option.

CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION¶

Ask cmake_install.cmake script to warn each time a file with absolute INSTALL DESTINATION is encountered.

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 warning messages from the script.

CMAKE_XCODE_GENERATE_SCHEME¶

Added in version 3.9.

If enabled, the Xcode generator will generate schema files. These are useful to invoke analyze, archive, build-for-testing and test actions from the command line.

This variable initializes the XCODE_GENERATE_SCHEME target property on all targets.

CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY¶

Added in version 3.11.

If enabled, the Xcode generator will generate only a single Xcode project file for the topmost project() command instead of generating one for every project() command.

This could be useful to speed up the CMake generation step for large projects and to work-around a bug in the ZERO_CHECK logic.

CMAKE_XCODE_LINK_BUILD_PHASE_MODE¶

Added in version 3.19.

This variable is used to initialize the XCODE_LINK_BUILD_PHASE_MODE property on targets. It affects the methods that the Xcode generator uses to link different kinds of libraries. Its default value is NONE.

CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER¶

Added in version 3.13.

Whether to enable Address Sanitizer in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_ADDRESS_SANITIZER property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN¶

Added in version 3.13.

Whether to enable Detect use of stack after return in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING¶

Added in version 3.16.

Whether to enable Allow debugging when using document Versions Browser in the Options section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER¶

Added in version 3.13.

Whether to disable the Main Thread Checker in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS¶

Added in version 3.13.

Whether to enable Dynamic Library Loads in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE¶

Added in version 3.13.

Whether to enable Dynamic Linker API usage in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_ENABLE_GPU_API_VALIDATION¶

Added in version 3.25.

Property value for Metal: API Validation in the Options section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_ENABLE_GPU_API_VALIDATION property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE¶

Added in version 3.23.

Property value for GPU Frame Capture in the Options section of the generated Xcode scheme. Example values are Metal and Disabled.

This variable initializes the XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION¶

Added in version 3.25.

Property value for Metal: Shader Validation in the Options section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_ENVIRONMENT¶

Added in version 3.17.

Specify environment variables that should be added to the Arguments section of the generated Xcode scheme.

If set to a list of environment variables and values of the form MYVAR=value those environment variables will be added to the scheme.

This variable initializes the XCODE_SCHEME_ENVIRONMENT property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_GUARD_MALLOC¶

Added in version 3.13.

Whether to enable Guard Malloc in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_GUARD_MALLOC property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_LAUNCH_CONFIGURATION¶

Added in version 3.25.

Set the build configuration to run the target.

This variable initializes the XCODE_SCHEME_LAUNCH_CONFIGURATION property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_LAUNCH_MODE¶

Added in version 3.25.

Property value for Launch in the Info section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_LAUNCH_MODE property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP¶

Added in version 3.13.

Whether to enable the Main Thread Checker option Pause on issues in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES¶

Added in version 3.13.

Whether to enable Malloc Guard Edges in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_MALLOC_GUARD_EDGES property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE¶

Added in version 3.13.

Whether to enable Malloc Scribble in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_MALLOC_SCRIBBLE property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_MALLOC_STACK¶

Added in version 3.13.

Whether to enable Malloc Stack in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_MALLOC_STACK property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_THREAD_SANITIZER¶

Added in version 3.13.

Whether to enable Thread Sanitizer in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_THREAD_SANITIZER property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP¶

Added in version 3.13.

Whether to enable Thread Sanitizer - Pause on issues in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_THREAD_SANITIZER_STOP property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER¶

Added in version 3.13.

Whether to enable Undefined Behavior Sanitizer in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP¶

Added in version 3.13.

Whether to enable Undefined Behavior Sanitizer option Pause on issues in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_WORKING_DIRECTORY¶

Added in version 3.17.

Specify the Working Directory of the Run and Profile actions in the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_WORKING_DIRECTORY property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS¶

Added in version 3.13.

Whether to enable Zombie Objects in the Diagnostics section of the generated Xcode scheme.

This variable initializes the XCODE_SCHEME_ZOMBIE_OBJECTS property on all targets.

Please refer to the XCODE_GENERATE_SCHEME target property documentation to see all Xcode schema related properties.

CMAKE_XCODE_XCCONFIG¶

Added in version 3.24.

If set, the Xcode generator will register the specified file as a global XCConfig file. For target-level XCConfig files see the XCODE_XCCONFIG target property.

This feature is intended to ease migration from native Xcode projects to CMake projects.

Contents of CMAKE_XCODE_XCCONFIG may use generator expressions.

<PackageName>_ROOT¶

Added in version 3.12.

Calls to find_package(<PackageName>) will search in prefixes specified by the <PackageName>_ROOT CMake variable, where <PackageName> is the (case-preserved) name given to the find_package() call and _ROOT is literal. For example, find_package(Foo) will search prefixes specified in the Foo_ROOT CMake variable (if set). See policy CMP0074.

This variable may hold a single prefix or a semicolon-separated list of multiple prefixes.

See also the <PackageName>_ROOT environment variable.

ANDROID¶

Added in version 3.7.

Set to 1 when the target system (CMAKE_SYSTEM_NAME) is Android.

APPLE¶

Set to True when the target system is an Apple platform (macOS, iOS, tvOS, visionOS or watchOS).

BORLAND¶

True if the Borland compiler is being used.

This is set to true if the Borland compiler is being used.

BSD¶

Added in version 3.25.

Set to a string value when the target system is BSD. This value can be one of the following: DragonFlyBSD, FreeBSD, OpenBSD, or NetBSD.

CMAKE_ANDROID_NDK_VERSION¶

Added in version 3.20.

When Cross Compiling for Android with the NDK and using an Android NDK version 11 or higher, this variable is provided by CMake to report the NDK version number.

CMAKE_CL_64¶

Discouraged. Use CMAKE_SIZEOF_VOID_P instead.

Set to a true value when using a Microsoft Visual Studio cl compiler that targets a 64-bit architecture.

CMAKE_COMPILER_2005¶

Using the Visual Studio 2005 compiler from Microsoft

Set to true when using the Visual Studio 2005 compiler from Microsoft.

CMAKE_HOST_APPLE¶

True for Apple macOS operating systems.

Set to true when the host system is Apple macOS.

CMAKE_HOST_BSD¶

Added in version 3.25.

Set to a string value when the host system is BSD. This value can be one of the following: DragonFlyBSD, FreeBSD, OpenBSD, or NetBSD.

CMAKE_HOST_EXECUTABLE_SUFFIX¶

Added in version 3.31.

The suffix for executables on the host platform. This may differ from the suffix for the target platform, CMAKE_EXECUTABLE_SUFFIX.

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

See also CMAKE_EXECUTABLE_SUFFIX.

CMAKE_HOST_LINUX¶

Added in version 3.25.

Set to true when the host system is Linux.

CMAKE_HOST_SOLARIS¶

Added in version 3.6.

True for Oracle Solaris operating systems.

Set to true when the host system is Oracle Solaris.

CMAKE_HOST_SYSTEM¶

Composite Name of OS CMake is being run on.

This variable is the composite of CMAKE_HOST_SYSTEM_NAME and CMAKE_HOST_SYSTEM_VERSION, e.g. ${CMAKE_HOST_SYSTEM_NAME}-${CMAKE_HOST_SYSTEM_VERSION}. If CMAKE_HOST_SYSTEM_VERSION is not set, then this variable is the same as CMAKE_HOST_SYSTEM_NAME.

CMAKE_HOST_SYSTEM_NAME¶

Name of the OS CMake is running on.

On systems that have the uname command, this variable is set to the output of uname -s. Linux, Windows, and Darwin for macOS are the values found on the big three operating systems.

For a list of possible values, see CMAKE_SYSTEM_NAME.

CMAKE_HOST_SYSTEM_PROCESSOR¶

The name of the CPU CMake is running on.

Windows Platforms¶

On Windows, this variable is set to the value of the environment variable PROCESSOR_ARCHITECTURE.

Unix Platforms¶

On systems that support uname, this variable is set to the output of:

macOS Platforms¶

The value of uname -m is used by default.

On Apple Silicon hosts, the architecture printed by uname -m may vary based on CMake's own architecture and that of the invoking process tree.

Added in version 3.19.2: On Apple Silicon hosts:

CMAKE_HOST_SYSTEM_VERSION¶

The OS version CMake is running on.

A numeric version string for the system. On systems that support uname, this variable is set to the output of uname -r. On other systems this is set to major-minor version numbers.

CMAKE_HOST_UNIX¶

True for UNIX and UNIX like operating systems.

Set to true when the host system is UNIX or UNIX like (i.e. APPLE and CYGWIN).

CMAKE_HOST_WIN32¶

True if the host system is running Windows, including Windows 64-bit and MSYS.

Set to false on Cygwin.

CMAKE_LIBRARY_ARCHITECTURE¶

Target architecture library directory name, if detected.

This is the value of CMAKE_<LANG>_LIBRARY_ARCHITECTURE as detected for one of the enabled languages.

CMAKE_LIBRARY_ARCHITECTURE_REGEX¶

Regex matching possible target architecture library directory names.

This is used to detect CMAKE_<LANG>_LIBRARY_ARCHITECTURE from the implicit linker search path by matching the <arch> name.

CMAKE_OBJECT_PATH_MAX¶

Maximum object file full-path length allowed by native build tools.

CMake computes for every source file an object file name that is unique to the source file and deterministic with respect to the full path to the source file. This allows multiple source files in a target to share the same name if they lie in different directories without rebuilding when one is added or removed. However, it can produce long full paths in a few cases, so CMake shortens the path using a hashing scheme when the full path to an object file exceeds a limit. CMake has a built-in limit for each platform that is sufficient for common tools, but some native tools may have a lower limit. This variable may be set to specify the limit explicitly. The value must be an integer no less than 128.

CMAKE_SYSTEM¶

Composite name of operating system CMake is compiling for.

This variable is the composite of CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_VERSION, e.g. ${CMAKE_SYSTEM_NAME}-${CMAKE_SYSTEM_VERSION}. If CMAKE_SYSTEM_VERSION is not set, then this variable is the same as CMAKE_SYSTEM_NAME.

CMAKE_SYSTEM_NAME¶

The name of the operating system for which CMake is to build. See the CMAKE_SYSTEM_VERSION variable for the OS version.

Note that CMAKE_SYSTEM_NAME is not set to anything by default when running in script mode, since it's not building anything.

System Name for Host Builds¶

CMAKE_SYSTEM_NAME is by default set to the same value as the CMAKE_HOST_SYSTEM_NAME variable so that the build targets the host system.

System Name for Cross Compiling¶

CMAKE_SYSTEM_NAME may be set explicitly when first configuring a new build tree in order to enable cross compiling. In this case the CMAKE_SYSTEM_VERSION variable must also be set explicitly.

System Names Known to CMake¶

The following is a list of possible values, each associated with corresponding operating systems or environments.

Platform-specific notes:

CMAKE_SYSTEM_PROCESSOR¶

When not cross-compiling, this variable has the same value as the CMAKE_HOST_SYSTEM_PROCESSOR variable. In many cases, this will correspond to the target architecture for the build, but this is not guaranteed. (E.g. on Windows, the host may be AMD64 even when using a MSVC cl compiler with a 32-bit target.)

When cross-compiling, a CMAKE_TOOLCHAIN_FILE should set the CMAKE_SYSTEM_PROCESSOR variable to match target architecture that it specifies (via CMAKE_<LANG>_COMPILER and perhaps CMAKE_<LANG>_COMPILER_TARGET).

CMAKE_SYSTEM_VERSION¶

The version of the operating system for which CMake is to build. See the CMAKE_SYSTEM_NAME variable for the OS name.

System Version for Host Builds¶

When the CMAKE_SYSTEM_NAME variable takes its default value then CMAKE_SYSTEM_VERSION is by default set to the same value as the CMAKE_HOST_SYSTEM_VERSION variable so that the build targets the host system version.

In the case of a host build then CMAKE_SYSTEM_VERSION may be set explicitly when first configuring a new build tree in order to enable targeting the build for a different version of the host operating system than is actually running on the host. This is allowed and not considered cross compiling so long as the binaries built for the specified OS version can still run on the host.

System Version for Cross Compiling¶

When the CMAKE_SYSTEM_NAME variable is set explicitly to enable cross compiling then the value of CMAKE_SYSTEM_VERSION must also be set explicitly to specify the target system version.

CYGWIN¶

True for Cygwin.

Set to true when using Cygwin.

GHSMULTI¶

Added in version 3.3.

1 when using Green Hills MULTI generator.

Also, Set to 1 when the target system is a Green Hills platform (i.e. When CMAKE_SYSTEM_NAME is GHS-MULTI).

IOS¶

Added in version 3.14.

Set to 1 when the target system (CMAKE_SYSTEM_NAME) is iOS.

LINUX¶

Added in version 3.25.

Set to true when the target system is Linux.

MINGW¶

Added in version 3.2.

Set to a true value when at least one language is enabled with a compiler targeting the GNU ABI on Windows (MinGW).

Otherwise, this variable is not set by CMake.

MSVC¶

Set to true when the compiler is some version of Microsoft Visual C++ or another compiler simulating the Visual C++ cl command-line syntax.

See also the MSVC_VERSION variable.

MSVC_IDE¶

True when using the Microsoft Visual C++ IDE.

Set to true when the target platform is the Microsoft Visual C++ IDE, as opposed to the command line compiler.

NOTE:

MSVC_TOOLSET_VERSION¶

Added in version 3.12.

The toolset version of Microsoft Visual C/C++ being used if any. If MSVC-like is being used, this variable is set based on the version of the compiler as given by the MSVC_VERSION variable.

Known toolset version numbers are:

80        = VS 2005 (8.0)
90        = VS 2008 (9.0)
100       = VS 2010 (10.0)
110       = VS 2012 (11.0)
120       = VS 2013 (12.0)
140       = VS 2015 (14.0)
141       = VS 2017 (15.0)
142       = VS 2019 (16.0)
143       = VS 2022 (17.0)

Compiler versions newer than those known to CMake will be reported as the latest known toolset version.

See also the MSVC_VERSION variable.

MSVC_VERSION¶

The version of Microsoft Visual C/C++ being used if any. If a compiler simulating Visual C++ is being used, this variable is set to the toolset version simulated as given by the _MSC_VER preprocessor definition.

Known version numbers are:

1200      = VS  6.0
1300      = VS  7.0
1310      = VS  7.1
1400      = VS  8.0 (v80 toolset)
1500      = VS  9.0 (v90 toolset)
1600      = VS 10.0 (v100 toolset)
1700      = VS 11.0 (v110 toolset)
1800      = VS 12.0 (v120 toolset)
1900      = VS 14.0 (v140 toolset)
1910-1919 = VS 15.0 (v141 toolset)
1920-1929 = VS 16.0 (v142 toolset)
1930-1949 = VS 17.0 (v143 toolset)

See also the CMAKE_<LANG>_COMPILER_VERSION and MSVC_TOOLSET_VERSION variable.

MSYS¶

Added in version 3.14.

True when using the MSYS Makefiles generator.

UNIX¶

Set to True when the target system is UNIX or UNIX-like (e.g. APPLE and CYGWIN). The CMAKE_SYSTEM_NAME variable should be queried if a more specific understanding of the target system is required.

WASI¶

Added in version 3.31.

Set to 1 when the target system is WebAssembly System Interface (CMAKE_SYSTEM_NAME is WASI).

WIN32¶

Set to True when the target system is Windows, including Win64.

WINCE¶

Added in version 3.1.

True when the CMAKE_SYSTEM_NAME variable is set to WindowsCE.

WINDOWS_PHONE¶

Added in version 3.1.

True when the CMAKE_SYSTEM_NAME variable is set to WindowsPhone.

WINDOWS_STORE¶

Added in version 3.1.

True when the CMAKE_SYSTEM_NAME variable is set to WindowsStore.

XCODE¶

Added in version 3.7.

True when using Xcode generator.

XCODE_VERSION¶

Version of Xcode (Xcode generator only).

Under the Xcode generator, this is the version of Xcode as specified in Xcode.app/Contents/version.plist (such as 3.1.2).

CMAKE_ADSP_ROOT¶

Added in version 3.24.

When Cross Compiling for ADSP SHARC/Blackfin, this variable holds the absolute path to the latest CCES or VDSP++ install. The directory is expected to contain the cc21k.exe and ccblkfn.exe compilers. This will be set automatically if a default install of CCES or VDSP++ can be found.

See also the ADSP_ROOT environment variable.

CMAKE_AIX_SHARED_LIBRARY_ARCHIVE¶

Added in version 3.31.

On AIX, enable creation of shared library archives.

This variable initializes the AIX_SHARED_LIBRARY_ARCHIVE target property on SHARED library targets as they are created by add_library(). See that target property for details.

CMAKE_AIX_EXPORT_ALL_SYMBOLS¶

Added in version 3.17.

Default value for AIX_EXPORT_ALL_SYMBOLS target property. This variable is used to initialize the property on each target as it is created.

CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS¶

Added in version 3.4.

Default value for the ANDROID_ANT_ADDITIONAL_OPTIONS target property. See that target property for additional information.

CMAKE_ANDROID_API¶

Added in version 3.1.

When Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition, this variable may be set to specify the default value for the ANDROID_API target property. See that target property for additional information.

When Cross Compiling for Android, the CMAKE_SYSTEM_VERSION variable represents the Android API version number targeted. For historical reasons, if a toolchain file sets CMAKE_ANDROID_API, but not CMAKE_SYSTEM_VERSION, the latter will be initialized using the former.

CMAKE_ANDROID_API_MIN¶

Added in version 3.2.

Default value for the ANDROID_API_MIN target property. See that target property for additional information.

CMAKE_ANDROID_ARCH¶

Added in version 3.4.

When Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition, this variable may be set to specify the default value for the ANDROID_ARCH target property. See that target property for additional information.

Otherwise, when Cross Compiling for Android, this variable provides the name of the Android architecture corresponding to the value of the CMAKE_ANDROID_ARCH_ABI variable. The architecture name may be one of:

CMAKE_ANDROID_ARCH_ABI¶

Added in version 3.7.

When Cross Compiling for Android, this variable specifies the target architecture and ABI to be used. Valid values are:

See also the CMAKE_ANDROID_ARM_MODE and CMAKE_ANDROID_ARM_NEON variables.

CMAKE_ANDROID_ARM_MODE¶

Added in version 3.7.

When Cross Compiling for Android and CMAKE_ANDROID_ARCH_ABI is set to one of the armeabi architectures, set CMAKE_ANDROID_ARM_MODE to ON to target 32-bit ARM processors (-marm). Otherwise, the default is to target the 16-bit Thumb processors (-mthumb).

CMAKE_ANDROID_ARM_NEON¶

Added in version 3.7.

When Cross Compiling for Android and CMAKE_ANDROID_ARCH_ABI is set to armeabi-v7a set CMAKE_ANDROID_ARM_NEON to ON to target ARM NEON devices.

CMAKE_ANDROID_ASSETS_DIRECTORIES¶

Added in version 3.4.

Default value for the ANDROID_ASSETS_DIRECTORIES target property. See that target property for additional information.

CMAKE_ANDROID_EXCEPTIONS¶

Added in version 3.20.

When Cross Compiling for Android with the NDK, this variable may be set to specify whether exceptions are enabled.

CMAKE_ANDROID_GUI¶

Added in version 3.1.

Default value for the ANDROID_GUI target property of executables. See that target property for additional information.

CMAKE_ANDROID_JAR_DEPENDENCIES¶

Added in version 3.4.

Default value for the ANDROID_JAR_DEPENDENCIES target property. See that target property for additional information.

CMAKE_ANDROID_JAR_DIRECTORIES¶

Added in version 3.4.

Default value for the ANDROID_JAR_DIRECTORIES target property. See that target property for additional information.

CMAKE_ANDROID_JAVA_SOURCE_DIR¶

Added in version 3.4.

Default value for the ANDROID_JAVA_SOURCE_DIR target property. See that target property for additional information.

CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES¶

Added in version 3.4.

Default value for the ANDROID_NATIVE_LIB_DEPENDENCIES target property. See that target property for additional information.

CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES¶

Added in version 3.4.

Default value for the ANDROID_NATIVE_LIB_DIRECTORIES target property. See that target property for additional information.

CMAKE_ANDROID_NDK¶

Added in version 3.7.

When Cross Compiling for Android with the NDK, this variable holds the absolute path to the root directory of the NDK. The directory must contain a platforms subdirectory holding the android-<api> directories.

CMAKE_ANDROID_NDK_DEPRECATED_HEADERS¶

Added in version 3.9.

When Cross Compiling for Android with the NDK, this variable may be set to specify whether to use the deprecated per-api-level headers instead of the unified headers.

If not specified, the default will be false if using a NDK version that provides the unified headers and true otherwise.

CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG¶

Added in version 3.7.1.

When Cross Compiling for Android with the NDK, this variable provides the NDK's "host tag" used to construct the path to prebuilt toolchains that run on the host.

CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION¶

Added in version 3.7.

When Cross Compiling for Android with the NDK, this variable may be set to specify the version of the toolchain to be used as the compiler.

On NDK r19 or above, this variable must be unset or set to clang.

On NDK r18 or below, this variable must be set to one of these forms:

A toolchain of the requested version will be selected automatically to match the ABI named in the CMAKE_ANDROID_ARCH_ABI variable.

If not specified, the default will be a value that selects the latest available GCC toolchain.

CMAKE_ANDROID_PROCESS_MAX¶

Added in version 3.4.

Default value for the ANDROID_PROCESS_MAX target property. See that target property for additional information.

CMAKE_ANDROID_PROGUARD¶

Added in version 3.4.

Default value for the ANDROID_PROGUARD target property. See that target property for additional information.

CMAKE_ANDROID_PROGUARD_CONFIG_PATH¶

Added in version 3.4.

Default value for the ANDROID_PROGUARD_CONFIG_PATH target property. See that target property for additional information.

CMAKE_ANDROID_RTTI¶

Added in version 3.20.

When Cross Compiling for Android with the NDK, this variable may be set to specify whether RTTI is enabled.

CMAKE_ANDROID_SECURE_PROPS_PATH¶

Added in version 3.4.

Default value for the ANDROID_SECURE_PROPS_PATH target property. See that target property for additional information.

CMAKE_ANDROID_SKIP_ANT_STEP¶

Added in version 3.4.

Default value for the ANDROID_SKIP_ANT_STEP target property. See that target property for additional information.

CMAKE_ANDROID_STANDALONE_TOOLCHAIN¶

Added in version 3.7.

When Cross Compiling for Android with a Standalone Toolchain, this variable holds the absolute path to the root directory of the toolchain. The specified directory must contain a sysroot subdirectory.

CMAKE_ANDROID_STL_TYPE¶

Added in version 3.4.

When Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition, this variable may be set to specify the default value for the ANDROID_STL_TYPE target property. See that target property for additional information.

When Cross Compiling for Android with the NDK, this variable may be set to specify the STL variant to be used. The value may be one of:

The default value is gnustl_static on NDK versions that provide it and otherwise c++_static. Note that this default differs from the native NDK build system because CMake may be used to build projects for Android that are not natively implemented for it and use the C++ standard library.

CMAKE_APPLE_SILICON_PROCESSOR¶

Added in version 3.19.2.

On Apple Silicon hosts running macOS, set this variable to tell CMake what architecture to use for CMAKE_HOST_SYSTEM_PROCESSOR. The value must be either arm64 or x86_64.

The value of this variable should never be modified by project code. It is meant to be set as a cache entry provided by the user, e.g. via -DCMAKE_APPLE_SILICON_PROCESSOR=....

See also the CMAKE_APPLE_SILICON_PROCESSOR environment variable.

CMAKE_ARCHIVE_OUTPUT_DIRECTORY¶

Where to put all the ARCHIVE target files when built.

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

CMAKE_ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>¶

Added in version 3.3.

Where to put all the ARCHIVE target files when built for a specific configuration.

This variable is used to initialize the ARCHIVE_OUTPUT_DIRECTORY_<CONFIG> property on all the targets. See that target property for additional information.

CMAKE_AUTOGEN_BETTER_GRAPH_MULTI_CONFIG¶

Added in version 3.29.

This variable is used to initialize the AUTOGEN_BETTER_GRAPH_MULTI_CONFIG property on all targets as they are created. See that target property for additional information.

By default CMAKE_AUTOGEN_BETTER_GRAPH_MULTI_CONFIG is unset.

CMAKE_AUTOGEN_COMMAND_LINE_LENGTH_MAX¶

Added in version 3.29.

Command line length limit for autogen targets, i.e. moc or uic, that triggers the use of response files on Windows instead of passing all arguments to the command line.

By default CMAKE_AUTOGEN_COMMAND_LINE_LENGTH_MAX is unset.

CMAKE_AUTOGEN_ORIGIN_DEPENDS¶

Added in version 3.14.

Switch for forwarding origin target dependencies to the corresponding The <ORIGIN>_autogen target targets.

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

By default CMAKE_AUTOGEN_ORIGIN_DEPENDS is ON.

CMAKE_AUTOGEN_PARALLEL¶

Added in version 3.11.

Number of parallel moc or uic processes to start when using AUTOMOC and AUTOUIC.

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

By default CMAKE_AUTOGEN_PARALLEL is unset.

CMAKE_AUTOGEN_USE_SYSTEM_INCLUDE¶

Added in version 3.27.

This variable is used to initialize the AUTOGEN_USE_SYSTEM_INCLUDE property on all targets as they are created. See that target property for additional information.

By default CMAKE_AUTOGEN_USE_SYSTEM_INCLUDE is unset.

CMAKE_AUTOGEN_VERBOSE¶

Added in version 3.13.

Sets the verbosity of AUTOMOC, AUTOUIC and AUTORCC. A positive integer value or a true boolean value lets the AUTO* generators output additional processing information.

Setting CMAKE_AUTOGEN_VERBOSE has the same effect as setting the VERBOSE environment variable during generation (e.g. by calling make VERBOSE=1). The extra verbosity is limited to the AUTO* generators though.

By default CMAKE_AUTOGEN_VERBOSE is unset.

CMAKE_AUTOMOC¶

Whether to handle moc automatically for Qt targets.

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

CMAKE_AUTOMOC_COMPILER_PREDEFINES¶

Added in version 3.10.

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

By default it is ON.

CMAKE_AUTOMOC_DEPEND_FILTERS¶

Added in version 3.9.

Filter definitions used by CMAKE_AUTOMOC to extract file names from source code as additional dependencies for the moc file.

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

By default it is empty.

CMAKE_AUTOMOC_MACRO_NAMES¶

Added in version 3.10.

Semicolon-separated list list of macro names used by CMAKE_AUTOMOC to determine if a C++ file needs to be processed by moc.

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

The default value is Q_OBJECT;Q_GADGET;Q_NAMESPACE;Q_NAMESPACE_EXPORT.

Example¶

Let CMake know that source files that contain CUSTOM_MACRO must be moc processed as well:

set(CMAKE_AUTOMOC ON)
list(APPEND CMAKE_AUTOMOC_MACRO_NAMES "CUSTOM_MACRO")

CMAKE_AUTOMOC_MOC_OPTIONS¶

Additional options for moc when using CMAKE_AUTOMOC.

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

CMAKE_AUTOMOC_PATH_PREFIX¶

Added in version 3.16.

Whether to generate the -p path prefix option for moc on AUTOMOC enabled Qt targets.

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

The default value is OFF.

CMAKE_AUTOMOC_EXECUTABLE¶

Added in version 3.27.

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

By default it is empty.

CMAKE_AUTORCC¶

Whether to handle rcc automatically for Qt targets.

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

CMAKE_AUTORCC_OPTIONS¶

Additional options for rcc when using CMAKE_AUTORCC.

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

EXAMPLE¶

# ...
set(CMAKE_AUTORCC_OPTIONS "--compress;9")
# ...

CMAKE_AUTORCC_EXECUTABLE¶

Added in version 3.27.

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

By default it is empty.

CMAKE_AUTOUIC¶

Whether to handle uic automatically for Qt targets.

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

CMAKE_AUTOUIC_OPTIONS¶

Additional options for uic when using CMAKE_AUTOUIC.

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

EXAMPLE¶

# ...
set_property(CMAKE_AUTOUIC_OPTIONS "--no-protection")
# ...

CMAKE_AUTOUIC_SEARCH_PATHS¶

Added in version 3.9.

Search path list used by CMAKE_AUTOUIC to find included .ui files.

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

By default it is empty.

CMAKE_AUTOUIC_EXECUTABLE¶

Added in version 3.27.

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

By default it is empty.

CMAKE_BUILD_RPATH¶

Added in version 3.8.

Semicolon-separated list specifying runtime path (RPATH) entries to add to binaries linked in the build tree (for platforms that support it). The entries will not be used for binaries in the install tree. See also the CMAKE_INSTALL_RPATH variable.

This is used to initialize the BUILD_RPATH target property for all targets.

CMAKE_BUILD_RPATH_USE_ORIGIN¶

Added in version 3.14.

Whether to use relative paths for the build RPATH.

This is used to initialize the BUILD_RPATH_USE_ORIGIN target property for all targets, see that property for more details.

CMAKE_BUILD_WITH_INSTALL_NAME_DIR¶

Added in version 3.9.

Whether to use INSTALL_NAME_DIR on targets in the build tree.

This variable is used to initialize the BUILD_WITH_INSTALL_NAME_DIR property on all targets.

CMAKE_BUILD_WITH_INSTALL_RPATH¶

Use the install path for the RPATH.

Normally CMake uses the build tree for the RPATH when building executables etc on systems that use RPATH. When the software is installed the executables etc are relinked by CMake to have the install RPATH. If this variable is set to true then the software is always built with the install path for the RPATH and does not need to be relinked when installed.

This is used to initialize the BUILD_WITH_INSTALL_RPATH target property for all targets.

CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY¶

Added in version 3.1.

Output directory for MS debug symbol .pdb files generated by the compiler while building source files.

This variable is used to initialize the COMPILE_PDB_OUTPUT_DIRECTORY property on all the targets.

CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>¶

Added in version 3.1.

Per-configuration output directory for MS debug symbol .pdb files generated by the compiler while building source files.

This is a per-configuration version of CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY. This variable is used to initialize the COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG> property on all the targets.

CMAKE_COMPILE_WARNING_AS_ERROR¶

Added in version 3.24.

Specify whether to treat warnings on compile as errors.

This variable is used to initialize the COMPILE_WARNING_AS_ERROR property on all the targets.

CMAKE_<CONFIG>_POSTFIX¶

Default filename postfix for libraries under configuration <CONFIG>.

When a non-executable target is created its <CONFIG>_POSTFIX target property is initialized with the value of this variable if it is set.

CMAKE_CROSS_CONFIGS¶

Added in version 3.17.

Specifies a semicolon-separated list of configurations available from all build-<Config>.ninja files in the Ninja Multi-Config generator. This variable activates cross-config mode. Targets from each config specified in this variable can be built from any build-<Config>.ninja file. Custom commands will use the configuration native to build-<Config>.ninja. If it is set to all, all configurations from CMAKE_CONFIGURATION_TYPES are cross-configs. If it is not specified, or empty, each build-<Config>.ninja file will only contain build rules for its own configuration.

The value of this variable must be a subset of CMAKE_CONFIGURATION_TYPES.

CMAKE_CTEST_ARGUMENTS¶

Added in version 3.17.

Set this to a semicolon-separated list of command-line arguments to pass to ctest(1) when running tests through the test (or RUN_TESTS) target of the generated build system.

CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS¶

Added in version 3.16.

Default value for CUDA_RESOLVE_DEVICE_SYMBOLS target property when defined. By default this variable is not defined.

This variable is used to initialize the property on each target as it is created.

CMAKE_CUDA_RUNTIME_LIBRARY¶

Added in version 3.17.

Select the CUDA runtime library for use when compiling and linking CUDA. This variable is used to initialize the CUDA_RUNTIME_LIBRARY property on all targets as they are created.

The allowed case insensitive values are:

Contents of CMAKE_CUDA_RUNTIME_LIBRARY may use generator expressions.

If this variable is not set then the CUDA_RUNTIME_LIBRARY target property will not be set automatically. If that property is not set then CMake uses an appropriate default value based on the compiler to select the CUDA runtime library.

NOTE:

CMAKE_CUDA_SEPARABLE_COMPILATION¶

Added in version 3.11.

Default value for CUDA_SEPARABLE_COMPILATION target property. This variable is used to initialize the property on each target as it is created.

CMAKE_CXX_MODULE_STD¶

Added in version 3.30.

Whether to add utility targets as dependencies to targets with at least cxx_std_23 or not.

NOTE:

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

CMAKE_CXX_SCAN_FOR_MODULES¶

Added in version 3.28.

Whether to scan C++ source files for module dependencies.

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

CMAKE_DEBUG_POSTFIX¶

See variable CMAKE_<CONFIG>_POSTFIX.

This variable is a special case of the more-general CMAKE_<CONFIG>_POSTFIX variable for the DEBUG configuration.

CMAKE_DEFAULT_BUILD_TYPE¶

Added in version 3.17.

Specifies the configuration to use by default in a build.ninja file in the Ninja Multi-Config generator. If this variable is specified, build.ninja uses build rules from build-<Config>.ninja by default. All custom commands are executed with this configuration. If the variable is not specified, the first item from CMAKE_CONFIGURATION_TYPES is used instead.

The value of this variable must be one of the items from CMAKE_CONFIGURATION_TYPES.

CMAKE_DEFAULT_CONFIGS¶

Added in version 3.17.

Specifies a semicolon-separated list of configurations to build for a target in build.ninja if no :<Config> suffix is specified in the Ninja Multi-Config generator. If it is set to all, all configurations from CMAKE_CROSS_CONFIGS are used. If it is not specified, it defaults to CMAKE_DEFAULT_BUILD_TYPE.

For example, if you set CMAKE_DEFAULT_BUILD_TYPE to Release, but set CMAKE_DEFAULT_CONFIGS to Debug or all, all <target> aliases in build.ninja will resolve to <target>:Debug or <target>:all, but custom commands will still use the Release configuration.

The value of this variable must be a subset of CMAKE_CROSS_CONFIGS or be the same as CMAKE_DEFAULT_BUILD_TYPE. It must not be specified if CMAKE_DEFAULT_BUILD_TYPE or CMAKE_CROSS_CONFIGS is not used.

CMAKE_DEPENDS_USE_COMPILER¶

Added in version 3.20.

For the Makefile Generators, source dependencies are now, for a selection of compilers, generated by the compiler itself. By defining this variable with value FALSE, you can restore the legacy behavior (i.e. using CMake for dependencies discovery).

CMAKE_DISABLE_PRECOMPILE_HEADERS¶

Added in version 3.16.

Default value for DISABLE_PRECOMPILE_HEADERS of targets.

By default CMAKE_DISABLE_PRECOMPILE_HEADERS is OFF.

CMAKE_DLL_NAME_WITH_SOVERSION¶

Added in version 3.27.

This variable is used to initialize the DLL_NAME_WITH_SOVERSION property on shared library targets for the Windows platform, which is selected when the WIN32 variable is set.

See this target property for additional information.

Please note that setting this variable has no effect if versioned filenames are globally disabled with the CMAKE_PLATFORM_NO_VERSIONED_SONAME variable.

CMAKE_ENABLE_EXPORTS¶

Added in version 3.4.

Specify whether executables export symbols for loadable modules.

This variable is used to initialize the ENABLE_EXPORTS target property for executable targets when they are created by calls to the add_executable() command. See the property documentation for details.

This variable has been superseded by the CMAKE_EXECUTABLE_ENABLE_EXPORTS variable. It is provided for backward compatibility with older CMake code, but should not be used in new projects.

CMAKE_EXECUTABLE_ENABLE_EXPORTS¶

Added in version 3.27.

Specify whether executables export symbols for loadable modules.

This variable is used to initialize the ENABLE_EXPORTS target property for executable targets when they are created by calls to the add_executable() command. See the property documentation for details.

This variable supersede the CMAKE_ENABLE_EXPORTS variable.

CMAKE_EXE_LINKER_FLAGS¶

Linker flags to be used to create executables.

These flags will be used by the linker when creating an executable.

CMAKE_EXE_LINKER_FLAGS_<CONFIG>¶

Flags to be used when linking an executable.

Same as CMAKE_C_FLAGS_* but used by the linker when creating executables.

CMAKE_EXE_LINKER_FLAGS_<CONFIG>_INIT¶

Added in version 3.7.

Value used to initialize the CMAKE_EXE_LINKER_FLAGS_<CONFIG> cache entry the first time a build tree is configured. 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_EXE_LINKER_FLAGS_INIT.

CMAKE_EXE_LINKER_FLAGS_INIT¶

Added in version 3.7.

Value used to initialize the CMAKE_EXE_LINKER_FLAGS cache entry the first time a build tree is configured. 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 the configuration-specific variable CMAKE_EXE_LINKER_FLAGS_<CONFIG>_INIT.

CMAKE_EXPORT_FIND_PACKAGE_NAME¶

NOTE:

Initializes the value of EXPORT_FIND_PACKAGE_NAME.

CMAKE_FOLDER¶

Added in version 3.12.

Set the folder name. Use to organize targets in an IDE.

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

CMAKE_Fortran_FORMAT¶

Set to FIXED or FREE to indicate the Fortran source layout.

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

CMAKE_Fortran_MODULE_DIRECTORY¶

Fortran module output directory.

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

CMAKE_Fortran_PREPROCESS¶

Added in version 3.18.

Default value for Fortran_PREPROCESS of targets.

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

CMAKE_FRAMEWORK¶

Added in version 3.15.

Default value for FRAMEWORK of targets.

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

CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>¶

Added in version 3.18.

Default framework filename postfix under configuration <CONFIG> when using a multi-config generator.

When a framework target is created its FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG> target property is initialized with the value of this variable if it is set.

CMAKE_GHS_NO_SOURCE_GROUP_FILE¶

Added in version 3.14.

ON / OFF boolean to control if the project file for a target should be one single file or multiple files. Refer to GHS_NO_SOURCE_GROUP_FILE for further details.

CMAKE_GLOBAL_AUTOGEN_TARGET¶

Added in version 3.14.

Switch to enable generation of a global autogen target.

When CMAKE_GLOBAL_AUTOGEN_TARGET is enabled, a custom target autogen is generated. This target depends on all AUTOMOC and AUTOUIC generated The <ORIGIN>_autogen target targets in the project. By building the global autogen target, all AUTOMOC and AUTOUIC files in the project will be generated.

The name of the global autogen target can be changed by setting CMAKE_GLOBAL_AUTOGEN_TARGET_NAME.

By default CMAKE_GLOBAL_AUTOGEN_TARGET is unset.

See the cmake-qt(7) manual for more information on using CMake with Qt.

NOTE:

CMAKE_GLOBAL_AUTOGEN_TARGET_NAME¶

Added in version 3.14.

Change the name of the global autogen target.

When CMAKE_GLOBAL_AUTOGEN_TARGET is enabled, a global custom target named autogen is created. CMAKE_GLOBAL_AUTOGEN_TARGET_NAME allows to set a different name for that target.

By default CMAKE_GLOBAL_AUTOGEN_TARGET_NAME is unset.

See the cmake-qt(7) manual for more information on using CMake with Qt.

CMAKE_GLOBAL_AUTORCC_TARGET¶

Added in version 3.14.

Switch to enable generation of a global autorcc target.

When CMAKE_GLOBAL_AUTORCC_TARGET is enabled, a custom target autorcc is generated. This target depends on all AUTORCC generated <ORIGIN>_arcc_<QRC> targets in the project. By building the global autorcc target, all AUTORCC files in the project will be generated.

The name of the global autorcc target can be changed by setting CMAKE_GLOBAL_AUTORCC_TARGET_NAME.

By default CMAKE_GLOBAL_AUTORCC_TARGET is unset.

See the cmake-qt(7) manual for more information on using CMake with Qt.

CMAKE_GLOBAL_AUTORCC_TARGET_NAME¶

Added in version 3.14.

Change the name of the global autorcc target.

When CMAKE_GLOBAL_AUTORCC_TARGET is enabled, a global custom target named autorcc is created. CMAKE_GLOBAL_AUTORCC_TARGET_NAME allows to set a different name for that target.

By default CMAKE_GLOBAL_AUTORCC_TARGET_NAME is unset.

See the cmake-qt(7) manual for more information on using CMake with Qt.

CMAKE_GNUtoMS¶

Convert GNU import libraries (.dll.a) to MS format (.lib).

This variable is used to initialize the GNUtoMS property on targets when they are created. See that target property for additional information.

CMAKE_INCLUDE_CURRENT_DIR¶

Automatically add the current source and build directories to the include path.

If this variable is enabled, CMake automatically adds CMAKE_CURRENT_SOURCE_DIR and CMAKE_CURRENT_BINARY_DIR to the include path for each directory. These additional include directories do not propagate down to subdirectories. This is useful mainly for out-of-source builds, where files generated into the build tree are included by files located in the source tree.

By default CMAKE_INCLUDE_CURRENT_DIR is OFF.

CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE¶

Automatically add the current source and build directories to the INTERFACE_INCLUDE_DIRECTORIES target property.

If this variable is enabled, CMake automatically adds for each shared library target, static library target, module target and executable target, CMAKE_CURRENT_SOURCE_DIR and CMAKE_CURRENT_BINARY_DIR to the INTERFACE_INCLUDE_DIRECTORIES target property. By default CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE is OFF.

CMAKE_INSTALL_NAME_DIR¶

Directory name for installed targets on Apple platforms.

CMAKE_INSTALL_NAME_DIR is used to initialize the INSTALL_NAME_DIR property on all targets. See that target property for more information.

CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH¶

Added in version 3.16.

Sets the default for whether toolchain-defined rpaths should be removed during installation.

CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH is a boolean that provides the default value for the INSTALL_REMOVE_ENVIRONMENT_RPATH property of all subsequently created targets.

CMAKE_INSTALL_RPATH¶

The rpath to use for installed targets.

A semicolon-separated list specifying the rpath to use in installed targets (for platforms that support it). This is used to initialize the target property INSTALL_RPATH for all targets.

CMAKE_INSTALL_RPATH_USE_LINK_PATH¶

Add paths to linker search and installed rpath.

CMAKE_INSTALL_RPATH_USE_LINK_PATH is a boolean that if set to True will append to the runtime search path (rpath) of installed binaries any directories outside the project that are in the linker search path or contain linked library files. The directories are appended after the value of the INSTALL_RPATH target property.

This variable is used to initialize the target property INSTALL_RPATH_USE_LINK_PATH for all targets.

CMAKE_INTERPROCEDURAL_OPTIMIZATION¶

Added in version 3.9.

Default value for INTERPROCEDURAL_OPTIMIZATION of targets.

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

CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>¶

Added in version 3.9.

Default value for INTERPROCEDURAL_OPTIMIZATION_<CONFIG> of targets.

This variable is used to initialize the INTERPROCEDURAL_OPTIMIZATION_<CONFIG> property on all the targets. See that target property for additional information.

CMAKE_<LANG>_CLANG_TIDY¶

Added in version 3.6.

Default value for <LANG>_CLANG_TIDY target property when <LANG> is C, CXX, OBJC or OBJCXX.

This variable is used to initialize the property on each target as it is created. For example:

set(CMAKE_CXX_CLANG_TIDY clang-tidy -checks=-*,readability-*)
add_executable(foo foo.cxx)

CMAKE_<LANG>_CLANG_TIDY_EXPORT_FIXES_DIR¶

Added in version 3.26.

Default value for <LANG>_CLANG_TIDY_EXPORT_FIXES_DIR target property when <LANG> is C, CXX, OBJC or OBJCXX.

This variable is used to initialize the property on each target as it is created. For example:

set(CMAKE_CXX_CLANG_TIDY_EXPORT_FIXES_DIR clang-tidy-fixes)
add_executable(foo foo.cxx)

CMAKE_<LANG>_COMPILER_LAUNCHER¶

Added in version 3.4.

Default value for <LANG>_COMPILER_LAUNCHER target property. This variable is used to initialize the property on each target as it is created. This is done only when <LANG> is C, CXX, Fortran, HIP, ISPC, OBJC, OBJCXX, or CUDA.

This variable is initialized to the CMAKE_<LANG>_COMPILER_LAUNCHER environment variable if it is set.

CMAKE_<LANG>_CPPCHECK¶

Added in version 3.10.

Default value for <LANG>_CPPCHECK target property. This variable is used to initialize the property on each target as it is created. This is done only when <LANG> is C or CXX.

CMAKE_<LANG>_CPPLINT¶

Added in version 3.8.

Default value for <LANG>_CPPLINT target property. This variable is used to initialize the property on each target as it is created. This is done only when <LANG> is C or CXX.

CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE¶

Added in version 3.3.

Default value for <LANG>_INCLUDE_WHAT_YOU_USE target property. This variable is used to initialize the property on each target as it is created. This is done only when <LANG> is C or CXX.

CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>¶

Added in version 3.24.

This variable defines how to link a group of libraries for the specified <FEATURE> when a LINK_GROUP generator expression is used and the link language for the target is <LANG>. For this variable to have any effect, the associated CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>_SUPPORTED variable must be set to true.

The CMAKE_LINK_GROUP_USING_<FEATURE> variable should be defined instead for features that are independent of the link language.

Feature names are case-sensitive and may only contain letters, numbers and underscores. Feature names defined in all uppercase are reserved for CMake's own built-in features (see Predefined Features further below).

Feature Definitions¶

A group feature definition is a list that contains exactly two elements:

<PREFIX> <SUFFIX>

On the linker command line, <PREFIX> will precede the list of libraries in the group and <SUFFIX> will follow after.

For the elements of this variable, the LINKER: prefix can be used.

To pass options to the linker tool, each compiler driver has its own syntax. The LINKER: prefix and , separator can be used to specify, in a portable way, options to pass to the linker tool. LINKER: is replaced by the appropriate driver option and , by the appropriate driver separator. The driver prefix and driver separator are given by the values of the CMAKE_<LANG>_LINKER_WRAPPER_FLAG and CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP variables.

For example, "LINKER:-z,defs" becomes -Xlinker -z -Xlinker defs for Clang and -Wl,-z,defs for GNU GCC.

The LINKER: prefix can be specified as part of a SHELL: prefix expression.

The LINKER: prefix supports, as an alternative syntax, specification of arguments using the SHELL: prefix and space as separator. The previous example then becomes "LINKER:SHELL:-z defs".

NOTE:

Examples¶

Solving cross-references between two static libraries¶

A project may define two or more static libraries which have circular dependencies between them. In order for the linker to resolve all symbols at link time, it may need to search repeatedly among the libraries until no new undefined references are created. Different linkers use different syntax for achieving this. The following example shows how this may be implemented for some linkers. Note that this is for illustration purposes only. Projects should use the built-in RESCAN group feature instead (see Predefined Features), which provides a more complete and more robust implementation of this functionality.

set(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED TRUE)
if(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND CMAKE_SYSTEM_NAME STREQUAL "Linux")


  set(CMAKE_C_LINK_GROUP_USING_cross_refs


    "LINKER:--start-group"


    "LINKER:--end-group"


  )
elseif(CMAKE_C_COMPILER_ID STREQUAL "SunPro" AND CMAKE_SYSTEM_NAME STREQUAL "SunOS")


  set(CMAKE_C_LINK_GROUP_USING_cross_refs


    "LINKER:-z,rescan-start"


    "LINKER:-z,rescan-end"


  )
else()


  # feature not yet supported for the other environments


  set(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED FALSE)
endif()
add_library(lib1 STATIC ...)
add_library(lib2 SHARED ...)
if(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED)


  target_link_libraries(lib2 PRIVATE "$<LINK_GROUP:cross_refs,lib1,external>")
else()


  target_link_libraries(lib2 PRIVATE lib1 external)
endif()

CMake will generate the following linker command line fragments when linking lib2:

Predefined Features¶

The following built-in group features are pre-defined by CMake:

CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>_SUPPORTED¶

Added in version 3.24.

This variable specifies whether the <FEATURE> is supported for the link language <LANG>. If this variable is true, then the <FEATURE> must be defined by CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>, and the more generic CMAKE_LINK_GROUP_USING_<FEATURE>_SUPPORTED and CMAKE_LINK_GROUP_USING_<FEATURE> variables are not used.

If CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>_SUPPORTED is false or is not set, then the CMAKE_LINK_GROUP_USING_<FEATURE>_SUPPORTED variable will determine whether <FEATURE> is deemed to be supported.

CMAKE_<LANG>_LINK_LIBRARY_<FEATURE>_ATTRIBUTES¶

Added in version 3.30.

This variable defines the semantics of the specified link library <FEATURE> when linking with the link language <LANG>. It takes precedence over CMAKE_LINK_LIBRARY_<FEATURE>_ATTRIBUTES if that variable is also defined for the same <FEATURE>, but otherwise has similar effects. See CMAKE_LINK_LIBRARY_<FEATURE>_ATTRIBUTES for further details.

CMAKE_<LANG>_LINK_LIBRARY_FILE_FLAG¶

Added in version 3.16.

Language-specific flag to be used to link a library specified by a path to its file.

The flag will be used before a library file path is given to the linker. This is needed only on very few platforms.

CMAKE_<LANG>_LINK_LIBRARY_FLAG¶

Added in version 3.16.

Flag to be used to link a library into a shared library or executable.

This flag will be used to specify a library to link to a shared library or an executable for the specific language. On most compilers this is -l.

CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>¶

Added in version 3.24.

This variable defines how to link a library or framework for the specified <FEATURE> when a LINK_LIBRARY generator expression is used and the link language for the target is <LANG>. For this variable to have any effect, the associated CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED variable must be set to true.

The CMAKE_LINK_LIBRARY_USING_<FEATURE> variable should be defined instead for features that are independent of the link language.

Feature names are case-sensitive and may only contain letters, numbers and underscores. Feature names defined in all uppercase are reserved for CMake's own built-in features (see Predefined Features further below).

Some aspects of feature behavior can be defined by the CMAKE_<LANG>_LINK_LIBRARY_<FEATURE>_ATTRIBUTES and CMAKE_LINK_LIBRARY_<FEATURE>_ATTRIBUTES variables.

Feature Definitions¶

A library feature definition is a list that contains one or three elements:

[<PREFIX>] <LIBRARY_EXPRESSION> [<SUFFIX>]

When <PREFIX> and <SUFFIX> are specified, they precede and follow respectively the whole list of libraries specified in the LINK_LIBRARY expression, not each library item individually. There is no guarantee that the list of specified libraries will be kept grouped together though, so the <PREFIX> and <SUFFIX> may appear more than once if the library list is reorganized by CMake to satisfy other constraints. This means constructs like --start-group and --end-group, as supported by the GNU ld linker, cannot be used in this way. The LINK_GROUP generator expression should be used instead for such constructs.

<LIBRARY_EXPRESSION> is used to specify the pattern for constructing the corresponding fragment on the linker command line for each library. The following placeholders can be used in the expression:

In addition to the above, it is possible to have one pattern for paths (CMake targets and external libraries specified with file paths) and another for other items specified by name only. The PATH{} and NAME{} wrappers can be used to provide the expansion for those two cases, respectively. When wrappers are used, both must be present. For example:

set(CMAKE_LINK_LIBRARY_USING_weak_library


    "PATH{-weak_library <LIBRARY>}NAME{LINKER:-weak-l<LIB_ITEM>}"
)

For all three elements of this variable (<PREFIX>, <LIBRARY_EXPRESSION>, and <SUFFIX>), the LINKER: prefix can be used.

To pass options to the linker tool, each compiler driver has its own syntax. The LINKER: prefix and , separator can be used to specify, in a portable way, options to pass to the linker tool. LINKER: is replaced by the appropriate driver option and , by the appropriate driver separator. The driver prefix and driver separator are given by the values of the CMAKE_<LANG>_LINKER_WRAPPER_FLAG and CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP variables.

For example, "LINKER:-z,defs" becomes -Xlinker -z -Xlinker defs for Clang and -Wl,-z,defs for GNU GCC.

The LINKER: prefix can be specified as part of a SHELL: prefix expression.

The LINKER: prefix supports, as an alternative syntax, specification of arguments using the SHELL: prefix and space as separator. The previous example then becomes "LINKER:SHELL:-z defs".

NOTE:

Examples¶

Loading a whole static library¶

A common need is to prevent the linker from discarding any symbols from a static library. Different linkers use different syntax for achieving this. The following example shows how this may be implemented for some linkers. Note that this is for illustration purposes only. Projects should use the built-in WHOLE_ARCHIVE feature instead (see Predefined Features), which provides a more complete and more robust implementation of this functionality.

set(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED TRUE)
if(CMAKE_C_COMPILER_ID STREQUAL "AppleClang")


  set(CMAKE_C_LINK_LIBRARY_USING_load_archive "-force_load <LIB_ITEM>")
elseif(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND CMAKE_SYSTEM_NAME STREQUAL "Linux")


  set(CMAKE_C_LINK_LIBRARY_USING_load_archive


    "LINKER:--push-state,--whole-archive"


    "<LINK_ITEM>"


    "LINKER:--pop-state"


  )
elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")


  set(CMAKE_C_LINK_LIBRARY_USING_load_archive "/WHOLEARCHIVE:<LIBRARY>")
else()


  # feature not yet supported for the other environments


  set(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED FALSE)
endif()
add_library(lib1 STATIC ...)
add_library(lib2 SHARED ...)
if(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED)


  # The -force_load Apple linker option requires a file name


  set(external_lib


    "$<IF:$<LINK_LANG_AND_ID:C,AppleClang>,libexternal.a,external>"


  )


  target_link_libraries(lib2 PRIVATE


    "$<LINK_LIBRARY:load_archive,lib1,${external_lib}>"


  )
else()


  target_link_libraries(lib2 PRIVATE lib1 external)
endif()

CMake will generate the following link expressions:

Linking a library as weak¶

On macOS, it is possible to link a library in weak mode (the library and all references are marked as weak imports). Different flags must be used for a library specified by file path compared to one specified by name. This constraint can be solved using PATH{} and NAME{} wrappers. Again, the following example shows how this may be implemented for some linkers, but it is for illustration purposes only. Projects should use the built-in WEAK_FRAMEWORK or WEAK_LIBRARY features instead (see Predefined Features), which provide more complete and more robust implementations of this functionality.

if (CMAKE_C_COMPILER_ID STREQUAL "AppleClang")


  set(CMAKE_LINK_LIBRARY_USING_weak_library


      "PATH{-weak_library <LIBRARY>}NAME{LINKER:-weak-l<LIB_ITEM>}"


  )


  set(CMAKE_LINK_LIBRARY_USING_weak_library_SUPPORTED TRUE)
endif()
add_library(lib SHARED ...)
add_executable(main ...)
if(CMAKE_LINK_LIBRARY_USING_weak_library_SUPPORTED)


  target_link_libraries(main PRIVATE "$<LINK_LIBRARY:weak_library,lib,external>")
else()


  target_link_libraries(main PRIVATE lib external)
endif()

CMake will generate the following linker command line fragment when linking main using the AppleClang toolchain:

-weak_library /path/to/lib -Xlinker -weak-lexternal.

Predefined Features¶

The following built-in library features are pre-defined by CMake:

add_library(lib SHARED ...)
target_link_libraries(lib PRIVATE "$<LINK_LIBRARY:FRAMEWORK,/path/to/my_framework>")
# The constructed linker command line will contain:
#   -F/path/to -framework my_framework

CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED¶

Added in version 3.24.

Set to TRUE if the <FEATURE>, as defined by variable CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>, is supported for the linker language <LANG>.

NOTE:

CMAKE_<LANG>_LINK_WHAT_YOU_USE_FLAG¶

Added in version 3.22.

Linker flag to be used to configure linker so that all specified libraries on the command line will be linked into the target.

See also variable CMAKE_LINK_WHAT_YOU_USE_CHECK.

CMAKE_<LANG>_LINKER_LAUNCHER¶

Added in version 3.21.

Default value for <LANG>_LINKER_LAUNCHER target property. This variable is used to initialize the property on each target as it is created. This is done only when <LANG> is C, CXX, OBJC, or OBJCXX.

This variable is initialized to the CMAKE_<LANG>_LINKER_LAUNCHER environment variable if it is set.

CMAKE_<LANG>_USING_LINKER_MODE¶

Added in version 3.29.

This controls how the value of the CMAKE_<LANG>_USING_LINKER_<TYPE> variable should be interpreted. The supported linker mode values are:

CMAKE_<LANG>_USING_LINKER_<TYPE>¶

Added in version 3.29.

This variable defines how to specify the <TYPE> linker for the link step, as controlled by the CMAKE_LINKER_TYPE variable or the LINKER_TYPE target property. Depending on the value of the CMAKE_<LANG>_USING_LINKER_MODE variable, CMAKE_<LANG>_USING_LINKER_<TYPE> can hold compiler flags for the link step, or flags to be given directly to the linker tool.

NOTE:

For example, the LLD linker for GNU compilers is defined like so:

set(CMAKE_C_USING_LINKER_LLD "-fuse-ld=lld")

On the Windows platform with Clang compilers simulating MSVC:

set(CMAKE_C_USING_LINKER_LLD "-fuse-ld=lld-link")

And for the MSVC compiler, the linker is invoked directly, not via the compiler frontend:

set(CMAKE_C_USING_LINKER_LLD "/path/to/lld-link.exe")
set(CMAKE_C_USING_LINKER_MODE TOOL)

A custom linker type can also be defined, usually in a toolchain file:

set(CMAKE_LINKER_TYPE lld_launcher)
set(CMAKE_C_USING_LINKER_lld_launcher "-fuse-ld=/path/to/lld-launcher.sh")
set(CMAKE_C_USING_LINKER_MODE FLAG)

CMAKE_<LANG>_VISIBILITY_PRESET¶

Default value for the <LANG>_VISIBILITY_PRESET target property when a target is created.

CMAKE_LIBRARY_OUTPUT_DIRECTORY¶

Where to put all the LIBRARY target files when built.

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

CMAKE_LIBRARY_OUTPUT_DIRECTORY_<CONFIG>¶

Added in version 3.3.

Where to put all the LIBRARY target files when built for a specific configuration.

This variable is used to initialize the LIBRARY_OUTPUT_DIRECTORY_<CONFIG> property on all the targets. See that target property for additional information.

CMAKE_LIBRARY_PATH_FLAG¶

The flag to be used to add a library search path to a compiler.

The flag will be used to specify a library directory to the compiler. On most compilers this is -L.

CMAKE_LINK_DEF_FILE_FLAG¶

Linker flag to be used to specify a .def file for dll creation.

The flag will be used to add a .def file when creating a dll on Windows; this is only defined on Windows.

CMAKE_LINK_DEPENDS_NO_SHARED¶

Whether to skip link dependencies on shared library files.

This variable initializes the LINK_DEPENDS_NO_SHARED property on targets when they are created. See that target property for additional information.

CMAKE_LINK_DEPENDS_USE_LINKER¶

Added in version 3.27.

For the Makefile and Ninja generators, link dependencies are now, for a selection of linkers, generated by the linker itself. By defining this variable with value FALSE, you can deactivate this feature.

This feature is also deactivated if the LINK_DEPENDS_NO_SHARED target property is true.

NOTE:

CMAKE_LINK_GROUP_USING_<FEATURE>¶

Added in version 3.24.

This variable defines how to link a group of libraries for the specified <FEATURE> when a LINK_GROUP generator expression is used. Both of the following conditions must be met for this variable to have any effect:

The CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE> variable should be defined instead for features that are dependent on the link language.

Feature names are case-sensitive and may only contain letters, numbers and underscores. Feature names defined in all uppercase are reserved for CMake's own built-in features (see Predefined Features further below).

Feature Definitions¶

A group feature definition is a list that contains exactly two elements:

<PREFIX> <SUFFIX>

On the linker command line, <PREFIX> will precede the list of libraries in the group and <SUFFIX> will follow after.

For the elements of this variable, the LINKER: prefix can be used.

To pass options to the linker tool, each compiler driver has its own syntax. The LINKER: prefix and , separator can be used to specify, in a portable way, options to pass to the linker tool. LINKER: is replaced by the appropriate driver option and , by the appropriate driver separator. The driver prefix and driver separator are given by the values of the CMAKE_<LANG>_LINKER_WRAPPER_FLAG and CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP variables.

For example, "LINKER:-z,defs" becomes -Xlinker -z -Xlinker defs for Clang and -Wl,-z,defs for GNU GCC.

The LINKER: prefix can be specified as part of a SHELL: prefix expression.

The LINKER: prefix supports, as an alternative syntax, specification of arguments using the SHELL: prefix and space as separator. The previous example then becomes "LINKER:SHELL:-z defs".

NOTE:

Examples¶

Solving cross-references between two static libraries¶

A project may define two or more static libraries which have circular dependencies between them. In order for the linker to resolve all symbols at link time, it may need to search repeatedly among the libraries until no new undefined references are created. Different linkers use different syntax for achieving this. The following example shows how this may be implemented for some linkers. Note that this is for illustration purposes only. Projects should use the built-in RESCAN group feature instead (see Predefined Features), which provides a more complete and more robust implementation of this functionality.

set(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED TRUE)
if(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND CMAKE_SYSTEM_NAME STREQUAL "Linux")


  set(CMAKE_C_LINK_GROUP_USING_cross_refs


    "LINKER:--start-group"


    "LINKER:--end-group"


  )
elseif(CMAKE_C_COMPILER_ID STREQUAL "SunPro" AND CMAKE_SYSTEM_NAME STREQUAL "SunOS")


  set(CMAKE_C_LINK_GROUP_USING_cross_refs


    "LINKER:-z,rescan-start"


    "LINKER:-z,rescan-end"


  )
else()


  # feature not yet supported for the other environments


  set(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED FALSE)
endif()
add_library(lib1 STATIC ...)
add_library(lib2 SHARED ...)
if(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED)


  target_link_libraries(lib2 PRIVATE "$<LINK_GROUP:cross_refs,lib1,external>")
else()


  target_link_libraries(lib2 PRIVATE lib1 external)
endif()

CMake will generate the following linker command line fragments when linking lib2:

Predefined Features¶

The following built-in group features are pre-defined by CMake:

CMAKE_LINK_GROUP_USING_<FEATURE>_SUPPORTED¶

Added in version 3.24.

This variable specifies whether the <FEATURE> is supported regardless of the link language. If this variable is true, then the <FEATURE> must be defined by CMAKE_LINK_GROUP_USING_<FEATURE>.

Note that this variable has no effect if CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>_SUPPORTED is true for the link language of the target.

CMAKE_LINK_INTERFACE_LIBRARIES¶

Default value for LINK_INTERFACE_LIBRARIES of targets.

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

CMAKE_LINK_LIBRARIES_STRATEGY¶

Added in version 3.31.

Specify a strategy for ordering targets' direct link dependencies on linker command lines.

If set, this variable acts as the default value for the LINK_LIBRARIES_STRATEGY target property when a target is created. Set that property directly to specify a strategy for a single target.

CMAKE_LINK_LIBRARY_<FEATURE>_ATTRIBUTES¶

Added in version 3.30.

This variable defines the behavior of the specified link library <FEATURE>. It specifies how the <FEATURE> interacts with other features, when the <FEATURE> should be applied, and aspects of how the <FEATURE> should be handled when CMake assembles the final linker command line (e.g. de-duplication).

The syntax of the linker flags for the <FEATURE> are controlled by the CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE> and CMAKE_LINK_LIBRARY_USING_<FEATURE> variables. The CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED and CMAKE_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED variables control whether the <FEATURE> is available at all.

When linking for a particular language <LANG>, CMAKE_LINK_LIBRARY_<FEATURE>_ATTRIBUTES is ignored if the CMAKE_<LANG>_LINK_LIBRARY_<FEATURE>_ATTRIBUTES variable is also defined for the same <FEATURE>.

The value of CMAKE_LINK_LIBRARY_<FEATURE>_ATTRIBUTES and CMAKE_<LANG>_LINK_LIBRARY_<FEATURE>_ATTRIBUTES at the end of the directory scope in which a target is defined is what matters.

Feature Attributes Definition¶

A feature attributes definition is a semicolon-separated list of attribute=value(s) items. If an attribute has multiple values, those values must be comma-separated.

The following attributes are supported:

Example¶

A common need is the loading of a full archive as part of the creation of a shared library. The built-in WHOLE_ARCHIVE feature can be used for that purpose. The implementation of that built-in feature sets the following link library feature attributes:

set(CMAKE_LINK_LIBRARY_WHOLE_ARCHIVE_ATTRIBUTES


  LIBRARY_TYPE=STATIC


  OVERRIDE=DEFAULT


  DEDUPLICATION=YES
)

The WHOLE_ARCHIVE feature can be used like so:

add_library(A STATIC ...)
add_library(B STATIC ...)
target_link_libraries(B PUBLIC A)
target_link_libraries(A PUBLIC B)
add_library(global SHARED ...)
target_link_libraries(global PRIVATE $<LINK_LIBRARY:WHOLE_ARCHIVE,A>)

The resulting link command will only have one instance of the A library specified, and the linker flags will ensure that all symbols are loaded from the A library.

CMAKE_LINK_LIBRARY_FILE_FLAG¶

Flag to be used to link a library specified by a path to its file.

The flag will be used before a library file path is given to the linker. This is needed only on very few platforms.

CMAKE_LINK_LIBRARY_FLAG¶

Flag to be used to link a library into an executable.

The flag will be used to specify a library to link to an executable. On most compilers this is -l.

CMAKE_LINK_LIBRARY_USING_<FEATURE>¶

Added in version 3.24.

This variable defines how to link a library or framework for the specified <FEATURE> when a LINK_LIBRARY generator expression is used. Both of the following conditions must be met for this variable to have any effect:

Feature names are case-sensitive and may only contain letters, numbers and underscores. Feature names defined in all uppercase are reserved for CMake's own built-in features (see Predefined Features further below).

Some aspects of feature behavior can be defined by the CMAKE_<LANG>_LINK_LIBRARY_<FEATURE>_ATTRIBUTES and CMAKE_LINK_LIBRARY_<FEATURE>_ATTRIBUTES variables.

Feature Definitions¶

A library feature definition is a list that contains one or three elements:

[<PREFIX>] <LIBRARY_EXPRESSION> [<SUFFIX>]

When <PREFIX> and <SUFFIX> are specified, they precede and follow respectively the whole list of libraries specified in the LINK_LIBRARY expression, not each library item individually. There is no guarantee that the list of specified libraries will be kept grouped together though, so the <PREFIX> and <SUFFIX> may appear more than once if the library list is reorganized by CMake to satisfy other constraints. This means constructs like --start-group and --end-group, as supported by the GNU ld linker, cannot be used in this way. The LINK_GROUP generator expression should be used instead for such constructs.

<LIBRARY_EXPRESSION> is used to specify the pattern for constructing the corresponding fragment on the linker command line for each library. The following placeholders can be used in the expression:

In addition to the above, it is possible to have one pattern for paths (CMake targets and external libraries specified with file paths) and another for other items specified by name only. The PATH{} and NAME{} wrappers can be used to provide the expansion for those two cases, respectively. When wrappers are used, both must be present. For example:

set(CMAKE_LINK_LIBRARY_USING_weak_library


    "PATH{-weak_library <LIBRARY>}NAME{LINKER:-weak-l<LIB_ITEM>}"
)

For all three elements of this variable (<PREFIX>, <LIBRARY_EXPRESSION>, and <SUFFIX>), the LINKER: prefix can be used.

To pass options to the linker tool, each compiler driver has its own syntax. The LINKER: prefix and , separator can be used to specify, in a portable way, options to pass to the linker tool. LINKER: is replaced by the appropriate driver option and , by the appropriate driver separator. The driver prefix and driver separator are given by the values of the CMAKE_<LANG>_LINKER_WRAPPER_FLAG and CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP variables.

For example, "LINKER:-z,defs" becomes -Xlinker -z -Xlinker defs for Clang and -Wl,-z,defs for GNU GCC.

The LINKER: prefix can be specified as part of a SHELL: prefix expression.

The LINKER: prefix supports, as an alternative syntax, specification of arguments using the SHELL: prefix and space as separator. The previous example then becomes "LINKER:SHELL:-z defs".

NOTE:

Examples¶

Loading a whole static library¶

A common need is to prevent the linker from discarding any symbols from a static library. Different linkers use different syntax for achieving this. The following example shows how this may be implemented for some linkers. Note that this is for illustration purposes only. Projects should use the built-in WHOLE_ARCHIVE feature instead (see Predefined Features), which provides a more complete and more robust implementation of this functionality.

set(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED TRUE)
if(CMAKE_C_COMPILER_ID STREQUAL "AppleClang")


  set(CMAKE_C_LINK_LIBRARY_USING_load_archive "-force_load <LIB_ITEM>")
elseif(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND CMAKE_SYSTEM_NAME STREQUAL "Linux")


  set(CMAKE_C_LINK_LIBRARY_USING_load_archive


    "LINKER:--push-state,--whole-archive"


    "<LINK_ITEM>"


    "LINKER:--pop-state"


  )
elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")


  set(CMAKE_C_LINK_LIBRARY_USING_load_archive "/WHOLEARCHIVE:<LIBRARY>")
else()


  # feature not yet supported for the other environments


  set(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED FALSE)
endif()
add_library(lib1 STATIC ...)
add_library(lib2 SHARED ...)
if(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED)


  # The -force_load Apple linker option requires a file name


  set(external_lib


    "$<IF:$<LINK_LANG_AND_ID:C,AppleClang>,libexternal.a,external>"


  )


  target_link_libraries(lib2 PRIVATE


    "$<LINK_LIBRARY:load_archive,lib1,${external_lib}>"


  )
else()


  target_link_libraries(lib2 PRIVATE lib1 external)
endif()

CMake will generate the following link expressions:

Linking a library as weak¶

On macOS, it is possible to link a library in weak mode (the library and all references are marked as weak imports). Different flags must be used for a library specified by file path compared to one specified by name. This constraint can be solved using PATH{} and NAME{} wrappers. Again, the following example shows how this may be implemented for some linkers, but it is for illustration purposes only. Projects should use the built-in WEAK_FRAMEWORK or WEAK_LIBRARY features instead (see Predefined Features), which provide more complete and more robust implementations of this functionality.

if (CMAKE_C_COMPILER_ID STREQUAL "AppleClang")


  set(CMAKE_LINK_LIBRARY_USING_weak_library


      "PATH{-weak_library <LIBRARY>}NAME{LINKER:-weak-l<LIB_ITEM>}"


  )


  set(CMAKE_LINK_LIBRARY_USING_weak_library_SUPPORTED TRUE)
endif()
add_library(lib SHARED ...)
add_executable(main ...)
if(CMAKE_LINK_LIBRARY_USING_weak_library_SUPPORTED)


  target_link_libraries(main PRIVATE "$<LINK_LIBRARY:weak_library,lib,external>")
else()


  target_link_libraries(main PRIVATE lib external)
endif()

CMake will generate the following linker command line fragment when linking main using the AppleClang toolchain:

-weak_library /path/to/lib -Xlinker -weak-lexternal.

Predefined Features¶

The following built-in library features are pre-defined by CMake:

add_library(lib SHARED ...)
target_link_libraries(lib PRIVATE "$<LINK_LIBRARY:FRAMEWORK,/path/to/my_framework>")
# The constructed linker command line will contain:
#   -F/path/to -framework my_framework