CMake Reference Documentation — CMake 3.14.0-rc4 Documentation

Navigation

  • index
  • next |
  • CMake »
  • 3.14.0-rc4 Documentation »

Command-Line Tools

  • cmake(1)
  • ctest(1)
  • cpack(1)

Interactive Dialogs

  • cmake-gui(1)
  • ccmake(1)

Reference Manuals

  • cmake-buildsystem(7)
  • cmake-commands(7)
  • cmake-compile-features(7)
  • cmake-developer(7)
  • cmake-env-variables(7)
  • cmake-file-api(7)
  • cmake-generator-expressions(7)
  • cmake-generators(7)
  • cmake-language(7)
  • cmake-modules(7)
  • cmake-packages(7)
  • cmake-policies(7)
  • cmake-properties(7)
  • cmake-qt(7)
  • cmake-server(7)
  • cmake-toolchains(7)
  • cmake-variables(7)
  • cpack-generators(7)

Release Notes

  • CMake Release Notes

Index and Search

  • Index
  • Search Page

Navigation

  • index
  • next |
  • CMake »
  • 3.14.0-rc4 Documentation »
© Copyright 2000-2019 Kitware, Inc. and Contributors. Created using Sphinx 1.8.5.


cmake(1) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake(1)

Synopsis

Generate a Project Buildsystem
 cmake [<options>] <path-to-source>
 cmake [<options>] <path-to-existing-build>
 cmake [<options>] -S <path-to-source> -B <path-to-build>

Build a Project
 cmake --build <dir> [<options>] [-- <build-tool-options>]

Open a Project
 cmake --open <dir>

Run a Script
 cmake [{-D <var>=<value>}...] -P <cmake-script-file>

Run a Command-Line Tool
 cmake -E <command> [<options>]

Run the Find-Package Tool
 cmake --find-package [<options>]

View Help
 cmake --help[-<topic>]

Description

The cmake executable is the command-line interface of the cross-platform buildsystem generator CMake. The above Synopsis lists various actions the tool can perform as described in sections below.

To build a software project with CMake, Generate a Project Buildsystem. Optionally use cmake to Build a Project or just run the corresponding build tool (e.g. make) directly. cmake can also be used to View Help.

The other actions are meant for use by software developers writing scripts in the CMake language to support their builds.

For graphical user interfaces that may be used in place of cmake, see ccmake and cmake-gui. For command-line interfaces to the CMake testing and packaging facilities, see ctest and cpack.

For more information on CMake at large, see also the links at the end of this manual.

Introduction to CMake Buildsystems

A buildsystem describes how to build a project’s executables and libraries from its source code using a build tool to automate the process. For example, a buildsystem may be a Makefile for use with a command-line make tool or a project file for an Integrated Development Environment (IDE). In order to avoid maintaining multiple such buildsystems, a project may specify its buildsystem abstractly using files written in the CMake language. From these files CMake generates a preferred buildsystem locally for each user through a backend called a generator.

To generate a buildsystem with CMake, the following must be selected:

Source Tree
The top-level directory containing source files provided by the project. The project specifies its buildsystem using files as described in the cmake-language(7) manual, starting with a top-level file named CMakeLists.txt. These files specify build targets and their dependencies as described in the cmake-buildsystem(7) manual.
Build Tree

The top-level directory in which buildsystem files and build output artifacts (e.g. executables and libraries) are to be stored. CMake will write a CMakeCache.txt file to identify the directory as a build tree and store persistent information such as buildsystem configuration options.

To maintain a pristine source tree, perform an out-of-source build by using a separate dedicated build tree. An in-source build in which the build tree is placed in the same directory as the source tree is also supported, but discouraged.

Generator

This chooses the kind of buildsystem to generate. See the cmake-generators(7) manual for documentation of all generators. Run cmake --help to see a list of generators available locally. Optionally use the -G option below to specify a generator, or simply accept the default CMake chooses for the current platform.

When using one of the Command-Line Build Tool Generators CMake expects that the environment needed by the compiler toolchain is already configured in the shell. When using one of the IDE Build Tool Generators, no particular environment is needed.

Generate a Project Buildsystem

Run CMake with one of the following command signatures to specify the source and build trees and generate a buildsystem:

cmake [<options>] <path-to-source>

Uses the current working directory as the build tree, and <path-to-source> as the source tree. The specified path may be absolute or relative to the current working directory. The source tree must contain a CMakeLists.txt file and must not contain a CMakeCache.txt file because the latter identifies an existing build tree. For example:

$ mkdir build ; cd build
$ cmake ../src
cmake [<options>] <path-to-existing-build>

Uses <path-to-existing-build> as the build tree, and loads the path to the source tree from its CMakeCache.txt file, which must have already been generated by a previous run of CMake. The specified path may be absolute or relative to the current working directory. For example:

$ cd build
$ cmake .
cmake [<options>] -S <path-to-source> -B <path-to-build>

Uses <path-to-build> as the build tree and <path-to-source> as the source tree. The specified paths may be absolute or relative to the current working directory. The source tree must contain a CMakeLists.txt file. The build tree will be created automatically if it does not already exist. For example:

$ cmake -S src -B build

In all cases the <options> may be zero or more of the Options below.

After generating a buildsystem one may use the corresponding native build tool to build the project. For example, after using the Unix Makefiles generator one may run make directly:

$ make
$ make install

Alternatively, one may use cmake to Build a Project by automatically choosing and invoking the appropriate native build tool.

Options

-S <path-to-source>
Path to root directory of the CMake project to build.
-B <path-to-build>

Path to directory which CMake will use as the root of build directory.

If the directory doesn’t already exist CMake will make it.

-C <initial-cache>

Pre-load a script to populate the cache.

When cmake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project. This option may be used to specify a file from which to load cache entries before the first pass through the project’s cmake listfiles. The loaded entries take priority over the project’s default values. The given file should be a CMake script containing SET commands that use the CACHE option, not a cache-format file.

-D <var>:<type>=<value>, -D <var>=<value>

Create or update a cmake cache entry.

When cmake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project. This option may be used to specify a setting that takes priority over the project’s default value. The option may be repeated for as many cache entries as desired.

If the :<type> portion is given it must be one of the types specified by the set() command documentation for its CACHE signature. If the :<type> portion is omitted the entry will be created with no type if it does not exist with a type already. If a command in the project sets the type to PATH or FILEPATH then the <value> will be converted to an absolute path.

This option may also be given as a single argument: -D<var>:<type>=<value> or -D<var>=<value>.

-U <globbing_expr>

Remove matching entries from CMake cache.

This option may be used to remove one or more variables from the CMakeCache.txt file, globbing expressions using * and ? are supported. The option may be repeated for as many cache entries as desired.

Use with care, you can make your CMakeCache.txt non-working.

-G <generator-name>

Specify a build system generator.

CMake may support multiple native build systems on certain platforms. A generator is responsible for generating a particular build system. Possible generator names are specified in the cmake-generators(7) manual.

-T <toolset-spec>

Toolset specification for the generator, if supported.

Some CMake generators support a toolset specification to tell the native build system how to choose a compiler. See the CMAKE_GENERATOR_TOOLSET variable for details.

-A <platform-name>

Specify platform name if supported by generator.

Some CMake generators support a platform name to be given to the native build system to choose a compiler or SDK. See the CMAKE_GENERATOR_PLATFORM variable for details.

-Wno-dev

Suppress developer warnings.

Suppress warnings that are meant for the author of the CMakeLists.txt files. By default this will also turn off deprecation warnings.

-Wdev

Enable developer warnings.

Enable warnings that are meant for the author of the CMakeLists.txt files. By default this will also turn on deprecation warnings.

-Werror=dev

Make developer warnings errors.

Make warnings that are meant for the author of the CMakeLists.txt files errors. By default this will also turn on deprecated warnings as errors.

-Wno-error=dev

Make developer warnings not errors.

Make warnings that are meant for the author of the CMakeLists.txt files not errors. By default this will also turn off deprecated warnings as errors.

-Wdeprecated

Enable deprecated functionality warnings.

Enable warnings for usage of deprecated functionality, that are meant for the author of the CMakeLists.txt files.

-Wno-deprecated

Suppress deprecated functionality warnings.

Suppress warnings for usage of deprecated functionality, that are meant for the author of the CMakeLists.txt files.

-Werror=deprecated

Make deprecated macro and function warnings errors.

Make warnings for usage of deprecated macros and functions, that are meant for the author of the CMakeLists.txt files, errors.

-Wno-error=deprecated

Make deprecated macro and function warnings not errors.

Make warnings for usage of deprecated macros and functions, that are meant for the author of the CMakeLists.txt files, not errors.

-L[A][H]

List non-advanced cached variables.

List cache variables will run CMake and list all the variables from the CMake cache that are not marked as INTERNAL or ADVANCED. This will effectively display current CMake settings, which can then be changed with -D option. Changing some of the variables may result in more variables being created. If A is specified, then it will display also advanced variables. If H is specified, it will also display help for each variable.

-N

View mode only.

Only load the cache. Do not actually run configure and generate steps.

--graphviz=[file]

Generate graphviz of dependencies, see CMakeGraphVizOptions for more.

Generate a graphviz input file that will contain all the library and executable dependencies in the project. See the documentation for CMakeGraphVizOptions for more details.

--system-information [file]

Dump information about this system.

Dump a wide range of information about the current system. If run from the top of a binary tree for a CMake project it will dump additional information such as the cache, log files etc.

--debug-trycompile

Do not delete the try_compile build tree. Only useful on one try_compile at a time.

Do not delete the files and directories created for try_compile calls. This is useful in debugging failed try_compiles. It may however change the results of the try-compiles as old junk from a previous try-compile may cause a different test to either pass or fail incorrectly. This option is best used for one try-compile at a time, and only when debugging.

--debug-output

Put cmake in a debug mode.

Print extra information during the cmake run like stack traces with message(send_error ) calls.

--trace

Put cmake in trace mode.

Print a trace of all calls made and from where.

--trace-expand

Put cmake in trace mode.

Like --trace, but with variables expanded.

--trace-source=<file>

Put cmake in trace mode, but output only lines of a specified file.

Multiple options are allowed.

--warn-uninitialized

Warn about uninitialized values.

Print a warning when an uninitialized variable is used.

--warn-unused-vars

Warn about unused variables.

Find variables that are declared or set, but not used.

--no-warn-unused-cli

Don’t warn about command line options.

Don’t find variables that are declared on the command line, but not used.

--check-system-vars

Find problems with variable usage in system files.

Normally, unused and uninitialized variables are searched for only in CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. This flag tells CMake to warn about other files as well.

Build a Project

CMake provides a command-line signature to build an already-generated project binary tree:

cmake --build <dir> [<options>] [-- <build-tool-options>]

This abstracts a native build tool’s command-line interface with the following options:

--build <dir>
Project binary directory to be built. This is required and must be first.
-j [<jobs>], --parallel [<jobs>]

The maximum number of concurrent processes to use when building. If <jobs> is omitted the native build tool’s default number is used.

The CMAKE_BUILD_PARALLEL_LEVEL environment variable, if set, specifies a default parallel level when this option is not given.

--target <tgt>
Build <tgt> instead of default targets. May only be specified once.
--config <cfg>
For multi-configuration tools, choose configuration <cfg>.
--clean-first
Build target clean first, then build. (To clean only, use --target clean.)
--use-stderr
Ignored. Behavior is default in CMake >= 3.0.
-v, --verbose

Enable verbose output - if supported - including the build commands to be executed.

This option can be omitted if VERBOSE environment variable or CMAKE_VERBOSE_MAKEFILE cached variable is set.

--
Pass remaining options to the native tool.

Run cmake --build with no options for quick help.

Open a Project

cmake --open <dir>

Open the generated project in the associated application. This is only supported by some generators.

Run a Script

cmake [{-D <var>=<value>}...] -P <cmake-script-file>

Process the given cmake file as a script written in the CMake language. No configure or generate step is performed and the cache is not modified. If variables are defined using -D, this must be done before the -P argument.

Run a Command-Line Tool

CMake provides builtin command-line tools through the signature

cmake -E <command> [<options>]

Run cmake -E or cmake -E help for a summary of commands. Available commands are:

capabilities

Report cmake capabilities in JSON format. The output is a JSON object with the following keys:

version

A JSON object with version information. Keys are:

string
The full version string as displayed by cmake --version.
major
The major version number in integer form.
minor
The minor version number in integer form.
patch
The patch level in integer form.
suffix
The cmake version suffix string.
isDirty
A bool that is set if the cmake build is from a dirty tree.
generators

A list available generators. Each generator is a JSON object with the following keys:

name
A string containing the name of the generator.
toolsetSupport
true if the generator supports toolsets and false otherwise.
platformSupport
true if the generator supports platforms and false otherwise.
extraGenerators
A list of strings with all the extra generators compatible with the generator.
serverMode
true if cmake supports server-mode and false otherwise.
chdir <dir> <cmd> [<arg>...]
Change the current working directory and run a command.
compare_files [--ignore-eol] <file1> <file2>
Check if <file1> is same as <file2>. If files are the same, then returns 0, if not it returns 1. The --ignore-eol option implies line-wise comparison and ignores LF/CRLF differences.
copy <file>... <destination>
Copy files to <destination> (either file or directory). If multiple files are specified, the <destination> must be directory and it must exist. Wildcards are not supported.
copy_directory <dir>... <destination>
Copy directories to <destination> directory. If <destination> directory does not exist it will be created.
copy_if_different <file>... <destination>
Copy files to <destination> (either file or directory) if they have changed. If multiple files are specified, the <destination> must be directory and it must exist.
echo [<string>...]
Displays arguments as text.
echo_append [<string>...]
Displays arguments as text but no new line.
env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...
Run command in a modified environment.
environment
Display the current environment variables.
make_directory <dir>...
Create <dir> directories. If necessary, create parent directories too. If a directory already exists it will be silently ignored.
md5sum <file>...

Create MD5 checksum of files in md5sum compatible format:

351abe79cd3800b38cdfb25d45015a15  file1.txt
052f86c15bbde68af55c7f7b340ab639  file2.txt
sha1sum <file>...

Create SHA1 checksum of files in sha1sum compatible format:

4bb7932a29e6f73c97bb9272f2bdc393122f86e0  file1.txt
1df4c8f318665f9a5f2ed38f55adadb7ef9f559c  file2.txt
sha224sum <file>...

Create SHA224 checksum of files in sha224sum compatible format:

b9b9346bc8437bbda630b0b7ddfc5ea9ca157546dbbf4c613192f930  file1.txt
6dfbe55f4d2edc5fe5c9197bca51ceaaf824e48eba0cc453088aee24  file2.txt
sha256sum <file>...

Create SHA256 checksum of files in sha256sum compatible format:

76713b23615d31680afeb0e9efe94d47d3d4229191198bb46d7485f9cb191acc  file1.txt
15b682ead6c12dedb1baf91231e1e89cfc7974b3787c1e2e01b986bffadae0ea  file2.txt
sha384sum <file>...

Create SHA384 checksum of files in sha384sum compatible format:

acc049fedc091a22f5f2ce39a43b9057fd93c910e9afd76a6411a28a8f2b8a12c73d7129e292f94fc0329c309df49434  file1.txt
668ddeb108710d271ee21c0f3acbd6a7517e2b78f9181c6a2ff3b8943af92b0195dcb7cce48aa3e17893173c0a39e23d  file2.txt
sha512sum <file>...

Create SHA512 checksum of files in sha512sum compatible format:

2a78d7a6c5328cfb1467c63beac8ff21794213901eaadafd48e7800289afbc08e5fb3e86aa31116c945ee3d7bf2a6194489ec6101051083d1108defc8e1dba89  file1.txt
7a0b54896fe5e70cca6dd643ad6f672614b189bf26f8153061c4d219474b05dad08c4e729af9f4b009f1a1a280cb625454bf587c690f4617c27e3aebdf3b7a2d  file2.txt
remove [-f] <file>...
Remove the file(s). If any of the listed files already do not exist, the command returns a non-zero exit code, but no message is logged. The -f option changes the behavior to return a zero exit code (i.e. success) in such situations instead.
remove_directory <dir>
Remove a directory and its contents. If a directory does not exist it will be silently ignored.
rename <oldname> <newname>
Rename a file or directory (on one volume).
server
Launch cmake-server(7) mode.
sleep <number>...
Sleep for given number of seconds.
tar [cxt][vf][zjJ] file.tar [<options>] [--] [<file>...]

Create or extract a tar or zip archive. Options are:

--
Stop interpreting options and treat all remaining arguments as file names even if they start in -.
--files-from=<file>
Read file names from the given file, one per line. Blank lines are ignored. Lines may not start in - except for --add-file=<name> to add files whose names start in -.
--mtime=<date>
Specify modification time recorded in tarball entries.
--format=<format>
Specify the format of the archive to be created. Supported formats are: 7zip, gnutar, pax, paxr (restricted pax, default), and zip.
time <command> [<args>...]
Run command and display elapsed time.
touch <file>
Touch a file.
touch_nocreate <file>
Touch a file if it exists but do not create it. If a file does not exist it will be silently ignored.
create_symlink <old> <new>
Create a symbolic link <new> naming <old>.

Note

Path to where <new> symbolic link will be created has to exist beforehand.

Windows-specific Command-Line Tools

The following cmake -E commands are available only on Windows:

delete_regv <key>
Delete Windows registry value.
env_vs8_wince <sdkname>
Displays a batch file which sets the environment for the provided Windows CE SDK installed in VS2005.
env_vs9_wince <sdkname>
Displays a batch file which sets the environment for the provided Windows CE SDK installed in VS2008.
write_regv <key> <value>
Write Windows registry value.

Run the Find-Package Tool

CMake provides a pkg-config like helper for Makefile-based projects:

cmake --find-package [<options>]

It searches a package using find_package() and prints the resulting flags to stdout. This can be used instead of pkg-config to find installed libraries in plain Makefile-based projects or in autoconf-based projects (via share/aclocal/cmake.m4).

Note

This mode is not well-supported due to some technical limitations. It is kept for compatibility but should not be used in new projects.

View Help

To print selected pages from the CMake documentation, use

cmake --help[-<topic>]

with one of the following options:

--help,-help,-usage,-h,-H,/?

Print usage information and exit.

Usage describes the basic command line interface and its options.

--version,-version,/V [<f>]

Show program name/version banner and exit.

If a file is specified, the version is written into it. The help is printed to a named <f>ile if given.

--help-full [<f>]

Print all help manuals and exit.

All manuals are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual <man> [<f>]

Print one help manual and exit.

The specified manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual-list [<f>]

List help manuals available and exit.

The list contains all manuals for which help may be obtained by using the --help-manual option followed by a manual name. The help is printed to a named <f>ile if given.

--help-command <cmd> [<f>]

Print help for one command and exit.

The cmake-commands(7) manual entry for <cmd> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-command-list [<f>]

List commands with help available and exit.

The list contains all commands for which help may be obtained by using the --help-command option followed by a command name. The help is printed to a named <f>ile if given.

--help-commands [<f>]

Print cmake-commands manual and exit.

The cmake-commands(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module <mod> [<f>]

Print help for one module and exit.

The cmake-modules(7) manual entry for <mod> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module-list [<f>]

List modules with help available and exit.

The list contains all modules for which help may be obtained by using the --help-module option followed by a module name. The help is printed to a named <f>ile if given.

--help-modules [<f>]

Print cmake-modules manual and exit.

The cmake-modules(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy <cmp> [<f>]

Print help for one policy and exit.

The cmake-policies(7) manual entry for <cmp> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy-list [<f>]

List policies with help available and exit.

The list contains all policies for which help may be obtained by using the --help-policy option followed by a policy name. The help is printed to a named <f>ile if given.

--help-policies [<f>]

Print cmake-policies manual and exit.

The cmake-policies(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property <prop> [<f>]

Print help for one property and exit.

The cmake-properties(7) manual entries for <prop> are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property-list [<f>]

List properties with help available and exit.

The list contains all properties for which help may be obtained by using the --help-property option followed by a property name. The help is printed to a named <f>ile if given.

--help-properties [<f>]

Print cmake-properties manual and exit.

The cmake-properties(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable <var> [<f>]

Print help for one variable and exit.

The cmake-variables(7) manual entry for <var> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable-list [<f>]

List variables with help available and exit.

The list contains all variables for which help may be obtained by using the --help-variable option followed by a variable name. The help is printed to a named <f>ile if given.

--help-variables [<f>]

Print cmake-variables manual and exit.

The cmake-variables(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

See Also

The following resources are available to get help using CMake:

Home Page

https://cmake.org

The primary starting point for learning about CMake.

Online Documentation and Community Resources

https://cmake.org/documentation

Links to available documentation and community resources may be found on this web page.

Mailing List

https://cmake.org/mailing-lists

For help and discussion about using cmake, a mailing list is provided at cmake@cmake.org. The list is member-post-only but one may sign up on the CMake web page. Please first read the full documentation at https://cmake.org before posting questions to the list.

Navigation

  • index
  • next |
  • previous |


ctest(1) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

ctest(1)

Contents

  • ctest(1)
    • Synopsis
    • Description
    • Options
    • Label and Subproject Summary
    • Build and Test Mode
    • Dashboard Client
      • Dashboard Client Steps
      • Dashboard Client Modes
      • Dashboard Client via CTest Command-Line
      • Dashboard Client via CTest Script
    • Dashboard Client Configuration
      • CTest Start Step
      • CTest Update Step
      • CTest Configure Step
      • CTest Build Step
      • CTest Test Step
      • CTest Coverage Step
      • CTest MemCheck Step
      • CTest Submit Step
    • Show as JSON Object Model
    • See Also

Synopsis

ctest [<options>]
ctest --build-and-test <path-to-source> <path-to-build>
      --build-generator <generator> [<options>...]
      [--build-options <opts>...] [--test-command <command> [<args>...]]
ctest {-D <dashboard> | -M <model> -T <action> | -S <script> | -SP <script>}
      [-- <dashboard-options>...]

Description

The ctest executable is the CMake test driver program. CMake-generated build trees created for projects that use the ENABLE_TESTING and ADD_TEST commands have testing support. This program will run the tests and report results.

Options

-C <cfg>, --build-config <cfg>

Choose configuration to test.

Some CMake-generated build trees can have multiple build configurations in the same tree. This option can be used to specify which one should be tested. Example configurations are “Debug” and “Release”.

--progress

Enable short progress output from tests.

When the output of ctest is being sent directly to a terminal, the progress through the set of tests is reported by updating the same line rather than printing start and end messages for each test on new lines. This can significantly reduce the verbosity of the test output. Test completion messages are still output on their own line for failed tests and the final test summary will also still be logged.

This option can also be enabled by setting the environment variable CTEST_PROGRESS_OUTPUT.

-V,--verbose

Enable verbose output from tests.

Test output is normally suppressed and only summary information is displayed. This option will show all test output.

-VV,--extra-verbose

Enable more verbose output from tests.

Test output is normally suppressed and only summary information is displayed. This option will show even more test output.

--debug

Displaying more verbose internals of CTest.

This feature will result in a large number of output that is mostly useful for debugging dashboard problems.

--output-on-failure
Output anything outputted by the test program if the test should fail. This option can also be enabled by setting the CTEST_OUTPUT_ON_FAILURE environment variable
-F

Enable failover.

This option allows CTest to resume a test set execution that was previously interrupted. If no interruption occurred, the -F option will have no effect.

-j <jobs>, --parallel <jobs>

Run the tests in parallel using the given number of jobs.

This option tells CTest to run the tests in parallel using given number of jobs. This option can also be set by setting the CTEST_PARALLEL_LEVEL environment variable.

This option can be used with the PROCESSORS test property.

See Label and Subproject Summary.

--test-load <level>

While running tests in parallel (e.g. with -j), try not to start tests when they may cause the CPU load to pass above a given threshold.

When ctest is run as a Dashboard Client this sets the TestLoad option of the CTest Test Step.

-Q,--quiet

Make CTest quiet.

This option will suppress all the output. The output log file will still be generated if the --output-log is specified. Options such as --verbose, --extra-verbose, and --debug are ignored if --quiet is specified.

-O <file>, --output-log <file>

Output to log file.

This option tells CTest to write all its output to a log file.

-N,--show-only[=<format>]

Disable actual execution of tests.

This option tells CTest to list the tests that would be run but not actually run them. Useful in conjunction with the -R and -E options.

<format> can be one of the following values.

human
Human-friendly output. This is not guaranteed to be stable. This is the default.
json-v1
Dump the test information in JSON format. See Show as JSON Object Model.
-L <regex>, --label-regex <regex>

Run tests with labels matching regular expression.

This option tells CTest to run only the tests whose labels match the given regular expression.

-R <regex>, --tests-regex <regex>

Run tests matching regular expression.

This option tells CTest to run only the tests whose names match the given regular expression.

-E <regex>, --exclude-regex <regex>

Exclude tests matching regular expression.

This option tells CTest to NOT run the tests whose names match the given regular expression.

-LE <regex>, --label-exclude <regex>

Exclude tests with labels matching regular expression.

This option tells CTest to NOT run the tests whose labels match the given regular expression.

-FA <regex>, --fixture-exclude-any <regex>

Exclude fixtures matching <regex> from automatically adding any tests to the test set.

If a test in the set of tests to be executed requires a particular fixture, that fixture’s setup and cleanup tests would normally be added to the test set automatically. This option prevents adding setup or cleanup tests for fixtures matching the <regex>. Note that all other fixture behavior is retained, including test dependencies and skipping tests that have fixture setup tests that fail.

-FS <regex>, --fixture-exclude-setup <regex>
Same as -FA except only matching setup tests are excluded.
-FC <regex>, --fixture-exclude-cleanup <regex>
Same as -FA except only matching cleanup tests are excluded.
-D <dashboard>, --dashboard <dashboard>

Execute dashboard test.

This option tells CTest to act as a CDash client and perform a dashboard test. All tests are <Mode><Test>, where Mode can be Experimental, Nightly, and Continuous, and Test can be Start, Update, Configure, Build, Test, Coverage, and Submit.

See Dashboard Client.

-D <var>:<type>=<value>

Define a variable for script mode.

Pass in variable values on the command line. Use in conjunction with -S to pass variable values to a dashboard script. Parsing -D arguments as variable values is only attempted if the value following -D does not match any of the known dashboard types.

-M <model>, --test-model <model>

Sets the model for a dashboard.

This option tells CTest to act as a CDash client where the <model> can be Experimental, Nightly, and Continuous. Combining -M and -T is similar to -D.

See Dashboard Client.

-T <action>, --test-action <action>

Sets the dashboard action to perform.

This option tells CTest to act as a CDash client and perform some action such as start, build, test etc. See Dashboard Client Steps for the full list of actions. Combining -M and -T is similar to -D.

See Dashboard Client.

-S <script>, --script <script>

Execute a dashboard for a configuration.

This option tells CTest to load in a configuration script which sets a number of parameters such as the binary and source directories. Then CTest will do what is required to create and run a dashboard. This option basically sets up a dashboard and then runs ctest -D with the appropriate options.

See Dashboard Client.

-SP <script>, --script-new-process <script>

Execute a dashboard for a configuration.

This option does the same operations as -S but it will do them in a separate process. This is primarily useful in cases where the script may modify the environment and you do not want the modified environment to impact other -S scripts.

See Dashboard Client.

-I [Start,End,Stride,test#,test#|Test file], --tests-information

Run a specific number of tests by number.

This option causes CTest to run tests starting at number Start, ending at number End, and incrementing by Stride. Any additional numbers after Stride are considered individual test numbers. Start, End,or stride can be empty. Optionally a file can be given that contains the same syntax as the command line.

-U, --union

Take the Union of -I and -R.

When both -R and -I are specified by default the intersection of tests are run. By specifying -U the union of tests is run instead.

--rerun-failed

Run only the tests that failed previously.

This option tells CTest to perform only the tests that failed during its previous run. When this option is specified, CTest ignores all other options intended to modify the list of tests to run (-L, -R, -E, -LE, -I, etc). In the event that CTest runs and no tests fail, subsequent calls to CTest with the --rerun-failed option will run the set of tests that most recently failed (if any).

--repeat-until-fail <n>

Require each test to run <n> times without failing in order to pass.

This is useful in finding sporadic failures in test cases.

--max-width <width>

Set the max width for a test name to output.

Set the maximum width for each test name to show in the output. This allows the user to widen the output to avoid clipping the test name which can be very annoying.

--interactive-debug-mode [0|1]

Set the interactive mode to 0 or 1.

This option causes CTest to run tests in either an interactive mode or a non-interactive mode. On Windows this means that in non-interactive mode, all system debug pop up windows are blocked. In dashboard mode (Experimental, Nightly, Continuous), the default is non-interactive. When just running tests not for a dashboard the default is to allow popups and interactive debugging.

--no-label-summary

Disable timing summary information for labels.

This option tells CTest not to print summary information for each label associated with the tests run. If there are no labels on the tests, nothing extra is printed.

See Label and Subproject Summary.

--no-subproject-summary

Disable timing summary information for subprojects.

This option tells CTest not to print summary information for each subproject associated with the tests run. If there are no subprojects on the tests, nothing extra is printed.

See Label and Subproject Summary.

--build-and-test See Build and Test Mode.

--test-output-size-passed <size>
Limit the output for passed tests to <size> bytes.
--test-output-size-failed <size>
Limit the output for failed tests to <size> bytes.
--overwrite

Overwrite CTest configuration option.

By default CTest uses configuration options from configuration file. This option will overwrite the configuration option.

--force-new-ctest-process

Run child CTest instances as new processes.

By default CTest will run child CTest instances within the same process. If this behavior is not desired, this argument will enforce new processes for child CTest processes.

--schedule-random

Use a random order for scheduling tests.

This option will run the tests in a random order. It is commonly used to detect implicit dependencies in a test suite.

--submit-index
Legacy option for old Dart2 dashboard server feature. Do not use.
--timeout <seconds>

Set the default test timeout.

This option effectively sets a timeout on all tests that do not already have a timeout set on them via the TIMEOUT property.

--stop-time <time>

Set a time at which all tests should stop running.

Set a real time of day at which all tests should timeout. Example: 7:00:00 -0400. Any time format understood by the curl date parser is accepted. Local time is assumed if no timezone is specified.

--print-labels

Print all available test labels.

This option will not run any tests, it will simply print the list of all labels associated with the test set.

--help,-help,-usage,-h,-H,/?

Print usage information and exit.

Usage describes the basic command line interface and its options.

--version,-version,/V [<f>]

Show program name/version banner and exit.

If a file is specified, the version is written into it. The help is printed to a named <f>ile if given.

--help-full [<f>]

Print all help manuals and exit.

All manuals are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual <man> [<f>]

Print one help manual and exit.

The specified manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual-list [<f>]

List help manuals available and exit.

The list contains all manuals for which help may be obtained by using the --help-manual option followed by a manual name. The help is printed to a named <f>ile if given.

--help-command <cmd> [<f>]

Print help for one command and exit.

The cmake-commands(7) manual entry for <cmd> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-command-list [<f>]

List commands with help available and exit.

The list contains all commands for which help may be obtained by using the --help-command option followed by a command name. The help is printed to a named <f>ile if given.

--help-commands [<f>]

Print cmake-commands manual and exit.

The cmake-commands(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module <mod> [<f>]

Print help for one module and exit.

The cmake-modules(7) manual entry for <mod> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module-list [<f>]

List modules with help available and exit.

The list contains all modules for which help may be obtained by using the --help-module option followed by a module name. The help is printed to a named <f>ile if given.

--help-modules [<f>]

Print cmake-modules manual and exit.

The cmake-modules(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy <cmp> [<f>]

Print help for one policy and exit.

The cmake-policies(7) manual entry for <cmp> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy-list [<f>]

List policies with help available and exit.

The list contains all policies for which help may be obtained by using the --help-policy option followed by a policy name. The help is printed to a named <f>ile if given.

--help-policies [<f>]

Print cmake-policies manual and exit.

The cmake-policies(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property <prop> [<f>]

Print help for one property and exit.

The cmake-properties(7) manual entries for <prop> are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property-list [<f>]

List properties with help available and exit.

The list contains all properties for which help may be obtained by using the --help-property option followed by a property name. The help is printed to a named <f>ile if given.

--help-properties [<f>]

Print cmake-properties manual and exit.

The cmake-properties(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable <var> [<f>]

Print help for one variable and exit.

The cmake-variables(7) manual entry for <var> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable-list [<f>]

List variables with help available and exit.

The list contains all variables for which help may be obtained by using the --help-variable option followed by a variable name. The help is printed to a named <f>ile if given.

--help-variables [<f>]

Print cmake-variables manual and exit.

The cmake-variables(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

Label and Subproject Summary

CTest prints timing summary information for each label and subproject associated with the tests run. The label time summary will not include labels that are mapped to subprojects.

When the PROCESSORS test property is set, CTest will display a weighted test timing result in label and subproject summaries. The time is reported with sec*proc instead of just sec.

The weighted time summary reported for each label or subproject j is computed as:

Weighted Time Summary for Label/Subproject j =
    sum(raw_test_time[j,i] * num_processors[j,i], i=1...num_tests[j])

for labels/subprojects j=1...total

where:

  • raw_test_time[j,i]: Wall-clock time for the ith test for the jth label or subproject
  • num_processors[j,i]: Value of the CTest PROCESSORS property for the ith test for the jth label or subproject
  • num_tests[j]: Number of tests associated with the jth label or subproject
  • total: Total number of labels or subprojects that have at least one test run

Therefore, the weighted time summary for each label or subproject represents the amount of time that CTest gave to run the tests for each label or subproject and gives a good representation of the total expense of the tests for each label or subproject when compared to other labels or subprojects.

For example, if “SubprojectA” showed “100 sec*proc” and “SubprojectB” showed “10 sec*proc”, then CTest allocated approximately 10 times the CPU/core time to run the tests for “SubprojectA” than for “SubprojectB” (e.g. so if effort is going to be expended to reduce the cost of the test suite for the whole project, then reducing the cost of the test suite for “SubprojectA” would likely have a larger impact than effort to reduce the cost of the test suite for “SubprojectB”).

Build and Test Mode

CTest provides a command-line signature to configure (i.e. run cmake on), build, and/or execute a test:

ctest --build-and-test <path-to-source> <path-to-build>
      --build-generator <generator>
      [<options>...]
      [--build-options <opts>...]
      [--test-command <command> [<args>...]]

The configure and test steps are optional. The arguments to this command line are the source and binary directories. The --build-generator option must be provided to use --build-and-test. If --test-command is specified then that will be run after the build is complete. Other options that affect this mode include:

--build-target

Specify a specific target to build.

If left out the all target is built.

--build-nocmake

Run the build without running cmake first.

Skip the cmake step.

--build-run-dir

Specify directory to run programs from.

Directory where programs will be after it has been compiled.

--build-two-config
Run CMake twice.
--build-exe-dir
Specify the directory for the executable.
--build-generator
Specify the generator to use. See the cmake-generators(7) manual.
--build-generator-platform
Specify the generator-specific platform.
--build-generator-toolset
Specify the generator-specific toolset.
--build-project
Specify the name of the project to build.
--build-makeprogram
Override the make program chosen by CTest with a given one.
--build-noclean
Skip the make clean step.
--build-config-sample
A sample executable to use to determine the configuration that should be used. e.g. Debug/Release/etc.
--build-options
Additional options for configuring the build (i.e. for CMake, not for the build tool). Note that if this is specified, the --build-options keyword and its arguments must be the last option given on the command line, with the possible exception of --test-command.
--test-command
The command to run as the test step with the --build-and-test option. All arguments following this keyword will be assumed to be part of the test command line, so it must be the last option given.
--test-timeout
The time limit in seconds

Dashboard Client

CTest can operate as a client for the CDash software quality dashboard application. As a dashboard client, CTest performs a sequence of steps to configure, build, and test software, and then submits the results to a CDash server. The command-line signature used to submit to CDash is:

ctest (-D <dashboard> | -M <model> -T <action> | -S <script> | -SP <script>)
      [-- <dashboard-options>...]

Options for Dashboard Client include:

--track <track>

Specify the track to submit dashboard to

Submit dashboard to specified track instead of default one. By default, the dashboard is submitted to Nightly, Experimental, or Continuous track, but by specifying this option, the track can be arbitrary.

-A <file>, --add-notes <file>

Add a notes file with submission.

This option tells CTest to include a notes file when submitting dashboard.

--tomorrow-tag

Nightly or experimental starts with next day tag.

This is useful if the build will not finish in one day.

--extra-submit <file>[;<file>]

Submit extra files to the dashboard.

This option will submit extra files to the dashboard.

--http1.0

Submit using HTTP 1.0.

This option will force CTest to use HTTP 1.0 to submit files to the dashboard, instead of HTTP 1.1.

--no-compress-output

Do not compress test output when submitting.

This flag will turn off automatic compression of test output. Use this to maintain compatibility with an older version of CDash which doesn’t support compressed test output.

Dashboard Client Steps

CTest defines an ordered list of testing steps of which some or all may be run as a dashboard client:

Start
Start a new dashboard submission to be composed of results recorded by the following steps. See the CTest Start Step section below.
Update
Update the source tree from its version control repository. Record the old and new versions and the list of updated source files. See the CTest Update Step section below.
Configure
Configure the software by running a command in the build tree. Record the configuration output log. See the CTest Configure Step section below.
Build
Build the software by running a command in the build tree. Record the build output log and detect warnings and errors. See the CTest Build Step section below.
Test
Test the software by loading a CTestTestfile.cmake from the build tree and executing the defined tests. Record the output and result of each test. See the CTest Test Step section below.
Coverage
Compute coverage of the source code by running a coverage analysis tool and recording its output. See the CTest Coverage Step section below.
MemCheck
Run the software test suite through a memory check tool. Record the test output, results, and issues reported by the tool. See the CTest MemCheck Step section below.
Submit
Submit results recorded from other testing steps to the software quality dashboard server. See the CTest Submit Step section below.

Dashboard Client Modes

CTest defines three modes of operation as a dashboard client:

Nightly
This mode is intended to be invoked once per day, typically at night. It enables the Start, Update, Configure, Build, Test, Coverage, and Submit steps by default. Selected steps run even if the Update step reports no changes to the source tree.
Continuous
This mode is intended to be invoked repeatedly throughout the day. It enables the Start, Update, Configure, Build, Test, Coverage, and Submit steps by default, but exits after the Update step if it reports no changes to the source tree.
Experimental
This mode is intended to be invoked by a developer to test local changes. It enables the Start, Configure, Build, Test, Coverage, and Submit steps by default.

Dashboard Client via CTest Command-Line

CTest can perform testing on an already-generated build tree. Run the ctest command with the current working directory set to the build tree and use one of these signatures:

ctest -D <mode>[<step>]
ctest -M <mode> [ -T <step> ]...

The <mode> must be one of the above Dashboard Client Modes, and each <step> must be one of the above Dashboard Client Steps.

CTest reads the Dashboard Client Configuration settings from a file in the build tree called either CTestConfiguration.ini or DartConfiguration.tcl (the names are historical). The format of the file is:

# Lines starting in '#' are comments.
# Other non-blank lines are key-value pairs.
<setting>: <value>

where <setting> is the setting name and <value> is the setting value.

In build trees generated by CMake, this configuration file is generated by the CTest module if included by the project. The module uses variables to obtain a value for each setting as documented with the settings below.

Dashboard Client via CTest Script

CTest can perform testing driven by a cmake-language(7) script that creates and maintains the source and build tree as well as performing the testing steps. Run the ctest command with the current working directory set outside of any build tree and use one of these signatures:

ctest -S <script>
ctest -SP <script>

The <script> file must call CTest Commands commands to run testing steps explicitly as documented below. The commands obtain Dashboard Client Configuration settings from their arguments or from variables set in the script.

Dashboard Client Configuration

The Dashboard Client Steps may be configured by named settings as documented in the following sections.

CTest Start Step

Start a new dashboard submission to be composed of results recorded by the following steps.

In a CTest Script, the ctest_start() command runs this step. Arguments to the command may specify some of the step settings. The command first runs the command-line specified by the CTEST_CHECKOUT_COMMAND variable, if set, to initialize the source directory.

Configuration settings include:

BuildDirectory

The full path to the project build tree.

  • CTest Script variable: CTEST_BINARY_DIRECTORY
  • CTest module variable: PROJECT_BINARY_DIR
SourceDirectory

The full path to the project source tree.

  • CTest Script variable: CTEST_SOURCE_DIRECTORY
  • CTest module variable: PROJECT_SOURCE_DIR

CTest Update Step

In a CTest Script, the ctest_update() command runs this step. Arguments to the command may specify some of the step settings.

Configuration settings to specify the version control tool include:

BZRCommand

bzr command-line tool to use if source tree is managed by Bazaar.

  • CTest Script variable: CTEST_BZR_COMMAND
  • CTest module variable: none
BZRUpdateOptions

Command-line options to the BZRCommand when updating the source.

  • CTest Script variable: CTEST_BZR_UPDATE_OPTIONS
  • CTest module variable: none
CVSCommand

cvs command-line tool to use if source tree is managed by CVS.

  • CTest Script variable: CTEST_CVS_COMMAND
  • CTest module variable: CVSCOMMAND
CVSUpdateOptions

Command-line options to the CVSCommand when updating the source.

  • CTest Script variable: CTEST_CVS_UPDATE_OPTIONS
  • CTest module variable: CVS_UPDATE_OPTIONS
GITCommand

git command-line tool to use if source tree is managed by Git.

  • CTest Script variable: CTEST_GIT_COMMAND
  • CTest module variable: GITCOMMAND

The source tree is updated by git fetch followed by git reset --hard to the FETCH_HEAD. The result is the same as git pull except that any local moficiations are overwritten. Use GITUpdateCustom to specify a different approach.

GITInitSubmodules

If set, CTest will update the repository’s submodules before updating.

  • CTest Script variable: CTEST_GIT_INIT_SUBMODULES
  • CTest module variable: CTEST_GIT_INIT_SUBMODULES
GITUpdateCustom

Specify a custom command line (as a semicolon-separated list) to run in the source tree (Git work tree) to update it instead of running the GITCommand.

  • CTest Script variable: CTEST_GIT_UPDATE_CUSTOM
  • CTest module variable: CTEST_GIT_UPDATE_CUSTOM
GITUpdateOptions

Command-line options to the GITCommand when updating the source.

  • CTest Script variable: CTEST_GIT_UPDATE_OPTIONS
  • CTest module variable: GIT_UPDATE_OPTIONS
HGCommand

hg command-line tool to use if source tree is managed by Mercurial.

  • CTest Script variable: CTEST_HG_COMMAND
  • CTest module variable: none
HGUpdateOptions

Command-line options to the HGCommand when updating the source.

  • CTest Script variable: CTEST_HG_UPDATE_OPTIONS
  • CTest module variable: none
P4Client

Value of the -c option to the P4Command.

  • CTest Script variable: CTEST_P4_CLIENT
  • CTest module variable: CTEST_P4_CLIENT
P4Command

p4 command-line tool to use if source tree is managed by Perforce.

  • CTest Script variable: CTEST_P4_COMMAND
  • CTest module variable: P4COMMAND
P4Options

Command-line options to the P4Command for all invocations.

  • CTest Script variable: CTEST_P4_OPTIONS
  • CTest module variable: CTEST_P4_OPTIONS
P4UpdateCustom

Specify a custom command line (as a semicolon-separated list) to run in the source tree (Perforce tree) to update it instead of running the P4Command.

  • CTest Script variable: none
  • CTest module variable: CTEST_P4_UPDATE_CUSTOM
P4UpdateOptions

Command-line options to the P4Command when updating the source.

  • CTest Script variable: CTEST_P4_UPDATE_OPTIONS
  • CTest module variable: CTEST_P4_UPDATE_OPTIONS
SVNCommand

svn command-line tool to use if source tree is managed by Subversion.

  • CTest Script variable: CTEST_SVN_COMMAND
  • CTest module variable: SVNCOMMAND
SVNOptions

Command-line options to the SVNCommand for all invocations.

  • CTest Script variable: CTEST_SVN_OPTIONS
  • CTest module variable: CTEST_SVN_OPTIONS
SVNUpdateOptions

Command-line options to the SVNCommand when updating the source.

  • CTest Script variable: CTEST_SVN_UPDATE_OPTIONS
  • CTest module variable: SVN_UPDATE_OPTIONS
UpdateCommand

Specify the version-control command-line tool to use without detecting the VCS that manages the source tree.

  • CTest Script variable: CTEST_UPDATE_COMMAND
  • CTest module variable: <VCS>COMMAND when UPDATE_TYPE is <vcs>, else UPDATE_COMMAND
UpdateOptions

Command-line options to the UpdateCommand.

  • CTest Script variable: CTEST_UPDATE_OPTIONS
  • CTest module variable: <VCS>_UPDATE_OPTIONS when UPDATE_TYPE is <vcs>, else UPDATE_OPTIONS
UpdateType

Specify the version-control system that manages the source tree if it cannot be detected automatically. The value may be bzr, cvs, git, hg, p4, or svn.

  • CTest Script variable: none, detected from source tree
  • CTest module variable: UPDATE_TYPE if set, else CTEST_UPDATE_TYPE
UpdateVersionOnly

Specify that you want the version control update command to only discover the current version that is checked out, and not to update to a different version.

  • CTest Script variable: CTEST_UPDATE_VERSION_ONLY

Additional configuration settings include:

NightlyStartTime

In the Nightly dashboard mode, specify the “nightly start time”. With centralized version control systems (cvs and svn), the Update step checks out the version of the software as of this time so that multiple clients choose a common version to test. This is not well-defined in distributed version-control systems so the setting is ignored.

  • CTest Script variable: CTEST_NIGHTLY_START_TIME
  • CTest module variable: NIGHTLY_START_TIME if set, else CTEST_NIGHTLY_START_TIME

CTest Configure Step

In a CTest Script, the ctest_configure() command runs this step. Arguments to the command may specify some of the step settings.

Configuration settings include:

ConfigureCommand

Command-line to launch the software configuration process. It will be executed in the location specified by the BuildDirectory setting.

  • CTest Script variable: CTEST_CONFIGURE_COMMAND
  • CTest module variable: CMAKE_COMMAND followed by PROJECT_SOURCE_DIR
LabelsForSubprojects

Specify a semicolon-separated list of labels that will be treated as subprojects. This mapping will be passed on to CDash when configure, test or build results are submitted.

  • CTest Script variable: CTEST_LABELS_FOR_SUBPROJECTS
  • CTest module variable: CTEST_LABELS_FOR_SUBPROJECTS

See Label and Subproject Summary.

CTest Build Step

In a CTest Script, the ctest_build() command runs this step. Arguments to the command may specify some of the step settings.

Configuration settings include:

DefaultCTestConfigurationType

When the build system to be launched allows build-time selection of the configuration (e.g. Debug, Release), this specifies the default configuration to be built when no -C option is given to the ctest command. The value will be substituted into the value of MakeCommand to replace the literal string ${CTEST_CONFIGURATION_TYPE} if it appears.

  • CTest Script variable: CTEST_CONFIGURATION_TYPE
  • CTest module variable: DEFAULT_CTEST_CONFIGURATION_TYPE, initialized by the CMAKE_CONFIG_TYPE environment variable
LabelsForSubprojects

Specify a semicolon-separated list of labels that will be treated as subprojects. This mapping will be passed on to CDash when configure, test or build results are submitted.

  • CTest Script variable: CTEST_LABELS_FOR_SUBPROJECTS
  • CTest module variable: CTEST_LABELS_FOR_SUBPROJECTS

See Label and Subproject Summary.

MakeCommand

Command-line to launch the software build process. It will be executed in the location specified by the BuildDirectory setting.

  • CTest Script variable: CTEST_BUILD_COMMAND
  • CTest module variable: MAKECOMMAND, initialized by the build_command() command
UseLaunchers

For build trees generated by CMake using one of the Makefile Generators or the Ninja generator, specify whether the CTEST_USE_LAUNCHERS feature is enabled by the CTestUseLaunchers module (also included by the CTest module). When enabled, the generated build system wraps each invocation of the compiler, linker, or custom command line with a “launcher” that communicates with CTest via environment variables and files to report granular build warning and error information. Otherwise, CTest must “scrape” the build output log for diagnostics.

  • CTest Script variable: CTEST_USE_LAUNCHERS
  • CTest module variable: CTEST_USE_LAUNCHERS

CTest Test Step

In a CTest Script, the ctest_test() command runs this step. Arguments to the command may specify some of the step settings.

Configuration settings include:

LabelsForSubprojects

Specify a semicolon-separated list of labels that will be treated as subprojects. This mapping will be passed on to CDash when configure, test or build results are submitted.

  • CTest Script variable: CTEST_LABELS_FOR_SUBPROJECTS
  • CTest module variable: CTEST_LABELS_FOR_SUBPROJECTS

See Label and Subproject Summary.

TestLoad

While running tests in parallel (e.g. with -j), try not to start tests when they may cause the CPU load to pass above a given threshold.

  • CTest Script variable: CTEST_TEST_LOAD
  • CTest module variable: CTEST_TEST_LOAD
TimeOut

The default timeout for each test if not specified by the TIMEOUT test property.

  • CTest Script variable: CTEST_TEST_TIMEOUT
  • CTest module variable: DART_TESTING_TIMEOUT

CTest Coverage Step

In a CTest Script, the ctest_coverage() command runs this step. Arguments to the command may specify some of the step settings.

Configuration settings include:

CoverageCommand

Command-line tool to perform software coverage analysis. It will be executed in the location specified by the BuildDirectory setting.

  • CTest Script variable: CTEST_COVERAGE_COMMAND
  • CTest module variable: COVERAGE_COMMAND
CoverageExtraFlags

Specify command-line options to the CoverageCommand tool.

  • CTest Script variable: CTEST_COVERAGE_EXTRA_FLAGS
  • CTest module variable: COVERAGE_EXTRA_FLAGS

These options are the first arguments passed to CoverageCommand.

CTest MemCheck Step

In a CTest Script, the ctest_memcheck() command runs this step. Arguments to the command may specify some of the step settings.

Configuration settings include:

MemoryCheckCommand

Command-line tool to perform dynamic analysis. Test command lines will be launched through this tool.

  • CTest Script variable: CTEST_MEMORYCHECK_COMMAND
  • CTest module variable: MEMORYCHECK_COMMAND
MemoryCheckCommandOptions

Specify command-line options to the MemoryCheckCommand tool. They will be placed prior to the test command line.

  • CTest Script variable: CTEST_MEMORYCHECK_COMMAND_OPTIONS
  • CTest module variable: MEMORYCHECK_COMMAND_OPTIONS
MemoryCheckType

Specify the type of memory checking to perform.

  • CTest Script variable: CTEST_MEMORYCHECK_TYPE
  • CTest module variable: MEMORYCHECK_TYPE
MemoryCheckSanitizerOptions

Specify options to sanitizers when running with a sanitize-enabled build.

  • CTest Script variable: CTEST_MEMORYCHECK_SANITIZER_OPTIONS
  • CTest module variable: MEMORYCHECK_SANITIZER_OPTIONS
MemoryCheckSuppressionFile

Specify a file containing suppression rules for the MemoryCheckCommand tool. It will be passed with options appropriate to the tool.

  • CTest Script variable: CTEST_MEMORYCHECK_SUPPRESSIONS_FILE
  • CTest module variable: MEMORYCHECK_SUPPRESSIONS_FILE

Additional configuration settings include:

BoundsCheckerCommand

Specify a MemoryCheckCommand that is known to be command-line compatible with Bounds Checker.

  • CTest Script variable: none
  • CTest module variable: none
PurifyCommand

Specify a MemoryCheckCommand that is known to be command-line compatible with Purify.

  • CTest Script variable: none
  • CTest module variable: PURIFYCOMMAND
ValgrindCommand

Specify a MemoryCheckCommand that is known to be command-line compatible with Valgrind.

  • CTest Script variable: none
  • CTest module variable: VALGRIND_COMMAND
ValgrindCommandOptions

Specify command-line options to the ValgrindCommand tool. They will be placed prior to the test command line.

  • CTest Script variable: none
  • CTest module variable: VALGRIND_COMMAND_OPTIONS

CTest Submit Step

In a CTest Script, the ctest_submit() command runs this step. Arguments to the command may specify some of the step settings.

Configuration settings include:

BuildName

Describe the dashboard client platform with a short string. (Operating system, compiler, etc.)

  • CTest Script variable: CTEST_BUILD_NAME
  • CTest module variable: BUILDNAME
CDashVersion

Legacy option. Not used.

  • CTest Script variable: none, detected from server
  • CTest module variable: CTEST_CDASH_VERSION
CTestSubmitRetryCount

Specify a number of attempts to retry submission on network failure.

  • CTest Script variable: none, use the ctest_submit() RETRY_COUNT option.
  • CTest module variable: CTEST_SUBMIT_RETRY_COUNT
CTestSubmitRetryDelay

Specify a delay before retrying submission on network failure.

  • CTest Script variable: none, use the ctest_submit() RETRY_DELAY option.
  • CTest module variable: CTEST_SUBMIT_RETRY_DELAY
CurlOptions

Specify a semicolon-separated list of options to control the Curl library that CTest uses internally to connect to the server. Possible options are CURLOPT_SSL_VERIFYPEER_OFF and CURLOPT_SSL_VERIFYHOST_OFF.

  • CTest Script variable: CTEST_CURL_OPTIONS
  • CTest module variable: CTEST_CURL_OPTIONS
DropLocation

Legacy option. When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.

  • CTest Script variable: CTEST_DROP_LOCATION
  • CTest module variable: DROP_LOCATION if set, else CTEST_DROP_LOCATION
DropMethod

Legacy option. When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.

  • CTest Script variable: CTEST_DROP_METHOD
  • CTest module variable: DROP_METHOD if set, else CTEST_DROP_METHOD
DropSite

Legacy option. When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.

  • CTest Script variable: CTEST_DROP_SITE
  • CTest module variable: DROP_SITE if set, else CTEST_DROP_SITE
DropSitePassword

Legacy option. When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.

  • CTest Script variable: CTEST_DROP_SITE_PASSWORD
  • CTest module variable: DROP_SITE_PASSWORD if set, else CTEST_DROP_SITE_PASWORD
DropSiteUser

Legacy option. When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.

  • CTest Script variable: CTEST_DROP_SITE_USER
  • CTest module variable: DROP_SITE_USER if set, else CTEST_DROP_SITE_USER
IsCDash

Legacy option. Not used.

  • CTest Script variable: CTEST_DROP_SITE_CDASH
  • CTest module variable: CTEST_DROP_SITE_CDASH
ScpCommand

Legacy option. Not used.

  • CTest Script variable: CTEST_SCP_COMMAND
  • CTest module variable: SCPCOMMAND
Site

Describe the dashboard client host site with a short string. (Hostname, domain, etc.)

  • CTest Script variable: CTEST_SITE
  • CTest module variable: SITE, initialized by the site_name() command
SubmitURL

The http or https URL of the dashboard server to send the submission to.

  • CTest Script variable: CTEST_SUBMIT_URL
  • CTest module variable: SUBMIT_URL if set, else CTEST_SUBMIT_URL
TriggerSite

Legacy option. Not used.

  • CTest Script variable: CTEST_TRIGGER_SITE
  • CTest module variable: TRIGGER_SITE if set, else CTEST_TRIGGER_SITE

Show as JSON Object Model

When the --show-only=json-v1 command line option is given, the test information is output in JSON format. Version 1.0 of the JSON object model is defined as follows:

kind
The string “ctestInfo”.
version

A JSON object specifying the version components. Its members are

major
A non-negative integer specifying the major version component.
minor
A non-negative integer specifying the minor version component.
backtraceGraph

JSON object representing backtrace information with the following members:

commands
List of command names.
files
List of file names.
nodes

List of node JSON objects with members:

command
Index into the commands member of the backtraceGraph.
file
Index into the files member of the backtraceGraph.
line
Line number in the file where the backtrace was added.
parent
Index into the nodes member of the backtraceGraph representing the parent in the graph.
tests

A JSON array listing information about each test. Each entry is a JSON object with members:

name
Test name.
config
Configuration that the test can run on. Empty string means any config.
command
List where the first element is the test command and the remaining elements are the command arguments.
backtrace
Index into the nodes member of the backtraceGraph.
properties
Test properties. Can contain keys for each of the supported test properties.

See Also

The following resources are available to get help using CMake:

Home Page

https://cmake.org

The primary starting point for learning about CMake.

Online Documentation and Community Resources

https://cmake.org/documentation

Links to available documentation and community resources may be found on this web page.

Mailing List

https://cmake.org/mailing-lists

For help and discussion about using cmake, a mailing list is provided at cmake@cmake.org. The list is member-post-only but one may sign up on the CMake web page. Please first read the full documentation at https://cmake.org before posting questions to the list.

Navigation

  • index
  • next |


cpack(1) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cpack(1)

Synopsis

cpack [<options>]

Description

The cpack executable is the CMake packaging program. It generates installers and source packages in a variety of formats.

For each installer or package format, cpack has a specific backend, called “generator”. A generator is responsible for generating the required inputs and invoking the specific package creation tools. These installer or package generators are not to be confused with the makefile generators of the cmake command.

All supported generators are specified in the cpack-generators manual. The command cpack --help prints a list of generators supported for the target platform. Which of them are to be used can be selected through the CPACK_GENERATOR variable or through the command-line option -G.

The cpack program is steered by a configuration file written in the CMake language. Unless chosen differently through the command-line option --config, the file CPackConfig.cmake in the current directory is used.

In the standard CMake workflow, the file CPackConfig.cmake is generated by the cmake executable, provided the CPack module is included by the project’s CMakeLists.txt file.

Options

-G <generators>
<generators> is a semicolon-separated list of generator names. cpack will iterate through this list and produce package(s) in that generator’s format according to the details provided in the CPackConfig.cmake configuration file. If this option is not given, the CPACK_GENERATOR variable determines the default set of generators that will be used.
-C <Configuration>
Specify the project configuration to be packaged (e.g. Debug, Release, etc.). When the CMake project uses a multi-configuration generator such as Xcode or Visual Studio, this option is needed to tell cpack which built executables to include in the package.
-D <var>=<value>
Set a CPack variable. This will override any value set for <var> in the input file read by cpack.
--config <configFile>
Specify the configuration file read by cpack to provide the packaging details. By default, CPackConfig.cmake in the current directory will be used.
--verbose,-V
Run cpack with verbose output. This can be used to show more details from the package generation tools and is suitable for project developers.
--debug
Run cpack with debug output. This option is intended mainly for the developers of cpack itself and is not normally needed by project developers.
--trace
Put the underlying cmake scripts in trace mode.
--trace-expand
Put the underlying cmake scripts in expanded trace mode.
-P <packageName>
Override/define the value of the CPACK_PACKAGE_NAME variable used for packaging. Any value set for this variable in the CPackConfig.cmake file will then be ignored.
-R <packageVersion>
Override/define the value of the CPACK_PACKAGE_VERSION variable used for packaging. It will override a value set in the CPackConfig.cmake file or one automatically computed from CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH.
-B <packageDirectory>
Override/define CPACK_PACKAGE_DIRECTORY, which controls the directory where CPack will perform its packaging work. The resultant package(s) will be created at this location by default and a _CPack_Packages subdirectory will also be created below this directory to use as a working area during package creation.
--vendor <vendorName>
Override/define CPACK_PACKAGE_VENDOR.
--help,-help,-usage,-h,-H,/?

Print usage information and exit.

Usage describes the basic command line interface and its options.

--version,-version,/V [<f>]

Show program name/version banner and exit.

If a file is specified, the version is written into it. The help is printed to a named <f>ile if given.

--help-full [<f>]

Print all help manuals and exit.

All manuals are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual <man> [<f>]

Print one help manual and exit.

The specified manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual-list [<f>]

List help manuals available and exit.

The list contains all manuals for which help may be obtained by using the --help-manual option followed by a manual name. The help is printed to a named <f>ile if given.

--help-command <cmd> [<f>]

Print help for one command and exit.

The cmake-commands(7) manual entry for <cmd> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-command-list [<f>]

List commands with help available and exit.

The list contains all commands for which help may be obtained by using the --help-command option followed by a command name. The help is printed to a named <f>ile if given.

--help-commands [<f>]

Print cmake-commands manual and exit.

The cmake-commands(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module <mod> [<f>]

Print help for one module and exit.

The cmake-modules(7) manual entry for <mod> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module-list [<f>]

List modules with help available and exit.

The list contains all modules for which help may be obtained by using the --help-module option followed by a module name. The help is printed to a named <f>ile if given.

--help-modules [<f>]

Print cmake-modules manual and exit.

The cmake-modules(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy <cmp> [<f>]

Print help for one policy and exit.

The cmake-policies(7) manual entry for <cmp> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy-list [<f>]

List policies with help available and exit.

The list contains all policies for which help may be obtained by using the --help-policy option followed by a policy name. The help is printed to a named <f>ile if given.

--help-policies [<f>]

Print cmake-policies manual and exit.

The cmake-policies(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property <prop> [<f>]

Print help for one property and exit.

The cmake-properties(7) manual entries for <prop> are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property-list [<f>]

List properties with help available and exit.

The list contains all properties for which help may be obtained by using the --help-property option followed by a property name. The help is printed to a named <f>ile if given.

--help-properties [<f>]

Print cmake-properties manual and exit.

The cmake-properties(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable <var> [<f>]

Print help for one variable and exit.

The cmake-variables(7) manual entry for <var> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable-list [<f>]

List variables with help available and exit.

The list contains all variables for which help may be obtained by using the --help-variable option followed by a variable name. The help is printed to a named <f>ile if given.

--help-variables [<f>]

Print cmake-variables manual and exit.

The cmake-variables(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

See Also

The following resources are available to get help using CMake:

Home Page

https://cmake.org

The primary starting point for learning about CMake.

Online Documentation and Community Resources

https://cmake.org/documentation

Links to available documentation and community resources may be found on this web page.

Mailing List

https://cmake.org/mailing-lists

For help and discussion about using cmake, a mailing list is provided at cmake@cmake.org. The list is member-post-only but one may sign up on the CMake web page. Please first read the full documentation at https://cmake.org before posting questions to the list.

Navigation


cmake-gui(1) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-gui(1)

Synopsis

cmake-gui [<options>]
cmake-gui [<options>] {<path-to-source> | <path-to-existing-build>}
cmake-gui [<options>] -S <path-to-source> -B <path-to-build>

Description

The cmake-gui executable is the CMake GUI. Project configuration settings may be specified interactively. Brief instructions are provided at the bottom of the window when the program is running.

CMake is a cross-platform build system generator. Projects specify their build process with platform-independent CMake listfiles included in each directory of a source tree with the name CMakeLists.txt. Users build a project by using CMake to generate a build system for a native tool on their platform.

Options

-S <path-to-source>
Path to root directory of the CMake project to build.
-B <path-to-build>

Path to directory which CMake will use as the root of build directory.

If the directory doesn’t already exist CMake will make it.

--help,-help,-usage,-h,-H,/?

Print usage information and exit.

Usage describes the basic command line interface and its options.

--version,-version,/V [<f>]

Show program name/version banner and exit.

If a file is specified, the version is written into it. The help is printed to a named <f>ile if given.

--help-full [<f>]

Print all help manuals and exit.

All manuals are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual <man> [<f>]

Print one help manual and exit.

The specified manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual-list [<f>]

List help manuals available and exit.

The list contains all manuals for which help may be obtained by using the --help-manual option followed by a manual name. The help is printed to a named <f>ile if given.

--help-command <cmd> [<f>]

Print help for one command and exit.

The cmake-commands(7) manual entry for <cmd> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-command-list [<f>]

List commands with help available and exit.

The list contains all commands for which help may be obtained by using the --help-command option followed by a command name. The help is printed to a named <f>ile if given.

--help-commands [<f>]

Print cmake-commands manual and exit.

The cmake-commands(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module <mod> [<f>]

Print help for one module and exit.

The cmake-modules(7) manual entry for <mod> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module-list [<f>]

List modules with help available and exit.

The list contains all modules for which help may be obtained by using the --help-module option followed by a module name. The help is printed to a named <f>ile if given.

--help-modules [<f>]

Print cmake-modules manual and exit.

The cmake-modules(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy <cmp> [<f>]

Print help for one policy and exit.

The cmake-policies(7) manual entry for <cmp> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy-list [<f>]

List policies with help available and exit.

The list contains all policies for which help may be obtained by using the --help-policy option followed by a policy name. The help is printed to a named <f>ile if given.

--help-policies [<f>]

Print cmake-policies manual and exit.

The cmake-policies(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property <prop> [<f>]

Print help for one property and exit.

The cmake-properties(7) manual entries for <prop> are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property-list [<f>]

List properties with help available and exit.

The list contains all properties for which help may be obtained by using the --help-property option followed by a property name. The help is printed to a named <f>ile if given.

--help-properties [<f>]

Print cmake-properties manual and exit.

The cmake-properties(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable <var> [<f>]

Print help for one variable and exit.

The cmake-variables(7) manual entry for <var> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable-list [<f>]

List variables with help available and exit.

The list contains all variables for which help may be obtained by using the --help-variable option followed by a variable name. The help is printed to a named <f>ile if given.

--help-variables [<f>]

Print cmake-variables manual and exit.

The cmake-variables(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

See Also

The following resources are available to get help using CMake:

Home Page

https://cmake.org

The primary starting point for learning about CMake.

Online Documentation and Community Resources

https://cmake.org/documentation

Links to available documentation and community resources may be found on this web page.

Mailing List

https://cmake.org/mailing-lists

For help and discussion about using cmake, a mailing list is provided at cmake@cmake.org. The list is member-post-only but one may sign up on the CMake web page. Please first read the full documentation at https://cmake.org before posting questions to the list.


ccmake(1) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

ccmake(1)

Synopsis

ccmake [<options>] {<path-to-source> | <path-to-existing-build>}

Description

The ccmake executable is the CMake curses interface. Project configuration settings may be specified interactively through this GUI. Brief instructions are provided at the bottom of the terminal when the program is running.

CMake is a cross-platform build system generator. Projects specify their build process with platform-independent CMake listfiles included in each directory of a source tree with the name CMakeLists.txt. Users build a project by using CMake to generate a build system for a native tool on their platform.

Options

-S <path-to-source>
Path to root directory of the CMake project to build.
-B <path-to-build>

Path to directory which CMake will use as the root of build directory.

If the directory doesn’t already exist CMake will make it.

-C <initial-cache>

Pre-load a script to populate the cache.

When cmake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project. This option may be used to specify a file from which to load cache entries before the first pass through the project’s cmake listfiles. The loaded entries take priority over the project’s default values. The given file should be a CMake script containing SET commands that use the CACHE option, not a cache-format file.

-D <var>:<type>=<value>, -D <var>=<value>

Create or update a cmake cache entry.

When cmake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project. This option may be used to specify a setting that takes priority over the project’s default value. The option may be repeated for as many cache entries as desired.

If the :<type> portion is given it must be one of the types specified by the set() command documentation for its CACHE signature. If the :<type> portion is omitted the entry will be created with no type if it does not exist with a type already. If a command in the project sets the type to PATH or FILEPATH then the <value> will be converted to an absolute path.

This option may also be given as a single argument: -D<var>:<type>=<value> or -D<var>=<value>.

-U <globbing_expr>

Remove matching entries from CMake cache.

This option may be used to remove one or more variables from the CMakeCache.txt file, globbing expressions using * and ? are supported. The option may be repeated for as many cache entries as desired.

Use with care, you can make your CMakeCache.txt non-working.

-G <generator-name>

Specify a build system generator.

CMake may support multiple native build systems on certain platforms. A generator is responsible for generating a particular build system. Possible generator names are specified in the cmake-generators(7) manual.

-T <toolset-spec>

Toolset specification for the generator, if supported.

Some CMake generators support a toolset specification to tell the native build system how to choose a compiler. See the CMAKE_GENERATOR_TOOLSET variable for details.

-A <platform-name>

Specify platform name if supported by generator.

Some CMake generators support a platform name to be given to the native build system to choose a compiler or SDK. See the CMAKE_GENERATOR_PLATFORM variable for details.

-Wno-dev

Suppress developer warnings.

Suppress warnings that are meant for the author of the CMakeLists.txt files. By default this will also turn off deprecation warnings.

-Wdev

Enable developer warnings.

Enable warnings that are meant for the author of the CMakeLists.txt files. By default this will also turn on deprecation warnings.

-Werror=dev

Make developer warnings errors.

Make warnings that are meant for the author of the CMakeLists.txt files errors. By default this will also turn on deprecated warnings as errors.

-Wno-error=dev

Make developer warnings not errors.

Make warnings that are meant for the author of the CMakeLists.txt files not errors. By default this will also turn off deprecated warnings as errors.

-Wdeprecated

Enable deprecated functionality warnings.

Enable warnings for usage of deprecated functionality, that are meant for the author of the CMakeLists.txt files.

-Wno-deprecated

Suppress deprecated functionality warnings.

Suppress warnings for usage of deprecated functionality, that are meant for the author of the CMakeLists.txt files.

-Werror=deprecated

Make deprecated macro and function warnings errors.

Make warnings for usage of deprecated macros and functions, that are meant for the author of the CMakeLists.txt files, errors.

-Wno-error=deprecated

Make deprecated macro and function warnings not errors.

Make warnings for usage of deprecated macros and functions, that are meant for the author of the CMakeLists.txt files, not errors.

--help,-help,-usage,-h,-H,/?

Print usage information and exit.

Usage describes the basic command line interface and its options.

--version,-version,/V [<f>]

Show program name/version banner and exit.

If a file is specified, the version is written into it. The help is printed to a named <f>ile if given.

--help-full [<f>]

Print all help manuals and exit.

All manuals are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual <man> [<f>]

Print one help manual and exit.

The specified manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-manual-list [<f>]

List help manuals available and exit.

The list contains all manuals for which help may be obtained by using the --help-manual option followed by a manual name. The help is printed to a named <f>ile if given.

--help-command <cmd> [<f>]

Print help for one command and exit.

The cmake-commands(7) manual entry for <cmd> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-command-list [<f>]

List commands with help available and exit.

The list contains all commands for which help may be obtained by using the --help-command option followed by a command name. The help is printed to a named <f>ile if given.

--help-commands [<f>]

Print cmake-commands manual and exit.

The cmake-commands(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module <mod> [<f>]

Print help for one module and exit.

The cmake-modules(7) manual entry for <mod> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-module-list [<f>]

List modules with help available and exit.

The list contains all modules for which help may be obtained by using the --help-module option followed by a module name. The help is printed to a named <f>ile if given.

--help-modules [<f>]

Print cmake-modules manual and exit.

The cmake-modules(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy <cmp> [<f>]

Print help for one policy and exit.

The cmake-policies(7) manual entry for <cmp> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-policy-list [<f>]

List policies with help available and exit.

The list contains all policies for which help may be obtained by using the --help-policy option followed by a policy name. The help is printed to a named <f>ile if given.

--help-policies [<f>]

Print cmake-policies manual and exit.

The cmake-policies(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property <prop> [<f>]

Print help for one property and exit.

The cmake-properties(7) manual entries for <prop> are printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-property-list [<f>]

List properties with help available and exit.

The list contains all properties for which help may be obtained by using the --help-property option followed by a property name. The help is printed to a named <f>ile if given.

--help-properties [<f>]

Print cmake-properties manual and exit.

The cmake-properties(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable <var> [<f>]

Print help for one variable and exit.

The cmake-variables(7) manual entry for <var> is printed in a human-readable text format. The help is printed to a named <f>ile if given.

--help-variable-list [<f>]

List variables with help available and exit.

The list contains all variables for which help may be obtained by using the --help-variable option followed by a variable name. The help is printed to a named <f>ile if given.

--help-variables [<f>]

Print cmake-variables manual and exit.

The cmake-variables(7) manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

See Also

The following resources are available to get help using CMake:

Home Page

https://cmake.org

The primary starting point for learning about CMake.

Online Documentation and Community Resources

https://cmake.org/documentation

Links to available documentation and community resources may be found on this web page.

Mailing List

https://cmake.org/mailing-lists

For help and discussion about using cmake, a mailing list is provided at cmake@cmake.org. The list is member-post-only but one may sign up on the CMake web page. Please first read the full documentation at https://cmake.org before posting questions to the list.


cmake-buildsystem(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-buildsystem(7)

Contents

  • cmake-buildsystem(7)
    • Introduction
    • Binary Targets
      • Binary Executables
      • Binary Library Types
        • Normal Libraries
          • Apple Frameworks
        • Object Libraries
    • Build Specification and Usage Requirements
      • Target Properties
      • Transitive Usage Requirements
      • Compatible Interface Properties
      • Property Origin Debugging
      • Build Specification with Generator Expressions
        • Include Directories and Usage Requirements
      • Link Libraries and Generator Expressions
      • Output Artifacts
        • Runtime Output Artifacts
        • Library Output Artifacts
        • Archive Output Artifacts
      • Directory-Scoped Commands
    • Pseudo Targets
      • Imported Targets
      • Alias Targets
      • Interface Libraries

Introduction

A CMake-based buildsystem is organized as a set of high-level logical targets. Each target corresponds to an executable or library, or is a custom target containing custom commands. Dependencies between the targets are expressed in the buildsystem to determine the build order and the rules for regeneration in response to change.

Binary Targets

Executables and libraries are defined using the add_executable() and add_library() commands. The resulting binary files have appropriate prefixes, suffixes and extensions for the platform targeted. Dependencies between binary targets are expressed using the target_link_libraries() command:

add_library(archive archive.cpp zip.cpp lzma.cpp)
add_executable(zipapp zipapp.cpp)
target_link_libraries(zipapp archive)

archive is defined as a static library – an archive containing objects compiled from archive.cpp, zip.cpp, and lzma.cpp. zipapp is defined as an executable formed by compiling and linking zipapp.cpp. When linking the zipapp executable, the archive static library is linked in.

Binary Executables

The add_executable() command defines an executable target:

add_executable(mytool mytool.cpp)

Commands such as add_custom_command(), which generates rules to be run at build time can transparently use an EXECUTABLE target as a COMMAND executable. The buildsystem rules will ensure that the executable is built before attempting to run the command.

Binary Library Types

Normal Libraries

By default, the add_library() command defines a static library, unless a type is specified. A type may be specified when using the command:

add_library(archive SHARED archive.cpp zip.cpp lzma.cpp)

add_library(archive STATIC archive.cpp zip.cpp lzma.cpp)

The BUILD_SHARED_LIBS variable may be enabled to change the behavior of add_library() to build shared libraries by default.

In the context of the buildsystem definition as a whole, it is largely irrelevant whether particular libraries are SHARED or STATIC – the commands, dependency specifications and other APIs work similarly regardless of the library type. The MODULE library type is dissimilar in that it is generally not linked to – it is not used in the right-hand-side of the target_link_libraries() command. It is a type which is loaded as a plugin using runtime techniques. If the library does not export any unmanaged symbols (e.g. Windows resource DLL, C++/CLI DLL), it is required that the library not be a SHARED library because CMake expects SHARED libraries to export at least one symbol.

add_library(archive MODULE 7z.cpp)
Apple Frameworks

A SHARED library may be marked with the FRAMEWORK target property to create an macOS or iOS Framework Bundle. The MACOSX_FRAMEWORK_IDENTIFIER sets CFBundleIdentifier key and it uniquely identifies the bundle.

add_library(MyFramework SHARED MyFramework.cpp)
set_target_properties(MyFramework PROPERTIES
  FRAMEWORK TRUE
  FRAMEWORK_VERSION A
  MACOSX_FRAMEWORK_IDENTIFIER org.cmake.MyFramework
)

Object Libraries

The OBJECT library type defines a non-archival collection of object files resulting from compiling the given source files. The object files collection may be used as source inputs to other targets:

add_library(archive OBJECT archive.cpp zip.cpp lzma.cpp)

add_library(archiveExtras STATIC $<TARGET_OBJECTS:archive> extras.cpp)

add_executable(test_exe $<TARGET_OBJECTS:archive> test.cpp)

The link (or archiving) step of those other targets will use the object files collection in addition to those from their own sources.

Alternatively, object libraries may be linked into other targets:

add_library(archive OBJECT archive.cpp zip.cpp lzma.cpp)

add_library(archiveExtras STATIC extras.cpp)
target_link_libraries(archiveExtras PUBLIC archive)

add_executable(test_exe test.cpp)
target_link_libraries(test_exe archive)

The link (or archiving) step of those other targets will use the object files from object libraries that are directly linked. Additionally, usage requirements of the object libraries will be honored when compiling sources in those other targets. Furthermore, those usage requirements will propagate transitively to dependents of those other targets.

Object libraries may not be used as the TARGET in a use of the add_custom_command(TARGET) command signature. However, the list of objects can be used by add_custom_command(OUTPUT) or file(GENERATE) by using $<TARGET_OBJECTS:objlib>.

Build Specification and Usage Requirements

The target_include_directories(), target_compile_definitions() and target_compile_options() commands specify the build specifications and the usage requirements of binary targets. The commands populate the INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and COMPILE_OPTIONS target properties respectively, and/or the INTERFACE_INCLUDE_DIRECTORIES, INTERFACE_COMPILE_DEFINITIONS and INTERFACE_COMPILE_OPTIONS target properties.

Each of the commands has a PRIVATE, PUBLIC and INTERFACE mode. The PRIVATE mode populates only the non-INTERFACE_ variant of the target property and the INTERFACE mode populates only the INTERFACE_ variants. The PUBLIC mode populates both variants of the respective target property. Each command may be invoked with multiple uses of each keyword:

target_compile_definitions(archive
  PRIVATE BUILDING_WITH_LZMA
  INTERFACE USING_ARCHIVE_LIB
)

Note that usage requirements are not designed as a way to make downstreams use particular COMPILE_OPTIONS or COMPILE_DEFINITIONS etc for convenience only. The contents of the properties must be requirements, not merely recommendations or convenience.

See the Creating Relocatable Packages section of the cmake-packages(7) manual for discussion of additional care that must be taken when specifying usage requirements while creating packages for redistribution.

Target Properties

The contents of the INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and COMPILE_OPTIONS target properties are used appropriately when compiling the source files of a binary target.

Entries in the INCLUDE_DIRECTORIES are added to the compile line with -I or -isystem prefixes and in the order of appearance in the property value.

Entries in the COMPILE_DEFINITIONS are prefixed with -D or /D and added to the compile line in an unspecified order. The DEFINE_SYMBOL target property is also added as a compile definition as a special convenience case for SHARED and MODULE library targets.

Entries in the COMPILE_OPTIONS are escaped for the shell and added in the order of appearance in the property value. Several compile options have special separate handling, such as POSITION_INDEPENDENT_CODE.

The contents of the INTERFACE_INCLUDE_DIRECTORIES, INTERFACE_COMPILE_DEFINITIONS and INTERFACE_COMPILE_OPTIONS target properties are Usage Requirements – they specify content which consumers must use to correctly compile and link with the target they appear on. For any binary target, the contents of each INTERFACE_ property on each target specified in a target_link_libraries() command is consumed:

set(srcs archive.cpp zip.cpp)
if (LZMA_FOUND)
  list(APPEND srcs lzma.cpp)
endif()
add_library(archive SHARED ${srcs})
if (LZMA_FOUND)
  # The archive library sources are compiled with -DBUILDING_WITH_LZMA
  target_compile_definitions(archive PRIVATE BUILDING_WITH_LZMA)
endif()
target_compile_definitions(archive INTERFACE USING_ARCHIVE_LIB)

add_executable(consumer)
# Link consumer to archive and consume its usage requirements. The consumer
# executable sources are compiled with -DUSING_ARCHIVE_LIB.
target_link_libraries(consumer archive)

Because it is common to require that the source directory and corresponding build directory are added to the INCLUDE_DIRECTORIES, the CMAKE_INCLUDE_CURRENT_DIR variable can be enabled to conveniently add the corresponding directories to the INCLUDE_DIRECTORIES of all targets. The variable CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE can be enabled to add the corresponding directories to the INTERFACE_INCLUDE_DIRECTORIES of all targets. This makes use of targets in multiple different directories convenient through use of the target_link_libraries() command.

Transitive Usage Requirements

The usage requirements of a target can transitively propagate to dependents. The target_link_libraries() command has PRIVATE, INTERFACE and PUBLIC keywords to control the propagation.

add_library(archive archive.cpp)
target_compile_definitions(archive INTERFACE USING_ARCHIVE_LIB)

add_library(serialization serialization.cpp)
target_compile_definitions(serialization INTERFACE USING_SERIALIZATION_LIB)

add_library(archiveExtras extras.cpp)
target_link_libraries(archiveExtras PUBLIC archive)
target_link_libraries(archiveExtras PRIVATE serialization)
# archiveExtras is compiled with -DUSING_ARCHIVE_LIB
# and -DUSING_SERIALIZATION_LIB

add_executable(consumer consumer.cpp)
# consumer is compiled with -DUSING_ARCHIVE_LIB
target_link_libraries(consumer archiveExtras)

Because archive is a PUBLIC dependency of archiveExtras, the usage requirements of it are propagated to consumer too. Because serialization is a PRIVATE dependency of archiveExtras, the usage requirements of it are not propagated to consumer.

Generally, a dependency should be specified in a use of target_link_libraries() with the PRIVATE keyword if it is used by only the implementation of a library, and not in the header files. If a dependency is additionally used in the header files of a library (e.g. for class inheritance), then it should be specified as a PUBLIC dependency. A dependency which is not used by the implementation of a library, but only by its headers should be specified as an INTERFACE dependency. The target_link_libraries() command may be invoked with multiple uses of each keyword:

target_link_libraries(archiveExtras
  PUBLIC archive
  PRIVATE serialization
)

Usage requirements are propagated by reading the INTERFACE_ variants of target properties from dependencies and appending the values to the non-INTERFACE_ variants of the operand. For example, the INTERFACE_INCLUDE_DIRECTORIES of dependencies is read and appended to the INCLUDE_DIRECTORIES of the operand. In cases where order is relevant and maintained, and the order resulting from the target_link_libraries() calls does not allow correct compilation, use of an appropriate command to set the property directly may update the order.

For example, if the linked libraries for a target must be specified in the order lib1 lib2 lib3 , but the include directories must be specified in the order lib3 lib1 lib2:

target_link_libraries(myExe lib1 lib2 lib3)
target_include_directories(myExe
  PRIVATE $<TARGET_PROPERTY:lib3,INTERFACE_INCLUDE_DIRECTORIES>)

Note that care must be taken when specifying usage requirements for targets which will be exported for installation using the install(EXPORT) command. See Creating Packages for more.

Compatible Interface Properties

Some target properties are required to be compatible between a target and the interface of each dependency. For example, the POSITION_INDEPENDENT_CODE target property may specify a boolean value of whether a target should be compiled as position-independent-code, which has platform-specific consequences. A target may also specify the usage requirement INTERFACE_POSITION_INDEPENDENT_CODE to communicate that consumers must be compiled as position-independent-code.

add_executable(exe1 exe1.cpp)
set_property(TARGET exe1 PROPERTY POSITION_INDEPENDENT_CODE ON)

add_library(lib1 SHARED lib1.cpp)
set_property(TARGET lib1 PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE ON)

add_executable(exe2 exe2.cpp)
target_link_libraries(exe2 lib1)

Here, both exe1 and exe2 will be compiled as position-independent-code. lib1 will also be compiled as position-independent-code because that is the default setting for SHARED libraries. If dependencies have conflicting, non-compatible requirements cmake(1) issues a diagnostic:

add_library(lib1 SHARED lib1.cpp)
set_property(TARGET lib1 PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE ON)

add_library(lib2 SHARED lib2.cpp)
set_property(TARGET lib2 PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE OFF)

add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 lib1)
set_property(TARGET exe1 PROPERTY POSITION_INDEPENDENT_CODE OFF)

add_executable(exe2 exe2.cpp)
target_link_libraries(exe2 lib1 lib2)

The lib1 requirement INTERFACE_POSITION_INDEPENDENT_CODE is not “compatible” with the POSITION_INDEPENDENT_CODE property of the exe1 target. The library requires that consumers are built as position-independent-code, while the executable specifies to not built as position-independent-code, so a diagnostic is issued.

The lib1 and lib2 requirements are not “compatible”. One of them requires that consumers are built as position-independent-code, while the other requires that consumers are not built as position-independent-code. Because exe2 links to both and they are in conflict, a diagnostic is issued.

To be “compatible”, the POSITION_INDEPENDENT_CODE property, if set must be either the same, in a boolean sense, as the INTERFACE_POSITION_INDEPENDENT_CODE property of all transitively specified dependencies on which that property is set.

This property of “compatible interface requirement” may be extended to other properties by specifying the property in the content of the COMPATIBLE_INTERFACE_BOOL target property. Each specified property must be compatible between the consuming target and the corresponding property with an INTERFACE_ prefix from each dependency:

add_library(lib1Version2 SHARED lib1_v2.cpp)
set_property(TARGET lib1Version2 PROPERTY INTERFACE_CUSTOM_PROP ON)
set_property(TARGET lib1Version2 APPEND PROPERTY
  COMPATIBLE_INTERFACE_BOOL CUSTOM_PROP
)

add_library(lib1Version3 SHARED lib1_v3.cpp)
set_property(TARGET lib1Version3 PROPERTY INTERFACE_CUSTOM_PROP OFF)

add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 lib1Version2) # CUSTOM_PROP will be ON

add_executable(exe2 exe2.cpp)
target_link_libraries(exe2 lib1Version2 lib1Version3) # Diagnostic

Non-boolean properties may also participate in “compatible interface” computations. Properties specified in the COMPATIBLE_INTERFACE_STRING property must be either unspecified or compare to the same string among all transitively specified dependencies. This can be useful to ensure that multiple incompatible versions of a library are not linked together through transitive requirements of a target:

add_library(lib1Version2 SHARED lib1_v2.cpp)
set_property(TARGET lib1Version2 PROPERTY INTERFACE_LIB_VERSION 2)
set_property(TARGET lib1Version2 APPEND PROPERTY
  COMPATIBLE_INTERFACE_STRING LIB_VERSION
)

add_library(lib1Version3 SHARED lib1_v3.cpp)
set_property(TARGET lib1Version3 PROPERTY INTERFACE_LIB_VERSION 3)

add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 lib1Version2) # LIB_VERSION will be "2"

add_executable(exe2 exe2.cpp)
target_link_libraries(exe2 lib1Version2 lib1Version3) # Diagnostic

The COMPATIBLE_INTERFACE_NUMBER_MAX target property specifies that content will be evaluated numerically and the maximum number among all specified will be calculated:

add_library(lib1Version2 SHARED lib1_v2.cpp)
set_property(TARGET lib1Version2 PROPERTY INTERFACE_CONTAINER_SIZE_REQUIRED 200)
set_property(TARGET lib1Version2 APPEND PROPERTY
  COMPATIBLE_INTERFACE_NUMBER_MAX CONTAINER_SIZE_REQUIRED
)

add_library(lib1Version3 SHARED lib1_v3.cpp)
set_property(TARGET lib1Version3 PROPERTY INTERFACE_CONTAINER_SIZE_REQUIRED 1000)

add_executable(exe1 exe1.cpp)
# CONTAINER_SIZE_REQUIRED will be "200"
target_link_libraries(exe1 lib1Version2)

add_executable(exe2 exe2.cpp)
# CONTAINER_SIZE_REQUIRED will be "1000"
target_link_libraries(exe2 lib1Version2 lib1Version3)

Similarly, the COMPATIBLE_INTERFACE_NUMBER_MIN may be used to calculate the numeric minimum value for a property from dependencies.

Each calculated “compatible” property value may be read in the consumer at generate-time using generator expressions.

Note that for each dependee, the set of properties specified in each compatible interface property must not intersect with the set specified in any of the other properties.

Property Origin Debugging

Because build specifications can be determined by dependencies, the lack of locality of code which creates a target and code which is responsible for setting build specifications may make the code more difficult to reason about. cmake(1) provides a debugging facility to print the origin of the contents of properties which may be determined by dependencies. The properties which can be debugged are listed in the CMAKE_DEBUG_TARGET_PROPERTIES variable documentation:

set(CMAKE_DEBUG_TARGET_PROPERTIES
  INCLUDE_DIRECTORIES
  COMPILE_DEFINITIONS
  POSITION_INDEPENDENT_CODE
  CONTAINER_SIZE_REQUIRED
  LIB_VERSION
)
add_executable(exe1 exe1.cpp)

In the case of properties listed in COMPATIBLE_INTERFACE_BOOL or COMPATIBLE_INTERFACE_STRING, the debug output shows which target was responsible for setting the property, and which other dependencies also defined the property. In the case of COMPATIBLE_INTERFACE_NUMBER_MAX and COMPATIBLE_INTERFACE_NUMBER_MIN, the debug output shows the value of the property from each dependency, and whether the value determines the new extreme.

Build Specification with Generator Expressions

Build specifications may use generator expressions containing content which may be conditional or known only at generate-time. For example, the calculated “compatible” value of a property may be read with the TARGET_PROPERTY expression:

add_library(lib1Version2 SHARED lib1_v2.cpp)
set_property(TARGET lib1Version2 PROPERTY
  INTERFACE_CONTAINER_SIZE_REQUIRED 200)
set_property(TARGET lib1Version2 APPEND PROPERTY
  COMPATIBLE_INTERFACE_NUMBER_MAX CONTAINER_SIZE_REQUIRED
)

add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 lib1Version2)
target_compile_definitions(exe1 PRIVATE
    CONTAINER_SIZE=$<TARGET_PROPERTY:CONTAINER_SIZE_REQUIRED>
)

In this case, the exe1 source files will be compiled with -DCONTAINER_SIZE=200.

Configuration determined build specifications may be conveniently set using the CONFIG generator expression.

target_compile_definitions(exe1 PRIVATE
    $<$<CONFIG:Debug>:DEBUG_BUILD>
)

The CONFIG parameter is compared case-insensitively with the configuration being built. In the presence of IMPORTED targets, the content of MAP_IMPORTED_CONFIG_DEBUG is also accounted for by this expression.

Some buildsystems generated by cmake(1) have a predetermined build-configuration set in the CMAKE_BUILD_TYPE variable. The buildsystem for the IDEs such as Visual Studio and Xcode are generated independent of the build-configuration, and the actual build configuration is not known until build-time. Therefore, code such as

string(TOLOWER ${CMAKE_BUILD_TYPE} _type)
if (_type STREQUAL debug)
  target_compile_definitions(exe1 PRIVATE DEBUG_BUILD)
endif()

may appear to work for Makefile based and Ninja generators, but is not portable to IDE generators. Additionally, the IMPORTED configuration-mappings are not accounted for with code like this, so it should be avoided.

The unary TARGET_PROPERTY generator expression and the TARGET_POLICY generator expression are evaluated with the consuming target context. This means that a usage requirement specification may be evaluated differently based on the consumer:

add_library(lib1 lib1.cpp)
target_compile_definitions(lib1 INTERFACE
  $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,EXECUTABLE>:LIB1_WITH_EXE>
  $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,SHARED_LIBRARY>:LIB1_WITH_SHARED_LIB>
  $<$<TARGET_POLICY:CMP0041>:CONSUMER_CMP0041_NEW>
)

add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 lib1)

cmake_policy(SET CMP0041 NEW)

add_library(shared_lib shared_lib.cpp)
target_link_libraries(shared_lib lib1)

The exe1 executable will be compiled with -DLIB1_WITH_EXE, while the shared_lib shared library will be compiled with -DLIB1_WITH_SHARED_LIB and -DCONSUMER_CMP0041_NEW, because policy CMP0041 is NEW at the point where the shared_lib target is created.

The BUILD_INTERFACE expression wraps requirements which are only used when consumed from a target in the same buildsystem, or when consumed from a target exported to the build directory using the export() command. The INSTALL_INTERFACE expression wraps requirements which are only used when consumed from a target which has been installed and exported with the install(EXPORT) command:

add_library(ClimbingStats climbingstats.cpp)
target_compile_definitions(ClimbingStats INTERFACE
  $<BUILD_INTERFACE:ClimbingStats_FROM_BUILD_LOCATION>
  $<INSTALL_INTERFACE:ClimbingStats_FROM_INSTALLED_LOCATION>
)
install(TARGETS ClimbingStats EXPORT libExport ${InstallArgs})
install(EXPORT libExport NAMESPACE Upstream::
        DESTINATION lib/cmake/ClimbingStats)
export(EXPORT libExport NAMESPACE Upstream::)

add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 ClimbingStats)

In this case, the exe1 executable will be compiled with -DClimbingStats_FROM_BUILD_LOCATION. The exporting commands generate IMPORTED targets with either the INSTALL_INTERFACE or the BUILD_INTERFACE omitted, and the *_INTERFACE marker stripped away. A separate project consuming the ClimbingStats package would contain:

find_package(ClimbingStats REQUIRED)

add_executable(Downstream main.cpp)
target_link_libraries(Downstream Upstream::ClimbingStats)

Depending on whether the ClimbingStats package was used from the build location or the install location, the Downstream target would be compiled with either -DClimbingStats_FROM_BUILD_LOCATION or -DClimbingStats_FROM_INSTALL_LOCATION. For more about packages and exporting see the cmake-packages(7) manual.

Include Directories and Usage Requirements

Include directories require some special consideration when specified as usage requirements and when used with generator expressions. The target_include_directories() command accepts both relative and absolute include directories:

add_library(lib1 lib1.cpp)
target_include_directories(lib1 PRIVATE
  /absolute/path
  relative/path
)

Relative paths are interpreted relative to the source directory where the command appears. Relative paths are not allowed in the INTERFACE_INCLUDE_DIRECTORIES of IMPORTED targets.

In cases where a non-trivial generator expression is used, the INSTALL_PREFIX expression may be used within the argument of an INSTALL_INTERFACE expression. It is a replacement marker which expands to the installation prefix when imported by a consuming project.

Include directories usage requirements commonly differ between the build-tree and the install-tree. The BUILD_INTERFACE and INSTALL_INTERFACE generator expressions can be used to describe separate usage requirements based on the usage location. Relative paths are allowed within the INSTALL_INTERFACE expression and are interpreted relative to the installation prefix. For example:

add_library(ClimbingStats climbingstats.cpp)
target_include_directories(ClimbingStats INTERFACE
  $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/generated>
  $<INSTALL_INTERFACE:/absolute/path>
  $<INSTALL_INTERFACE:relative/path>
  $<INSTALL_INTERFACE:$<INSTALL_PREFIX>/$<CONFIG>/generated>
)

Two convenience APIs are provided relating to include directories usage requirements. The CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE variable may be enabled, with an equivalent effect to:

set_property(TARGET tgt APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR};${CMAKE_CURRENT_BINARY_DIR}>
)

for each target affected. The convenience for installed targets is an INCLUDES DESTINATION component with the install(TARGETS) command:

install(TARGETS foo bar bat EXPORT tgts ${dest_args}
  INCLUDES DESTINATION include
)
install(EXPORT tgts ${other_args})
install(FILES ${headers} DESTINATION include)

This is equivalent to appending ${CMAKE_INSTALL_PREFIX}/include to the INTERFACE_INCLUDE_DIRECTORIES of each of the installed IMPORTED targets when generated by install(EXPORT).

When the INTERFACE_INCLUDE_DIRECTORIES of an imported target is consumed, the entries in the property are treated as SYSTEM include directories, as if they were listed in the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES of the dependency. This can result in omission of compiler warnings for headers found in those directories. This behavior for Imported Targets may be controlled by setting the NO_SYSTEM_FROM_IMPORTED target property on the consumers of imported targets.

If a binary target is linked transitively to a Mac OX framework, the Headers directory of the framework is also treated as a usage requirement. This has the same effect as passing the framework directory as an include directory.

Link Libraries and Generator Expressions

Like build specifications, link libraries may be specified with generator expression conditions. However, as consumption of usage requirements is based on collection from linked dependencies, there is an additional limitation that the link dependencies must form a “directed acyclic graph”. That is, if linking to a target is dependent on the value of a target property, that target property may not be dependent on the linked dependencies:

add_library(lib1 lib1.cpp)
add_library(lib2 lib2.cpp)
target_link_libraries(lib1 PUBLIC
  $<$<TARGET_PROPERTY:POSITION_INDEPENDENT_CODE>:lib2>
)
add_library(lib3 lib3.cpp)
set_property(TARGET lib3 PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE ON)

add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 lib1 lib3)

As the value of the POSITION_INDEPENDENT_CODE property of the exe1 target is dependent on the linked libraries (lib3), and the edge of linking exe1 is determined by the same POSITION_INDEPENDENT_CODE property, the dependency graph above contains a cycle. cmake(1) issues a diagnostic in this case.

Output Artifacts

The buildsystem targets created by the add_library() and add_executable() commands create rules to create binary outputs. The exact output location of the binaries can only be determined at generate-time because it can depend on the build-configuration and the link-language of linked dependencies etc. TARGET_FILE, TARGET_LINKER_FILE and related expressions can be used to access the name and location of generated binaries. These expressions do not work for OBJECT libraries however, as there is no single file generated by such libraries which is relevant to the expressions.

There are three kinds of output artifacts that may be build by targets as detailed in the following sections. Their classification differs between DLL platforms and non-DLL platforms. All Windows-based systems including Cygwin are DLL platforms.

Runtime Output Artifacts

A runtime output artifact of a buildsystem target may be:

  • The executable file (e.g. .exe) of an executable target created by the add_executable() command.
  • On DLL platforms: the executable file (e.g. .dll) of a shared library target created by the add_library() command with the SHARED option.

The RUNTIME_OUTPUT_DIRECTORY and RUNTIME_OUTPUT_NAME target properties may be used to control runtime output artifact locations and names in the build tree.

Library Output Artifacts

A library output artifact of a buildsystem target may be:

  • The loadable module file (e.g. .dll or .so) of a module library target created by the add_library() command with the MODULE option.
  • On non-DLL platforms: the shared library file (e.g. .so or .dylib) of a shared library target created by the add_library() command with the SHARED option.

The LIBRARY_OUTPUT_DIRECTORY and LIBRARY_OUTPUT_NAME target properties may be used to control library output artifact locations and names in the build tree.

Archive Output Artifacts

An archive output artifact of a buildsystem target may be:

  • The static library file (e.g. .lib or .a) of a static library target created by the add_library() command with the STATIC option.
  • On DLL platforms: the import library file (e.g. .lib) of a shared library target created by the add_library() command with the SHARED option. This file is only guaranteed to exist if the library exports at least one unmanaged symbol.
  • On DLL platforms: the import library file (e.g. .lib) of an executable target created by the add_executable() command when its ENABLE_EXPORTS target property is set.

The ARCHIVE_OUTPUT_DIRECTORY and ARCHIVE_OUTPUT_NAME target properties may be used to control archive output artifact locations and names in the build tree.

Directory-Scoped Commands

The target_include_directories(), target_compile_definitions() and target_compile_options() commands have an effect on only one target at a time. The commands add_compile_definitions(), add_compile_options() and include_directories() have a similar function, but operate at directory scope instead of target scope for convenience.

Pseudo Targets

Some target types do not represent outputs of the buildsystem, but only inputs such as external dependencies, aliases or other non-build artifacts. Pseudo targets are not represented in the generated buildsystem.

Imported Targets

An IMPORTED target represents a pre-existing dependency. Usually such targets are defined by an upstream package and should be treated as immutable. After declaring an IMPORTED target one can adjust its target properties by using the customary commands such as target_compile_definitions(), target_include_directories(), target_compile_options() or target_link_libraries() just like with any other regular target.

IMPORTED targets may have the same usage requirement properties populated as binary targets, such as INTERFACE_INCLUDE_DIRECTORIES, INTERFACE_COMPILE_DEFINITIONS, INTERFACE_COMPILE_OPTIONS, INTERFACE_LINK_LIBRARIES, and INTERFACE_POSITION_INDEPENDENT_CODE.

The LOCATION may also be read from an IMPORTED target, though there is rarely reason to do so. Commands such as add_custom_command() can transparently use an IMPORTED EXECUTABLE target as a COMMAND executable.

The scope of the definition of an IMPORTED target is the directory where it was defined. It may be accessed and used from subdirectories, but not from parent directories or sibling directories. The scope is similar to the scope of a cmake variable.

It is also possible to define a GLOBAL IMPORTED target which is accessible globally in the buildsystem.

See the cmake-packages(7) manual for more on creating packages with IMPORTED targets.

Alias Targets

An ALIAS target is a name which may be used interchangeably with a binary target name in read-only contexts. A primary use-case for ALIAS targets is for example or unit test executables accompanying a library, which may be part of the same buildsystem or built separately based on user configuration.

add_library(lib1 lib1.cpp)
install(TARGETS lib1 EXPORT lib1Export ${dest_args})
install(EXPORT lib1Export NAMESPACE Upstream:: ${other_args})

add_library(Upstream::lib1 ALIAS lib1)

In another directory, we can link unconditionally to the Upstream::lib1 target, which may be an IMPORTED target from a package, or an ALIAS target if built as part of the same buildsystem.

if (NOT TARGET Upstream::lib1)
  find_package(lib1 REQUIRED)
endif()
add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 Upstream::lib1)

ALIAS targets are not mutable, installable or exportable. They are entirely local to the buildsystem description. A name can be tested for whether it is an ALIAS name by reading the ALIASED_TARGET property from it:

get_target_property(_aliased Upstream::lib1 ALIASED_TARGET)
if(_aliased)
  message(STATUS "The name Upstream::lib1 is an ALIAS for ${_aliased}.")
endif()

Interface Libraries

An INTERFACE target has no LOCATION and is mutable, but is otherwise similar to an IMPORTED target.

It may specify usage requirements such as INTERFACE_INCLUDE_DIRECTORIES, INTERFACE_COMPILE_DEFINITIONS, INTERFACE_COMPILE_OPTIONS, INTERFACE_LINK_LIBRARIES, INTERFACE_SOURCES, and INTERFACE_POSITION_INDEPENDENT_CODE. Only the INTERFACE modes of the target_include_directories(), target_compile_definitions(), target_compile_options(), target_sources(), and target_link_libraries() commands may be used with INTERFACE libraries.

A primary use-case for INTERFACE libraries is header-only libraries.

add_library(Eigen INTERFACE)
target_include_directories(Eigen INTERFACE
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src>
  $<INSTALL_INTERFACE:include/Eigen>
)

add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 Eigen)

Here, the usage requirements from the Eigen target are consumed and used when compiling, but it has no effect on linking.

Another use-case is to employ an entirely target-focussed design for usage requirements:

add_library(pic_on INTERFACE)
set_property(TARGET pic_on PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE ON)
add_library(pic_off INTERFACE)
set_property(TARGET pic_off PROPERTY INTERFACE_POSITION_INDEPENDENT_CODE OFF)

add_library(enable_rtti INTERFACE)
target_compile_options(enable_rtti INTERFACE
  $<$<OR:$<COMPILER_ID:GNU>,$<COMPILER_ID:Clang>>:-rtti>
)

add_executable(exe1 exe1.cpp)
target_link_libraries(exe1 pic_on enable_rtti)

This way, the build specification of exe1 is expressed entirely as linked targets, and the complexity of compiler-specific flags is encapsulated in an INTERFACE library target.

The properties permitted to be set on or read from an INTERFACE library are:

  • Properties matching INTERFACE_*
  • Built-in properties matching COMPATIBLE_INTERFACE_*
  • EXPORT_NAME
  • IMPORTED
  • MANUALLY_ADDED_DEPENDENCIES
  • NAME
  • Properties matching IMPORTED_LIBNAME_*
  • Properties matching MAP_IMPORTED_CONFIG_*

INTERFACE libraries may be installed and exported. Any content they refer to must be installed separately:

add_library(Eigen INTERFACE)
target_include_directories(Eigen INTERFACE
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src>
  $<INSTALL_INTERFACE:include/Eigen>
)

install(TARGETS Eigen EXPORT eigenExport)
install(EXPORT eigenExport NAMESPACE Upstream::
  DESTINATION lib/cmake/Eigen
)
install(FILES
    ${CMAKE_CURRENT_SOURCE_DIR}/src/eigen.h
    ${CMAKE_CURRENT_SOURCE_DIR}/src/vector.h
    ${CMAKE_CURRENT_SOURCE_DIR}/src/matrix.h
  DESTINATION include/Eigen
)


cmake-commands(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-commands(7)

Contents

  • cmake-commands(7)
    • Scripting Commands
    • Project Commands
    • CTest Commands
    • Deprecated Commands

Scripting Commands

These commands are always available.

  • break
  • cmake_host_system_information
  • cmake_minimum_required
  • cmake_parse_arguments
  • cmake_policy
  • configure_file
  • continue
  • else
  • elseif
  • endforeach
  • endfunction
  • endif
  • endmacro
  • endwhile
  • execute_process
  • file
  • find_file
  • find_library
  • find_package
  • find_path
  • find_program
  • foreach
  • function
  • get_cmake_property
  • get_directory_property
  • get_filename_component
  • get_property
  • if
  • include
  • include_guard
  • list
  • macro
  • mark_as_advanced
  • math
  • message
  • option
  • return
  • separate_arguments
  • set
  • set_directory_properties
  • set_property
  • site_name
  • string
  • unset
  • variable_watch
  • while

Project Commands

These commands are available only in CMake projects.

  • add_compile_definitions
  • add_compile_options
  • add_custom_command
  • add_custom_target
  • add_definitions
  • add_dependencies
  • add_executable
  • add_library
  • add_link_options
  • add_subdirectory
  • add_test
  • aux_source_directory
  • build_command
  • create_test_sourcelist
  • define_property
  • enable_language
  • enable_testing
  • export
  • fltk_wrap_ui
  • get_source_file_property
  • get_target_property
  • get_test_property
  • include_directories
  • include_external_msproject
  • include_regular_expression
  • install
  • link_directories
  • link_libraries
  • load_cache
  • project
  • remove_definitions
  • set_source_files_properties
  • set_target_properties
  • set_tests_properties
  • source_group
  • target_compile_definitions
  • target_compile_features
  • target_compile_options
  • target_include_directories
  • target_link_directories
  • target_link_libraries
  • target_link_options
  • target_sources
  • try_compile
  • try_run

CTest Commands

These commands are available only in CTest scripts.

  • ctest_build
  • ctest_configure
  • ctest_coverage
  • ctest_empty_binary_directory
  • ctest_memcheck
  • ctest_read_custom_files
  • ctest_run_script
  • ctest_sleep
  • ctest_start
  • ctest_submit
  • ctest_test
  • ctest_update
  • ctest_upload

Deprecated Commands

These commands are deprecated and are only made available to maintain backward compatibility. The documentation of each command states the CMake version in which it was deprecated. Do not use these commands in new code.

  • build_name
  • exec_program
  • export_library_dependencies
  • install_files
  • install_programs
  • install_targets
  • load_command
  • make_directory
  • output_required_files
  • qt_wrap_cpp
  • qt_wrap_ui
  • remove
  • subdir_depends
  • subdirs
  • use_mangled_mesa
  • utility_source
  • variable_requires
  • write_file


break — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

break

Break from an enclosing foreach or while loop.

break()

Breaks from an enclosing foreach() or while() loop.

See also the continue() command.

Navigation

  • index
  • next |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »


cmake_host_system_information — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

cmake_host_system_information

Query host system specific information.

cmake_host_system_information(RESULT <variable> QUERY <key> ...)

Queries system information of the host system on which cmake runs. One or more <key> can be provided to select the information to be queried. The list of queried values is stored in <variable>.

<key> can be one of the following values:

Key | Description
NUMBER_OF_LOGICAL_CORES | Number of logical cores
NUMBER_OF_PHYSICAL_CORES | Number of physical cores
HOSTNAME | Hostname
FQDN | Fully qualified domain name
TOTAL_VIRTUAL_MEMORY | Total virtual memory in MiB [1]
AVAILABLE_VIRTUAL_MEMORY | Available virtual memory in MiB [1]
TOTAL_PHYSICAL_MEMORY | Total physical memory in MiB [1]
AVAILABLE_PHYSICAL_MEMORY | Available physical memory in MiB [1]
IS_64BIT | One if processor is 64Bit
HAS_FPU | One if processor has floating point unit
HAS_MMX | One if processor supports MMX instructions
HAS_MMX_PLUS | One if processor supports Ext. MMX instructions
HAS_SSE | One if processor supports SSE instructions
HAS_SSE2 | One if processor supports SSE2 instructions
HAS_SSE_FP | One if processor supports SSE FP instructions
HAS_SSE_MMX | One if processor supports SSE MMX instructions
HAS_AMD_3DNOW | One if processor supports 3DNow instructions
HAS_AMD_3DNOW_PLUS | One if processor supports 3DNow+ instructions
HAS_IA64 | One if IA64 processor emulating x86
HAS_SERIAL_NUMBER | One if processor has serial number
PROCESSOR_SERIAL_NUMBER | Processor serial number
PROCESSOR_NAME | Human readable processor name
PROCESSOR_DESCRIPTION | Human readable full processor description
OS_NAME | See CMAKE_HOST_SYSTEM_NAME
OS_RELEASE | The OS sub-type e.g. on Windows Professional
OS_VERSION | The OS build ID
OS_PLATFORM | See CMAKE_HOST_SYSTEM_PROCESSOR

Footnotes

[1] (1, 2, 3, 4) One MiB (mebibyte) is equal to 1024x1024 bytes.

  • cmake-commands(7) »


cmake_minimum_required — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

cmake_minimum_required

Require a minimum version of cmake.

cmake_minimum_required(VERSION <min>[...<max>] [FATAL_ERROR])

Sets the minimum required version of cmake for a project. Also updates the policy settings as explained below.

<min> and the optional <max> are each CMake versions of the form major.minor[.patch[.tweak]], and the ... is literal.

If the running version of CMake is lower than the <min> required version it will stop processing the project and report an error. The optional <max> version, if specified, must be at least the <min> version and affects policy settings as described below. If the running version of CMake is older than 3.12, the extra ... dots will be seen as version component separators, resulting in the ...<max> part being ignored and preserving the pre-3.12 behavior of basing policies on <min>.

The FATAL_ERROR option is accepted but ignored by CMake 2.6 and higher. It should be specified so CMake versions 2.4 and lower fail with an error instead of just a warning.

Note

Call the cmake_minimum_required() command at the beginning of the top-level CMakeLists.txt file even before calling the project() command. It is important to establish version and policy settings before invoking other commands whose behavior they may affect. See also policy CMP0000.

Calling cmake_minimum_required() inside a function() limits some effects to the function scope when invoked. Such calls should not be made with the intention of having global effects.

Policy Settings

The cmake_minimum_required(VERSION) command implicitly invokes the cmake_policy(VERSION) command to specify that the current project code is written for the given range of CMake versions. All policies known to the running version of CMake and introduced in the <min> (or <max>, if specified) version or earlier will be set to use NEW behavior. All policies introduced in later versions will be unset. This effectively requests behavior preferred as of a given CMake version and tells newer CMake versions to warn about their new policies.

When a <min> version higher than 2.4 is specified the command implicitly invokes

cmake_policy(VERSION <min>[...<max>])

which sets CMake policies based on the range of versions specified. When a <min> version 2.4 or lower is given the command implicitly invokes

cmake_policy(VERSION 2.4[...<max>])

which enables compatibility features for CMake 2.4 and lower.

  • cmake-commands(7) »


cmake_parse_arguments — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

cmake_parse_arguments

Parse function or macro arguments.

cmake_parse_arguments(<prefix> <options> <one_value_keywords>
                      <multi_value_keywords> <args>...)

cmake_parse_arguments(PARSE_ARGV <N> <prefix> <options>
                      <one_value_keywords> <multi_value_keywords>)

This command is for use in macros or functions. It processes the arguments given to that macro or function, and defines a set of variables which hold the values of the respective options.

The first signature reads processes arguments passed in the <args>.... This may be used in either a macro() or a function().

The PARSE_ARGV signature is only for use in a function() body. In this case the arguments that are parsed come from the ARGV# variables of the calling function. The parsing starts with the <N>-th argument, where <N> is an unsigned integer. This allows for the values to have special characters like ; in them.

The <options> argument contains all options for the respective macro, i.e. keywords which can be used when calling the macro without any value following, like e.g. the OPTIONAL keyword of the install() command.

The <one_value_keywords> argument contains all keywords for this macro which are followed by one value, like e.g. DESTINATION keyword of the install() command.

The <multi_value_keywords> argument contains all keywords for this macro which can be followed by more than one value, like e.g. the TARGETS or FILES keywords of the install() command.

Note

All keywords shall be unique. I.e. every keyword shall only be specified once in either <options>, <one_value_keywords> or <multi_value_keywords>. A warning will be emitted if uniqueness is violated.

When done, cmake_parse_arguments will consider for each of the keywords listed in <options>, <one_value_keywords> and <multi_value_keywords> a variable composed of the given <prefix> followed by "_" and the name of the respective keyword. These variables will then hold the respective value from the argument list or be undefined if the associated option could not be found. For the <options> keywords, these will always be defined, to TRUE or FALSE, whether the option is in the argument list or not.

All remaining arguments are collected in a variable <prefix>_UNPARSED_ARGUMENTS that will be undefined if all argument where recognized. This can be checked afterwards to see whether your macro was called with unrecognized parameters.

As an example here a my_install() macro, which takes similar arguments as the real install() command:

macro(my_install)
    set(options OPTIONAL FAST)
    set(oneValueArgs DESTINATION RENAME)
    set(multiValueArgs TARGETS CONFIGURATIONS)
    cmake_parse_arguments(MY_INSTALL "${options}" "${oneValueArgs}"
                          "${multiValueArgs}" ${ARGN} )

    # ...

Assume my_install() has been called like this:

my_install(TARGETS foo bar DESTINATION bin OPTIONAL blub)

After the cmake_parse_arguments call the macro will have set or undefined the following variables:

MY_INSTALL_OPTIONAL = TRUE
MY_INSTALL_FAST = FALSE # was not used in call to my_install
MY_INSTALL_DESTINATION = "bin"
MY_INSTALL_RENAME <UNDEFINED> # was not used
MY_INSTALL_TARGETS = "foo;bar"
MY_INSTALL_CONFIGURATIONS <UNDEFINED> # was not used
MY_INSTALL_UNPARSED_ARGUMENTS = "blub" # nothing expected after "OPTIONAL"

You can then continue and process these variables.

Keywords terminate lists of values, e.g. if directly after a one_value_keyword another recognized keyword follows, this is interpreted as the beginning of the new option. E.g. my_install(TARGETS foo DESTINATION OPTIONAL) would result in MY_INSTALL_DESTINATION set to "OPTIONAL", but as OPTIONAL is a keyword itself MY_INSTALL_DESTINATION will be empty and MY_INSTALL_OPTIONAL will therefore be set to TRUE.

  • cmake-commands(7) »


cmake_policy — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

cmake_policy

Manage CMake Policy settings. See the cmake-policies(7) manual for defined policies.

As CMake evolves it is sometimes necessary to change existing behavior in order to fix bugs or improve implementations of existing features. The CMake Policy mechanism is designed to help keep existing projects building as new versions of CMake introduce changes in behavior. Each new policy (behavioral change) is given an identifier of the form CMP<NNNN> where <NNNN> is an integer index. Documentation associated with each policy describes the OLD and NEW behavior and the reason the policy was introduced. Projects may set each policy to select the desired behavior. When CMake needs to know which behavior to use it checks for a setting specified by the project. If no setting is available the OLD behavior is assumed and a warning is produced requesting that the policy be set.

Setting Policies by CMake Version

The cmake_policy command is used to set policies to OLD or NEW behavior. While setting policies individually is supported, we encourage projects to set policies based on CMake versions:

cmake_policy(VERSION <min>[...<max>])

<min> and the optional <max> are each CMake versions of the form major.minor[.patch[.tweak]], and the ... is literal. The <min> version must be at least 2.4 and at most the running version of CMake. The <max> version, if specified, must be at least the <min> version but may exceed the running version of CMake. If the running version of CMake is older than 3.12, the extra ... dots will be seen as version component separators, resulting in the ...<max> part being ignored and preserving the pre-3.12 behavior of basing policies on <min>.

This specifies that the current CMake code is written for the given range of CMake versions. All policies known to the running version of CMake and introduced in the <min> (or <max>, if specified) version or earlier will be set to use NEW behavior. All policies introduced in later versions will be unset (unless the CMAKE_POLICY_DEFAULT_CMP<NNNN> variable sets a default). This effectively requests behavior preferred as of a given CMake version and tells newer CMake versions to warn about their new policies.

Note that the cmake_minimum_required(VERSION) command implicitly calls cmake_policy(VERSION) too.

Setting Policies Explicitly

cmake_policy(SET CMP<NNNN> NEW)
cmake_policy(SET CMP<NNNN> OLD)

Tell CMake to use the OLD or NEW behavior for a given policy. Projects depending on the old behavior of a given policy may silence a policy warning by setting the policy state to OLD. Alternatively one may fix the project to work with the new behavior and set the policy state to NEW.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

Checking Policy Settings

cmake_policy(GET CMP<NNNN> <variable>)

Check whether a given policy is set to OLD or NEW behavior. The output <variable> value will be OLD or NEW if the policy is set, and empty otherwise.

CMake Policy Stack

CMake keeps policy settings on a stack, so changes made by the cmake_policy command affect only the top of the stack. A new entry on the policy stack is managed automatically for each subdirectory to protect its parents and siblings. CMake also manages a new entry for scripts loaded by include() and find_package() commands except when invoked with the NO_POLICY_SCOPE option (see also policy CMP0011). The cmake_policy command provides an interface to manage custom entries on the policy stack:

cmake_policy(PUSH)
cmake_policy(POP)

Each PUSH must have a matching POP to erase any changes. This is useful to make temporary changes to policy settings. Calls to the cmake_minimum_required(VERSION), cmake_policy(VERSION), or cmake_policy(SET) commands influence only the current top of the policy stack.

Commands created by the function() and macro() commands record policy settings when they are created and use the pre-record policies when they are invoked. If the function or macro implementation sets policies, the changes automatically propagate up through callers until they reach the closest nested policy stack entry.

  • cmake-commands(7) »


configure_file — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

configure_file

Copy a file to another location and modify its contents.

configure_file(<input> <output>
               [COPYONLY] [ESCAPE_QUOTES] [@ONLY]
               [NEWLINE_STYLE [UNIX|DOS|WIN32|LF|CRLF] ])

Copies an <input> file to an <output> file and substitutes variable values referenced as @VAR@ or ${VAR} in the input file content. Each variable reference will be replaced with the current value of the variable, or the empty string if the variable is not defined. Furthermore, input lines of the form

#cmakedefine VAR ...

will be replaced with either

#define VAR ...

or

/* #undef VAR */

depending on whether VAR is set in CMake to any value not considered a false constant by the if() command. The “…” content on the line after the variable name, if any, is processed as above. Input file lines of the form #cmakedefine01 VAR will be replaced with either #define VAR 1 or #define VAR 0 similarly. The result lines (with the exception of the #undef comments) can be indented using spaces and/or tabs between the # character and the cmakedefine or cmakedefine01 words. This whitespace indentation will be preserved in the output lines:

#  cmakedefine VAR
#  cmakedefine01 VAR

will be replaced, if VAR is defined, with

#  define VAR
#  define VAR 1

If the input file is modified the build system will re-run CMake to re-configure the file and generate the build system again. The generated file is modified and its timestamp updated on subsequent cmake runs only if its content is changed.

The arguments are:

<input>
Path to the input file. A relative path is treated with respect to the value of CMAKE_CURRENT_SOURCE_DIR. The input path must be a file, not a directory.
<output>
Path to the output file or directory. A relative path is treated with respect to the value of CMAKE_CURRENT_BINARY_DIR. If the path names an existing directory the output file is placed in that directory with the same file name as the input file.
COPYONLY
Copy the file without replacing any variable references or other content. This option may not be used with NEWLINE_STYLE.
ESCAPE_QUOTES
Escape any substituted quotes with backslashes (C-style).
@ONLY
Restrict variable replacement to references of the form @VAR@. This is useful for configuring scripts that use ${VAR} syntax.
NEWLINE_STYLE <style>
Specify the newline style for the output file. Specify UNIX or LF for \n newlines, or specify DOS, WIN32, or CRLF for \r\n newlines. This option may not be used with COPYONLY.

Example

Consider a source tree containing a foo.h.in file:

#cmakedefine FOO_ENABLE
#cmakedefine FOO_STRING "@FOO_STRING@"

An adjacent CMakeLists.txt may use configure_file to configure the header:

option(FOO_ENABLE "Enable Foo" ON)
if(FOO_ENABLE)
  set(FOO_STRING "foo")
endif()
configure_file(foo.h.in foo.h @ONLY)

This creates a foo.h in the build directory corresponding to this source directory. If the FOO_ENABLE option is on, the configured file will contain:

#define FOO_ENABLE
#define FOO_STRING "foo"

Otherwise it will contain:

/* #undef FOO_ENABLE */
/* #undef FOO_STRING */

One may then use the include_directories() command to specify the output directory as an include directory:

include_directories(${CMAKE_CURRENT_BINARY_DIR})

so that sources may include the header as #include <foo.h>.

  • cmake-commands(7) »


continue — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

continue

Continue to the top of enclosing foreach or while loop.

continue()

The continue command allows a cmake script to abort the rest of a block in a foreach() or while() loop, and start at the top of the next iteration.

See also the break() command.

  • cmake-commands(7) »


else — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

else

Starts the else portion of an if block.

else([<condition>])

See the if() command.

  • cmake-commands(7) »


elseif — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

elseif

Starts an elseif portion of an if block.

elseif(<condition>)

See the if() command, especially for the syntax and logic of the <condition>.

  • cmake-commands(7) »


endforeach — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

endforeach

Ends a list of commands in a foreach block.

endforeach([<loop_var>])

See the foreach() command.

The optional <loop_var> argument is supported for backward compatibility only. If used it must be a verbatim repeat of the <loop_var> argument of the opening foreach clause.

  • cmake-commands(7) »


endfunction — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

endfunction

Ends a list of commands in a function block.

endfunction([<name>])

See the function() command.

The optional <name> argument is supported for backward compatibility only. If used it must be a verbatim repeat of the <name> argument of the opening function command.

  • cmake-commands(7) »


endif — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

endif

Ends a list of commands in an if block.

endif([<condition>])

See the if() command.

The optional <condition> argument is supported for backward compatibility only. If used it must be a verbatim repeat of the argument of the opening if clause.

  • cmake-commands(7) »


endmacro — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

endmacro

Ends a list of commands in a macro block.

endmacro([<name>])

See the macro() command.

The optional <name> argument is supported for backward compatibility only. If used it must be a verbatim repeat of the <name> argument of the opening macro command.

  • cmake-commands(7) »


endwhile — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

endwhile

Ends a list of commands in a while block.

endwhile([<condition>])

See the while() command.

The optional <condition> argument is supported for backward compatibility only. If used it must be a verbatim repeat of the argument of the opening while clause.

  • cmake-commands(7) »


execute_process — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

execute_process

Execute one or more child processes.

execute_process(COMMAND <cmd1> [<arguments>]
                [COMMAND <cmd2> [<arguments>]]...
                [WORKING_DIRECTORY <directory>]
                [TIMEOUT <seconds>]
                [RESULT_VARIABLE <variable>]
                [RESULTS_VARIABLE <variable>]
                [OUTPUT_VARIABLE <variable>]
                [ERROR_VARIABLE <variable>]
                [INPUT_FILE <file>]
                [OUTPUT_FILE <file>]
                [ERROR_FILE <file>]
                [OUTPUT_QUIET]
                [ERROR_QUIET]
                [OUTPUT_STRIP_TRAILING_WHITESPACE]
                [ERROR_STRIP_TRAILING_WHITESPACE]
                [ENCODING <name>])

Runs the given sequence of one or more commands in parallel with the standard output of each process piped to the standard input of the next. A single standard error pipe is used for all processes.

Options:

COMMAND

A child process command line.

CMake executes the child process using operating system APIs directly. All arguments are passed VERBATIM to the child process. No intermediate shell is used, so shell operators such as > are treated as normal arguments. (Use the INPUT_*, OUTPUT_*, and ERROR_* options to redirect stdin, stdout, and stderr.)

If a sequential execution of multiple commands is required, use multiple execute_process() calls with a single COMMAND argument.

WORKING_DIRECTORY
The named directory will be set as the current working directory of the child processes.
TIMEOUT
The child processes will be terminated if they do not finish in the specified number of seconds (fractions are allowed).
RESULT_VARIABLE
The variable will be set to contain the result of last child process. This will be an integer return code from the last child or a string describing an error condition.
RESULTS_VARIABLE <variable>
The variable will be set to contain the result of all processes as a semicolon-separated list, in order of the given COMMAND arguments. Each entry will be an integer return code from the corresponding child or a string describing an error condition.
OUTPUT_VARIABLE, ERROR_VARIABLE
The variable named will be set with the contents of the standard output and standard error pipes, respectively. If the same variable is named for both pipes their output will be merged in the order produced.
INPUT_FILE, OUTPUT_FILE, ERROR_FILE
The file named will be attached to the standard input of the first process, standard output of the last process, or standard error of all processes, respectively. If the same file is named for both output and error then it will be used for both.
OUTPUT_QUIET, ERROR_QUIET
The standard output or standard error results will be quietly ignored.
ENCODING <name>

On Windows, the encoding that is used to decode output from the process. Ignored on other platforms. Valid encoding names are:

NONE
Perform no decoding. This assumes that the process output is encoded in the same way as CMake’s internal encoding (UTF-8). This is the default.
AUTO
Use the current active console’s codepage or if that isn’t available then use ANSI.
ANSI
Use the ANSI codepage.
OEM
Use the original equipment manufacturer (OEM) code page.
UTF8 or UTF-8
Use the UTF-8 codepage. Prior to CMake 3.11.0, only UTF8 was accepted for this encoding. In CMake 3.11.0, UTF-8 was added for consistency with the UTF-8 RFC naming convention.

If more than one OUTPUT_* or ERROR_* option is given for the same pipe the precedence is not specified. If no OUTPUT_* or ERROR_* options are given the output will be shared with the corresponding pipes of the CMake process itself.

The execute_process() command is a newer more powerful version of exec_program(), but the old command has been kept for compatibility. Both commands run while CMake is processing the project prior to build system generation. Use add_custom_target() and add_custom_command() to create custom commands that run at build time.

  • cmake-commands(7) »


file — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

file

File manipulation command.

Synopsis

Reading
  file(READ <filename> <out-var> [...])
  file(STRINGS <filename> <out-var> [...])
  file(<HASH> <filename> <out-var>)
  file(TIMESTAMP <filename> <out-var> [...])

Writing
  file({WRITE | APPEND} <filename> <content>...)
  file({TOUCH | TOUCH_NOCREATE} [<file>...])
  file(GENERATE OUTPUT <output-file> [...])

Filesystem
  file({GLOB | GLOB_RECURSE} <out-var> [...] [<globbing-expr>...])
  file(RENAME <oldname> <newname>)
  file({REMOVE | REMOVE_RECURSE } [<files>...])
  file(MAKE_DIRECTORY [<dir>...])
  file({COPY | INSTALL} <file>... DESTINATION <dir> [...])
  file(SIZE <filename> <out-var>)
  file(READ_SYMLINK <linkname> <out-var>)
  file(CREATE_LINK <original> <linkname> [...])

Path Conversion
  file(RELATIVE_PATH <out-var> <directory> <file>)
  file({TO_CMAKE_PATH | TO_NATIVE_PATH} <path> <out-var>)

Transfer
  file(DOWNLOAD <url> <file> [...])
  file(UPLOAD <file> <url> [...])

Locking
  file(LOCK <path> [...])

Reading

file(READ <filename> <variable>
     [OFFSET <offset>] [LIMIT <max-in>] [HEX])

Read content from a file called <filename> and store it in a <variable>. Optionally start from the given <offset> and read at most <max-in> bytes. The HEX option causes data to be converted to a hexadecimal representation (useful for binary data).

file(STRINGS <filename> <variable> [<options>...])

Parse a list of ASCII strings from <filename> and store it in <variable>. Binary data in the file are ignored. Carriage return (\r, CR) characters are ignored. The options are:

LENGTH_MAXIMUM <max-len>
Consider only strings of at most a given length.
LENGTH_MINIMUM <min-len>
Consider only strings of at least a given length.
LIMIT_COUNT <max-num>
Limit the number of distinct strings to be extracted.
LIMIT_INPUT <max-in>
Limit the number of input bytes to read from the file.
LIMIT_OUTPUT <max-out>
Limit the number of total bytes to store in the <variable>.
NEWLINE_CONSUME
Treat newline characters (\n, LF) as part of string content instead of terminating at them.
NO_HEX_CONVERSION
Intel Hex and Motorola S-record files are automatically converted to binary while reading unless this option is given.
REGEX <regex>
Consider only strings that match the given regular expression.
ENCODING <encoding-type>
Consider strings of a given encoding. Currently supported encodings are: UTF-8, UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE. If the ENCODING option is not provided and the file has a Byte Order Mark, the ENCODING option will be defaulted to respect the Byte Order Mark.

For example, the code

file(STRINGS myfile.txt myfile)

stores a list in the variable myfile in which each item is a line from the input file.

file(<HASH> <filename> <variable>)

Compute a cryptographic hash of the content of <filename> and store it in a <variable>. The supported <HASH> algorithm names are those listed by the string(<HASH>) command.

file(TIMESTAMP <filename> <variable> [<format>] [UTC])

Compute a string representation of the modification time of <filename> and store it in <variable>. Should the command be unable to obtain a timestamp variable will be set to the empty string (“”).

See the string(TIMESTAMP) command for documentation of the <format> and UTC options.

Writing

file(WRITE <filename> <content>...)
file(APPEND <filename> <content>...)

Write <content> into a file called <filename>. If the file does not exist, it will be created. If the file already exists, WRITE mode will overwrite it and APPEND mode will append to the end. Any directories in the path specified by <filename> that do not exist will be created.

If the file is a build input, use the configure_file() command to update the file only when its content changes.

file(TOUCH [<files>...])
file(TOUCH_NOCREATE [<files>...])

Create a file with no content if it does not yet exist. If the file already exists, its access and/or modification will be updated to the time when the function call is executed.

Use TOUCH_NOCREATE to touch a file if it exists but not create it. If a file does not exist it will be silently ignored.

With TOUCH and TOUCH_NOCREATE the contents of an existing file will not be modified.

file(GENERATE OUTPUT output-file
     <INPUT input-file|CONTENT content>
     [CONDITION expression])

Generate an output file for each build configuration supported by the current CMake Generator. Evaluate generator expressions from the input content to produce the output content. The options are:

CONDITION <condition>
Generate the output file for a particular configuration only if the condition is true. The condition must be either 0 or 1 after evaluating generator expressions.
CONTENT <content>
Use the content given explicitly as input.
INPUT <input-file>
Use the content from a given file as input. A relative path is treated with respect to the value of CMAKE_CURRENT_SOURCE_DIR. See policy CMP0070.
OUTPUT <output-file>
Specify the output file name to generate. Use generator expressions such as $<CONFIG> to specify a configuration-specific output file name. Multiple configurations may generate the same output file only if the generated content is identical. Otherwise, the <output-file> must evaluate to an unique name for each configuration. A relative path (after evaluating generator expressions) is treated with respect to the value of CMAKE_CURRENT_BINARY_DIR. See policy CMP0070.

Exactly one CONTENT or INPUT option must be given. A specific OUTPUT file may be named by at most one invocation of file(GENERATE). Generated files are modified and their timestamp updated on subsequent cmake runs only if their content is changed.

Note also that file(GENERATE) does not create the output file until the generation phase. The output file will not yet have been written when the file(GENERATE) command returns, it is written only after processing all of a project’s CMakeLists.txt files.

Filesystem

file(GLOB <variable>
     [LIST_DIRECTORIES true|false] [RELATIVE <path>] [CONFIGURE_DEPENDS]
     [<globbing-expressions>...])
file(GLOB_RECURSE <variable> [FOLLOW_SYMLINKS]
     [LIST_DIRECTORIES true|false] [RELATIVE <path>] [CONFIGURE_DEPENDS]
     [<globbing-expressions>...])

Generate a list of files that match the <globbing-expressions> and store it into the <variable>. Globbing expressions are similar to regular expressions, but much simpler. If RELATIVE flag is specified, the results will be returned as relative paths to the given path. The results will be ordered lexicographically.

If the CONFIGURE_DEPENDS flag is specified, CMake will add logic to the main build system check target to rerun the flagged GLOB commands at build time. If any of the outputs change, CMake will regenerate the build system.

By default GLOB lists directories - directories are omitted in result if LIST_DIRECTORIES is set to false.

Note

We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. Even if CONFIGURE_DEPENDS works reliably, there is still a cost to perform the check on every rebuild.

Examples of globbing expressions include:

*.cxx      - match all files with extension cxx
*.vt?      - match all files with extension vta,...,vtz
f[3-5].txt - match files f3.txt, f4.txt, f5.txt

The GLOB_RECURSE mode will traverse all the subdirectories of the matched directory and match the files. Subdirectories that are symlinks are only traversed if FOLLOW_SYMLINKS is given or policy CMP0009 is not set to NEW.

By default GLOB_RECURSE omits directories from result list - setting LIST_DIRECTORIES to true adds directories to result list. If FOLLOW_SYMLINKS is given or policy CMP0009 is not set to OLD then LIST_DIRECTORIES treats symlinks as directories.

Examples of recursive globbing include:

/dir/*.py  - match all python files in /dir and subdirectories

file(RENAME <oldname> <newname>)

Move a file or directory within a filesystem from <oldname> to <newname>, replacing the destination atomically.

file(REMOVE [<files>...])
file(REMOVE_RECURSE [<files>...])

Remove the given files. The REMOVE_RECURSE mode will remove the given files and directories, also non-empty directories. No error is emitted if a given file does not exist.

file(MAKE_DIRECTORY [<directories>...])

Create the given directories and their parents as needed.

file(<COPY|INSTALL> <files>... DESTINATION <dir>
     [FILE_PERMISSIONS <permissions>...]
     [DIRECTORY_PERMISSIONS <permissions>...]
     [NO_SOURCE_PERMISSIONS] [USE_SOURCE_PERMISSIONS]
     [FILES_MATCHING]
     [[PATTERN <pattern> | REGEX <regex>]
      [EXCLUDE] [PERMISSIONS <permissions>...]] [...])

The COPY signature copies files, directories, and symlinks to a destination folder. Relative input paths are evaluated with respect to the current source directory, and a relative destination is evaluated with respect to the current build directory. Copying preserves input file timestamps, and optimizes out a file if it exists at the destination with the same timestamp. Copying preserves input permissions unless explicit permissions or NO_SOURCE_PERMISSIONS are given (default is USE_SOURCE_PERMISSIONS).

See the install(DIRECTORY) command for documentation of permissions, FILES_MATCHING, PATTERN, REGEX, and EXCLUDE options. Copying directories preserves the structure of their content even if options are used to select a subset of files.

The INSTALL signature differs slightly from COPY: it prints status messages (subject to the CMAKE_INSTALL_MESSAGE variable), and NO_SOURCE_PERMISSIONS is default. Installation scripts generated by the install() command use this signature (with some undocumented options for internal use).

file(SIZE <filename> <variable>)

Determine the file size of the <filename> and put the result in <variable> variable. Requires that <filename> is a valid path pointing to a file and is readable.

file(READ_SYMLINK <linkname> <variable>)

This subcommand queries the symlink <linkname> and stores the path it points to in the result <variable>. If <linkname> does not exist or is not a symlink, CMake issues a fatal error.

Note that this command returns the raw symlink path and does not resolve a relative path. The following is an example of how to ensure that an absolute path is obtained:

set(linkname "/path/to/foo.sym")
file(READ_SYMLINK "${linkname}" result)
if(NOT IS_ABSOLUTE "${result}")
  get_filename_component(dir "${linkname}" DIRECTORY)
  set(result "${dir}/${result}")
endif()

file(CREATE_LINK <original> <linkname>
     [RESULT <result>] [COPY_ON_ERROR] [SYMBOLIC])

Create a link <linkname> that points to <original>. It will be a hard link by default, but providing the SYMBOLIC option results in a symbolic link instead. Hard links require that original exists and is a file, not a directory. If <linkname> already exists, it will be overwritten.

The <result> variable, if specified, receives the status of the operation. It is set to 0 upon success or an error message otherwise. If RESULT is not specified and the operation fails, a fatal error is emitted.

Specifying COPY_ON_ERROR enables copying the file as a fallback if creating the link fails. It can be useful for handling situations such as <original> and <linkname> being on different drives or mount points, which would make them unable to support a hard link.

Path Conversion

file(RELATIVE_PATH <variable> <directory> <file>)

Compute the relative path from a <directory> to a <file> and store it in the <variable>.

file(TO_CMAKE_PATH "<path>" <variable>)
file(TO_NATIVE_PATH "<path>" <variable>)

The TO_CMAKE_PATH mode converts a native <path> into a cmake-style path with forward-slashes (/). The input can be a single path or a system search path like $ENV{PATH}. A search path will be converted to a cmake-style list separated by ; characters.

The TO_NATIVE_PATH mode converts a cmake-style <path> into a native path with platform-specific slashes (\ on Windows and / elsewhere).

Always use double quotes around the <path> to be sure it is treated as a single argument to this command.

Transfer

file(DOWNLOAD <url> <file> [<options>...])
file(UPLOAD   <file> <url> [<options>...])

The DOWNLOAD mode downloads the given <url> to a local <file>. The UPLOAD mode uploads a local <file> to a given <url>.

Options to both DOWNLOAD and UPLOAD are:

INACTIVITY_TIMEOUT <seconds>
Terminate the operation after a period of inactivity.
LOG <variable>
Store a human-readable log of the operation in a variable.
SHOW_PROGRESS
Print progress information as status messages until the operation is complete.
STATUS <variable>
Store the resulting status of the operation in a variable. The status is a ; separated list of length 2. The first element is the numeric return value for the operation, and the second element is a string value for the error. A 0 numeric error means no error in the operation.
TIMEOUT <seconds>
Terminate the operation after a given total time has elapsed.
USERPWD <username>:<password>
Set username and password for operation.
HTTPHEADER <HTTP-header>
HTTP header for operation. Suboption can be repeated several times.
NETRC <level>

Specify whether the .netrc file is to be used for operation. If this option is not specified, the value of the CMAKE_NETRC variable will be used instead. Valid levels are:

IGNORED
The .netrc file is ignored. This is the default.
OPTIONAL
The .netrc file is optional, and information in the URL is preferred. The file will be scanned to find which ever information is not specified in the URL.
REQUIRED
The .netrc file is required, and information in the URL is ignored.
NETRC_FILE <file>
Specify an alternative .netrc file to the one in your home directory, if the NETRC level is OPTIONAL or REQUIRED. If this option is not specified, the value of the CMAKE_NETRC_FILE variable will be used instead.

If neither NETRC option is given CMake will check variables CMAKE_NETRC and CMAKE_NETRC_FILE, respectively.

Additional options to DOWNLOAD are:

EXPECTED_HASH ALGO=<value>

Verify that the downloaded content hash matches the expected value, where ALGO is one of the algorithms supported by file(<HASH>). If it does not match, the operation fails with an error.
EXPECTED_MD5 <value>
Historical short-hand for EXPECTED_HASH MD5=<value>.
TLS_VERIFY <ON|OFF>
Specify whether to verify the server certificate for https:// URLs. The default is to not verify.
TLS_CAINFO <file>
Specify a custom Certificate Authority file for https:// URLs.

For https:// URLs CMake must be built with OpenSSL support. TLS/SSL certificates are not checked by default. Set TLS_VERIFY to ON to check certificates and/or use EXPECTED_HASH to verify downloaded content. If neither TLS option is given CMake will check variables CMAKE_TLS_VERIFY and CMAKE_TLS_CAINFO, respectively.

Locking

file(LOCK <path> [DIRECTORY] [RELEASE]
     [GUARD <FUNCTION|FILE|PROCESS>]
     [RESULT_VARIABLE <variable>]
     [TIMEOUT <seconds>])

Lock a file specified by <path> if no DIRECTORY option present and file <path>/cmake.lock otherwise. File will be locked for scope defined by GUARD option (default value is PROCESS). RELEASE option can be used to unlock file explicitly. If option TIMEOUT is not specified CMake will wait until lock succeed or until fatal error occurs. If TIMEOUT is set to 0 lock will be tried once and result will be reported immediately. If TIMEOUT is not 0 CMake will try to lock file for the period specified by <seconds> value. Any errors will be interpreted as fatal if there is no RESULT_VARIABLE option. Otherwise result will be stored in <variable> and will be 0 on success or error message on failure.

Note that lock is advisory - there is no guarantee that other processes will respect this lock, i.e. lock synchronize two or more CMake instances sharing some modifiable resources. Similar logic applied to DIRECTORY option - locking parent directory doesn’t prevent other LOCK commands to lock any child directory or file.

Trying to lock file twice is not allowed. Any intermediate directories and file itself will be created if they not exist. GUARD and TIMEOUT options ignored on RELEASE operation.

  • cmake-commands(7) »


find_file — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

find_file

A short-hand signature is:

find_file (<VAR> name1 [path1 path2 ...])

The general signature is:

find_file (
          <VAR>
          name | NAMES name1 [name2 ...]
          [HINTS path1 [path2 ... ENV var]]
          [PATHS path1 [path2 ... ENV var]]
          [PATH_SUFFIXES suffix1 [suffix2 ...]]
          [DOC "cache documentation string"]
          [NO_DEFAULT_PATH]
          [NO_PACKAGE_ROOT_PATH]
          [NO_CMAKE_PATH]
          [NO_CMAKE_ENVIRONMENT_PATH]
          [NO_SYSTEM_ENVIRONMENT_PATH]
          [NO_CMAKE_SYSTEM_PATH]
          [CMAKE_FIND_ROOT_PATH_BOTH |
           ONLY_CMAKE_FIND_ROOT_PATH |
           NO_CMAKE_FIND_ROOT_PATH]
         )

This command is used to find a full path to named file. A cache entry named by <VAR> is created to store the result of this command. If the full path to a file is found the result is stored in the variable and the search will not be repeated unless the variable is cleared. If nothing is found, the result will be <VAR>-NOTFOUND, and the search will be attempted again the next time find_file is invoked with the same variable.

Options include:

NAMES

Specify one or more possible names for the full path to a file.

When using this to specify names with and without a version suffix, we recommend specifying the unversioned name first so that locally-built packages can be found before those provided by distributions.

HINTS, PATHS
Specify directories to search in addition to the default locations. The ENV var sub-option reads paths from a system environment variable.
PATH_SUFFIXES
Specify additional subdirectories to check below each directory location otherwise considered.
DOC
Specify the documentation string for the <VAR> cache entry.

If NO_DEFAULT_PATH is specified, then no additional paths are added to the search. If NO_DEFAULT_PATH is not specified, the search process is as follows:

  1. If called from within a find module loaded by find_package(<PackageName>), search prefixes unique to the current package being found. Specifically look in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable. The package root variables are maintained as a stack so if called from nested find modules, root paths from the parent’s find module will be searched after paths from the current module, i.e. <CurrentPackage>_ROOT, ENV{<CurrentPackage>_ROOT}, <ParentPackage>_ROOT, ENV{<ParentPackage>_ROOT}, etc. This can be skipped if NO_PACKAGE_ROOT_PATH is passed. See policy CMP0074.
    • <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix> in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable if called from within a find module loaded by find_package(<PackageName>)
  2. Search paths specified in cmake-specific cache variables. These are intended to be used on the command line with a -DVAR=value. The values are interpreted as semicolon-separated lists. This can be skipped if NO_CMAKE_PATH is passed.
    • <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
    • CMAKE_INCLUDE_PATH
    • CMAKE_FRAMEWORK_PATH
  3. Search paths specified in cmake-specific environment variables. These are intended to be set in the user’s shell configuration, and therefore use the host’s native path separator (; on Windows and : on UNIX). This can be skipped if NO_CMAKE_ENVIRONMENT_PATH is passed.
    • <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
    • CMAKE_INCLUDE_PATH
    • CMAKE_FRAMEWORK_PATH
  4. Search the paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option.
  5. Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is an argument.
    • Directories in INCLUDE. On Windows hosts: <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix>/[s]bin in PATH, and <entry>/include for other entries in PATH, and the directories in PATH itself.
  6. Search cmake variables defined in the Platform files for the current system. This can be skipped if NO_CMAKE_SYSTEM_PATH is passed.
    • <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
    • CMAKE_SYSTEM_INCLUDE_PATH
    • CMAKE_SYSTEM_FRAMEWORK_PATH
  7. Search the paths specified by the PATHS option or in the short-hand version of the command. These are typically hard-coded guesses.

On macOS the CMAKE_FIND_FRAMEWORK and CMAKE_FIND_APPBUNDLE variables determine the order of preference between Apple-style and unix-style package components.

The CMake variable CMAKE_FIND_ROOT_PATH specifies one or more directories to be prepended to all other search directories. This effectively “re-roots” the entire search under given locations. Paths which are descendants of the CMAKE_STAGING_PREFIX are excluded from this re-rooting, because that variable is always a path on the host system. By default the CMAKE_FIND_ROOT_PATH is empty.

The CMAKE_SYSROOT variable can also be used to specify exactly one directory to use as a prefix. Setting CMAKE_SYSROOT also has other effects. See the documentation for that variable for more.

These variables are especially useful when cross-compiling to point to the root directory of the target environment and CMake will search there too. By default at first the directories listed in CMAKE_FIND_ROOT_PATH are searched, then the CMAKE_SYSROOT directory is searched, and then the non-rooted directories will be searched. The default behavior can be adjusted by setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE. This behavior can be manually overridden on a per-call basis using options:

CMAKE_FIND_ROOT_PATH_BOTH
Search in the order described above.
NO_CMAKE_FIND_ROOT_PATH
Do not use the CMAKE_FIND_ROOT_PATH variable.
ONLY_CMAKE_FIND_ROOT_PATH
Search only the re-rooted directories and directories below CMAKE_STAGING_PREFIX.

The default search order is designed to be most-specific to least-specific for common use cases. Projects may override the order by simply calling the command multiple times and using the NO_* options:

find_file (<VAR> NAMES name PATHS paths... NO_DEFAULT_PATH)
find_file (<VAR> NAMES name)

Once one of the calls succeeds the result variable will be set and stored in the cache so that no call will search again.

  • cmake-commands(7) »


find_library — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

find_library

A short-hand signature is:

find_library (<VAR> name1 [path1 path2 ...])

The general signature is:

find_library (
          <VAR>
          name | NAMES name1 [name2 ...] [NAMES_PER_DIR]
          [HINTS path1 [path2 ... ENV var]]
          [PATHS path1 [path2 ... ENV var]]
          [PATH_SUFFIXES suffix1 [suffix2 ...]]
          [DOC "cache documentation string"]
          [NO_DEFAULT_PATH]
          [NO_PACKAGE_ROOT_PATH]
          [NO_CMAKE_PATH]
          [NO_CMAKE_ENVIRONMENT_PATH]
          [NO_SYSTEM_ENVIRONMENT_PATH]
          [NO_CMAKE_SYSTEM_PATH]
          [CMAKE_FIND_ROOT_PATH_BOTH |
           ONLY_CMAKE_FIND_ROOT_PATH |
           NO_CMAKE_FIND_ROOT_PATH]
         )

This command is used to find a library. A cache entry named by <VAR> is created to store the result of this command. If the library is found the result is stored in the variable and the search will not be repeated unless the variable is cleared. If nothing is found, the result will be <VAR>-NOTFOUND, and the search will be attempted again the next time find_library is invoked with the same variable.

Options include:

NAMES

Specify one or more possible names for the library.

When using this to specify names with and without a version suffix, we recommend specifying the unversioned name first so that locally-built packages can be found before those provided by distributions.

HINTS, PATHS
Specify directories to search in addition to the default locations. The ENV var sub-option reads paths from a system environment variable.
PATH_SUFFIXES
Specify additional subdirectories to check below each directory location otherwise considered.
DOC
Specify the documentation string for the <VAR> cache entry.

If NO_DEFAULT_PATH is specified, then no additional paths are added to the search. If NO_DEFAULT_PATH is not specified, the search process is as follows:

  1. If called from within a find module loaded by find_package(<PackageName>), search prefixes unique to the current package being found. Specifically look in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable. The package root variables are maintained as a stack so if called from nested find modules, root paths from the parent’s find module will be searched after paths from the current module, i.e. <CurrentPackage>_ROOT, ENV{<CurrentPackage>_ROOT}, <ParentPackage>_ROOT, ENV{<ParentPackage>_ROOT}, etc. This can be skipped if NO_PACKAGE_ROOT_PATH is passed. See policy CMP0074.
    • <prefix>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/lib for each <prefix> in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable if called from within a find module loaded by find_package(<PackageName>)
  2. Search paths specified in cmake-specific cache variables. These are intended to be used on the command line with a -DVAR=value. The values are interpreted as semicolon-separated lists. This can be skipped if NO_CMAKE_PATH is passed.
    • <prefix>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/lib for each <prefix> in CMAKE_PREFIX_PATH
    • CMAKE_LIBRARY_PATH
    • CMAKE_FRAMEWORK_PATH
  3. Search paths specified in cmake-specific environment variables. These are intended to be set in the user’s shell configuration, and therefore use the host’s native path separator (; on Windows and : on UNIX). This can be skipped if NO_CMAKE_ENVIRONMENT_PATH is passed.
    • <prefix>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/lib for each <prefix> in CMAKE_PREFIX_PATH
    • CMAKE_LIBRARY_PATH
    • CMAKE_FRAMEWORK_PATH
  4. Search the paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option.
  5. Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is an argument.
    • Directories in LIB. On Windows hosts: <prefix>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/lib for each <prefix>/[s]bin in PATH, and <entry>/lib for other entries in PATH, and the directories in PATH itself.
  6. Search cmake variables defined in the Platform files for the current system. This can be skipped if NO_CMAKE_SYSTEM_PATH is passed.
    • <prefix>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/lib for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
    • CMAKE_SYSTEM_LIBRARY_PATH
    • CMAKE_SYSTEM_FRAMEWORK_PATH
  7. Search the paths specified by the PATHS option or in the short-hand version of the command. These are typically hard-coded guesses.

On macOS the CMAKE_FIND_FRAMEWORK and CMAKE_FIND_APPBUNDLE variables determine the order of preference between Apple-style and unix-style package components.

The CMake variable CMAKE_FIND_ROOT_PATH specifies one or more directories to be prepended to all other search directories. This effectively “re-roots” the entire search under given locations. Paths which are descendants of the CMAKE_STAGING_PREFIX are excluded from this re-rooting, because that variable is always a path on the host system. By default the CMAKE_FIND_ROOT_PATH is empty.

The CMAKE_SYSROOT variable can also be used to specify exactly one directory to use as a prefix. Setting CMAKE_SYSROOT also has other effects. See the documentation for that variable for more.

These variables are especially useful when cross-compiling to point to the root directory of the target environment and CMake will search there too. By default at first the directories listed in CMAKE_FIND_ROOT_PATH are searched, then the CMAKE_SYSROOT directory is searched, and then the non-rooted directories will be searched. The default behavior can be adjusted by setting CMAKE_FIND_ROOT_PATH_MODE_LIBRARY. This behavior can be manually overridden on a per-call basis using options:

CMAKE_FIND_ROOT_PATH_BOTH
Search in the order described above.
NO_CMAKE_FIND_ROOT_PATH
Do not use the CMAKE_FIND_ROOT_PATH variable.
ONLY_CMAKE_FIND_ROOT_PATH
Search only the re-rooted directories and directories below CMAKE_STAGING_PREFIX.

The default search order is designed to be most-specific to least-specific for common use cases. Projects may override the order by simply calling the command multiple times and using the NO_* options:

find_library (<VAR> NAMES name PATHS paths... NO_DEFAULT_PATH)
find_library (<VAR> NAMES name)

Once one of the calls succeeds the result variable will be set and stored in the cache so that no call will search again.

When more than one value is given to the NAMES option this command by default will consider one name at a time and search every directory for it. The NAMES_PER_DIR option tells this command to consider one directory at a time and search for all names in it.

Each library name given to the NAMES option is first considered as a library file name and then considered with platform-specific prefixes (e.g. lib) and suffixes (e.g. .so). Therefore one may specify library file names such as libfoo.a directly. This can be used to locate static libraries on UNIX-like systems.

If the library found is a framework, then <VAR> will be set to the full path to the framework <fullPath>/A.framework. When a full path to a framework is used as a library, CMake will use a -framework A, and a -F<fullPath> to link the framework to the target.

If the CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX variable is set all search paths will be tested as normal, with the suffix appended, and with all matches of lib/ replaced with lib${CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX}/. This variable overrides the FIND_LIBRARY_USE_LIB32_PATHS, FIND_LIBRARY_USE_LIBX32_PATHS, and FIND_LIBRARY_USE_LIB64_PATHS global properties.

If the FIND_LIBRARY_USE_LIB32_PATHS global property is set all search paths will be tested as normal, with 32/ appended, and with all matches of lib/ replaced with lib32/. This property is automatically set for the platforms that are known to need it if at least one of the languages supported by the project() command is enabled.

If the FIND_LIBRARY_USE_LIBX32_PATHS global property is set all search paths will be tested as normal, with x32/ appended, and with all matches of lib/ replaced with libx32/. This property is automatically set for the platforms that are known to need it if at least one of the languages supported by the project() command is enabled.

If the FIND_LIBRARY_USE_LIB64_PATHS global property is set all search paths will be tested as normal, with 64/ appended, and with all matches of lib/ replaced with lib64/. This property is automatically set for the platforms that are known to need it if at least one of the languages supported by the project() command is enabled.

  • cmake-commands(7) »


find_package — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

find_package

Contents

  • find_package
    • Basic Signature and Module Mode
    • Full Signature and Config Mode
    • Version Selection
    • Search Procedure
    • Package File Interface Variables

Find an external project, and load its settings.

Basic Signature and Module Mode

find_package(<PackageName> [version] [EXACT] [QUIET] [MODULE]
             [REQUIRED] [[COMPONENTS] [components...]]
             [OPTIONAL_COMPONENTS components...]
             [NO_POLICY_SCOPE])

Finds and loads settings from an external project. <PackageName>_FOUND will be set to indicate whether the package was found. When the package is found package-specific information is provided through variables and Imported Targets documented by the package itself. The QUIET option disables informational messages, including those indicating that the package cannot be found if it is not REQUIRED. The REQUIRED option stops processing with an error message if the package cannot be found.

A package-specific list of required components may be listed after the COMPONENTS option (or after the REQUIRED option if present). Additional optional components may be listed after OPTIONAL_COMPONENTS. Available components and their influence on whether a package is considered to be found are defined by the target package.

The [version] argument requests a version with which the package found should be compatible (format is major[.minor[.patch[.tweak]]]). The EXACT option requests that the version be matched exactly. If no [version] and/or component list is given to a recursive invocation inside a find-module, the corresponding arguments are forwarded automatically from the outer call (including the EXACT flag for [version]). Version support is currently provided only on a package-by-package basis (see the Version Selection section below).

See the cmake_policy() command documentation for discussion of the NO_POLICY_SCOPE option.

The command has two modes by which it searches for packages: “Module” mode and “Config” mode. The above signature selects Module mode. If no module is found the command falls back to Config mode, described below. This fall back is disabled if the MODULE option is given.

In Module mode, CMake searches for a file called Find<PackageName>.cmake. The file is first searched in the CMAKE_MODULE_PATH, then among the Find Modules provided by the CMake installation. If the file is found, it is read and processed by CMake. It is responsible for finding the package, checking the version, and producing any needed messages. Some find-modules provide limited or no support for versioning; check the module documentation.

Full Signature and Config Mode

User code should generally look for packages using the above basic signature. The remainder of this command documentation specifies the full command signature and details of the search process. Project maintainers wishing to provide a package to be found by this command are encouraged to read on.

The complete Config mode command signature is

find_package(<PackageName> [version] [EXACT] [QUIET]
             [REQUIRED] [[COMPONENTS] [components...]]
             [CONFIG|NO_MODULE]
             [NO_POLICY_SCOPE]
             [NAMES name1 [name2 ...]]
             [CONFIGS config1 [config2 ...]]
             [HINTS path1 [path2 ... ]]
             [PATHS path1 [path2 ... ]]
             [PATH_SUFFIXES suffix1 [suffix2 ...]]
             [NO_DEFAULT_PATH]
             [NO_PACKAGE_ROOT_PATH]
             [NO_CMAKE_PATH]
             [NO_CMAKE_ENVIRONMENT_PATH]
             [NO_SYSTEM_ENVIRONMENT_PATH]
             [NO_CMAKE_PACKAGE_REGISTRY]
             [NO_CMAKE_BUILDS_PATH] # Deprecated; does nothing.
             [NO_CMAKE_SYSTEM_PATH]
             [NO_CMAKE_SYSTEM_PACKAGE_REGISTRY]
             [CMAKE_FIND_ROOT_PATH_BOTH |
              ONLY_CMAKE_FIND_ROOT_PATH |
              NO_CMAKE_FIND_ROOT_PATH])

The CONFIG option, the synonymous NO_MODULE option, or the use of options not specified in the basic signature all enforce pure Config mode. In pure Config mode, the command skips Module mode search and proceeds at once with Config mode search.

Config mode search attempts to locate a configuration file provided by the package to be found. A cache entry called <PackageName>_DIR is created to hold the directory containing the file. By default the command searches for a package with the name <PackageName>. If the NAMES option is given the names following it are used instead of <PackageName>. The command searches for a file called <PackageName>Config.cmake or <lower-case-package-name>-config.cmake for each name specified. A replacement set of possible configuration file names may be given using the CONFIGS option. The search procedure is specified below. Once found, the configuration file is read and processed by CMake. Since the file is provided by the package it already knows the location of package contents. The full path to the configuration file is stored in the cmake variable <PackageName>_CONFIG.

All configuration files which have been considered by CMake while searching for an installation of the package with an appropriate version are stored in the cmake variable <PackageName>_CONSIDERED_CONFIGS, the associated versions in <PackageName>_CONSIDERED_VERSIONS.

If the package configuration file cannot be found CMake will generate an error describing the problem unless the QUIET argument is specified. If REQUIRED is specified and the package is not found a fatal error is generated and the configure step stops executing. If <PackageName>_DIR has been set to a directory not containing a configuration file CMake will ignore it and search from scratch.

Package maintainers providing CMake package configuration files are encouraged to name and install them such that the Search Procedure outlined below will find them without requiring use of additional options.

Version Selection

When the [version] argument is given Config mode will only find a version of the package that claims compatibility with the requested version (format is major[.minor[.patch[.tweak]]]). If the EXACT option is given only a version of the package claiming an exact match of the requested version may be found. CMake does not establish any convention for the meaning of version numbers. Package version numbers are checked by “version” files provided by the packages themselves. For a candidate package configuration file <config-file>.cmake the corresponding version file is located next to it and named either <config-file>-version.cmake or <config-file>Version.cmake. If no such version file is available then the configuration file is assumed to not be compatible with any requested version. A basic version file containing generic version matching code can be created using the CMakePackageConfigHelpers module. When a version file is found it is loaded to check the requested version number. The version file is loaded in a nested scope in which the following variables have been defined:

PACKAGE_FIND_NAME
the <PackageName>
PACKAGE_FIND_VERSION
full requested version string
PACKAGE_FIND_VERSION_MAJOR
major version if requested, else 0
PACKAGE_FIND_VERSION_MINOR
minor version if requested, else 0
PACKAGE_FIND_VERSION_PATCH
patch version if requested, else 0
PACKAGE_FIND_VERSION_TWEAK
tweak version if requested, else 0
PACKAGE_FIND_VERSION_COUNT
number of version components, 0 to 4

The version file checks whether it satisfies the requested version and sets these variables:

PACKAGE_VERSION
full provided version string
PACKAGE_VERSION_EXACT
true if version is exact match
PACKAGE_VERSION_COMPATIBLE
true if version is compatible
PACKAGE_VERSION_UNSUITABLE
true if unsuitable as any version

These variables are checked by the find_package command to determine whether the configuration file provides an acceptable version. They are not available after the find_package call returns. If the version is acceptable the following variables are set:

<PackageName>_VERSION
full provided version string
<PackageName>_VERSION_MAJOR
major version if provided, else 0
<PackageName>_VERSION_MINOR
minor version if provided, else 0
<PackageName>_VERSION_PATCH
patch version if provided, else 0
<PackageName>_VERSION_TWEAK
tweak version if provided, else 0
<PackageName>_VERSION_COUNT
number of version components, 0 to 4

and the corresponding package configuration file is loaded. When multiple package configuration files are available whose version files claim compatibility with the version requested it is unspecified which one is chosen: unless the variable CMAKE_FIND_PACKAGE_SORT_ORDER is set no attempt is made to choose a highest or closest version number.

To control the order in which find_package checks for compatibility use the two variables CMAKE_FIND_PACKAGE_SORT_ORDER and CMAKE_FIND_PACKAGE_SORT_DIRECTION. For instance in order to select the highest version one can set

SET(CMAKE_FIND_PACKAGE_SORT_ORDER NATURAL)
SET(CMAKE_FIND_PACKAGE_SORT_DIRECTION DEC)

before calling find_package.

Search Procedure

CMake constructs a set of possible installation prefixes for the package. Under each prefix several directories are searched for a configuration file. The tables below show the directories searched. Each entry is meant for installation trees following Windows (W), UNIX (U), or Apple (A) conventions:

<prefix>/                                                       (W)
<prefix>/(cmake|CMake)/                                         (W)
<prefix>/<name>*/                                               (W)
<prefix>/<name>*/(cmake|CMake)/                                 (W)
<prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/                 (U)
<prefix>/(lib/<arch>|lib*|share)/<name>*/                       (U)
<prefix>/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/         (U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/cmake/<name>*/         (W/U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/               (W/U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/ (W/U)

On systems supporting macOS Frameworks and Application Bundles the following directories are searched for frameworks or bundles containing a configuration file:

<prefix>/<name>.framework/Resources/                    (A)
<prefix>/<name>.framework/Resources/CMake/              (A)
<prefix>/<name>.framework/Versions/*/Resources/         (A)
<prefix>/<name>.framework/Versions/*/Resources/CMake/   (A)
<prefix>/<name>.app/Contents/Resources/                 (A)
<prefix>/<name>.app/Contents/Resources/CMake/           (A)

In all cases the <name> is treated as case-insensitive and corresponds to any of the names specified (<PackageName> or names given by NAMES).

Paths with lib/<arch> are enabled if the CMAKE_LIBRARY_ARCHITECTURE variable is set. lib* includes one or more of the values lib64, lib32, libx32 or lib (searched in that order).

  • Paths with lib64 are searched on 64 bit platforms if the FIND_LIBRARY_USE_LIB64_PATHS property is set to TRUE.
  • Paths with lib32 are searched on 32 bit platforms if the FIND_LIBRARY_USE_LIB32_PATHS property is set to TRUE.
  • Paths with libx32 are searched on platforms using the x32 ABI if the FIND_LIBRARY_USE_LIBX32_PATHS property is set to TRUE.
  • The lib path is always searched.

If PATH_SUFFIXES is specified, the suffixes are appended to each (W) or (U) directory entry one-by-one.

This set of directories is intended to work in cooperation with projects that provide configuration files in their installation trees. Directories above marked with (W) are intended for installations on Windows where the prefix may point at the top of an application’s installation directory. Those marked with (U) are intended for installations on UNIX platforms where the prefix is shared by multiple packages. This is merely a convention, so all (W) and (U) directories are still searched on all platforms. Directories marked with (A) are intended for installations on Apple platforms. The CMAKE_FIND_FRAMEWORK and CMAKE_FIND_APPBUNDLE variables determine the order of preference.

The set of installation prefixes is constructed using the following steps. If NO_DEFAULT_PATH is specified all NO_* options are enabled.

  1. Search paths specified in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable, where <PackageName> is the package to be found. The package root variables are maintained as a stack so if called from within a find module, root paths from the parent’s find module will also be searched after paths for the current package. This can be skipped if NO_PACKAGE_ROOT_PATH is passed. See policy CMP0074.

  2. Search paths specified in cmake-specific cache variables. These are intended to be used on the command line with a -DVAR=value. The values are interpreted as semicolon-separated lists. This can be skipped if NO_CMAKE_PATH is passed:

    CMAKE_PREFIX_PATH
CMAKE_FRAMEWORK_PATH
CMAKE_APPBUNDLE_PATH

  3. Search paths specified in cmake-specific environment variables. These are intended to be set in the user’s shell configuration, and therefore use the host’s native path separator (; on Windows and : on UNIX). This can be skipped if NO_CMAKE_ENVIRONMENT_PATH is passed:

    <PackageName>_DIR
CMAKE_PREFIX_PATH
CMAKE_FRAMEWORK_PATH
CMAKE_APPBUNDLE_PATH

  4. Search paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option.

  5. Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is passed. Path entries ending in /bin or /sbin are automatically converted to their parent directories:

    PATH

  6. Search paths stored in the CMake User Package Registry. This can be skipped if NO_CMAKE_PACKAGE_REGISTRY is passed or by setting the CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY to TRUE. See the cmake-packages(7) manual for details on the user package registry.

  7. Search cmake variables defined in the Platform files for the current system. This can be skipped if NO_CMAKE_SYSTEM_PATH is passed:

    CMAKE_SYSTEM_PREFIX_PATH
CMAKE_SYSTEM_FRAMEWORK_PATH
CMAKE_SYSTEM_APPBUNDLE_PATH

  8. Search paths stored in the CMake System Package Registry. This can be skipped if NO_CMAKE_SYSTEM_PACKAGE_REGISTRY is passed or by setting the CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY to TRUE. See the cmake-packages(7) manual for details on the system package registry.

  9. Search paths specified by the PATHS option. These are typically hard-coded guesses.

The CMake variable CMAKE_FIND_ROOT_PATH specifies one or more directories to be prepended to all other search directories. This effectively “re-roots” the entire search under given locations. Paths which are descendants of the CMAKE_STAGING_PREFIX are excluded from this re-rooting, because that variable is always a path on the host system. By default the CMAKE_FIND_ROOT_PATH is empty.

The CMAKE_SYSROOT variable can also be used to specify exactly one directory to use as a prefix. Setting CMAKE_SYSROOT also has other effects. See the documentation for that variable for more.

These variables are especially useful when cross-compiling to point to the root directory of the target environment and CMake will search there too. By default at first the directories listed in CMAKE_FIND_ROOT_PATH are searched, then the CMAKE_SYSROOT directory is searched, and then the non-rooted directories will be searched. The default behavior can be adjusted by setting CMAKE_FIND_ROOT_PATH_MODE_PACKAGE. This behavior can be manually overridden on a per-call basis using options:

CMAKE_FIND_ROOT_PATH_BOTH
Search in the order described above.
NO_CMAKE_FIND_ROOT_PATH
Do not use the CMAKE_FIND_ROOT_PATH variable.
ONLY_CMAKE_FIND_ROOT_PATH
Search only the re-rooted directories and directories below CMAKE_STAGING_PREFIX.

The default search order is designed to be most-specific to least-specific for common use cases. Projects may override the order by simply calling the command multiple times and using the NO_* options:

find_package (<PackageName> PATHS paths... NO_DEFAULT_PATH)
find_package (<PackageName>)

Once one of the calls succeeds the result variable will be set and stored in the cache so that no call will search again.

By default the value stored in the result variable will be the path at which the file is found. The CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS variable may be set to TRUE before calling find_package in order to resolve symbolic links and store the real path to the file.

Every non-REQUIRED find_package call can be disabled by setting the CMAKE_DISABLE_FIND_PACKAGE_<PackageName> variable to TRUE.

Package File Interface Variables

When loading a find module or package configuration file find_package defines variables to provide information about the call arguments (and restores their original state before returning):

CMAKE_FIND_PACKAGE_NAME
the <PackageName> which is searched for
<PackageName>_FIND_REQUIRED
true if REQUIRED option was given
<PackageName>_FIND_QUIETLY
true if QUIET option was given
<PackageName>_FIND_VERSION
full requested version string
<PackageName>_FIND_VERSION_MAJOR
major version if requested, else 0
<PackageName>_FIND_VERSION_MINOR
minor version if requested, else 0
<PackageName>_FIND_VERSION_PATCH
patch version if requested, else 0
<PackageName>_FIND_VERSION_TWEAK
tweak version if requested, else 0
<PackageName>_FIND_VERSION_COUNT
number of version components, 0 to 4
<PackageName>_FIND_VERSION_EXACT
true if EXACT option was given
<PackageName>_FIND_COMPONENTS
list of requested components
<PackageName>_FIND_REQUIRED_<c>
true if component <c> is required, false if component <c> is optional

In Module mode the loaded find module is responsible to honor the request detailed by these variables; see the find module for details. In Config mode find_package handles REQUIRED, QUIET, and [version] options automatically but leaves it to the package configuration file to handle components in a way that makes sense for the package. The package configuration file may set <PackageName>_FOUND to false to tell find_package that component requirements are not satisfied.

  • cmake-commands(7) »


find_path — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

find_path

A short-hand signature is:

find_path (<VAR> name1 [path1 path2 ...])

The general signature is:

find_path (
          <VAR>
          name | NAMES name1 [name2 ...]
          [HINTS path1 [path2 ... ENV var]]
          [PATHS path1 [path2 ... ENV var]]
          [PATH_SUFFIXES suffix1 [suffix2 ...]]
          [DOC "cache documentation string"]
          [NO_DEFAULT_PATH]
          [NO_PACKAGE_ROOT_PATH]
          [NO_CMAKE_PATH]
          [NO_CMAKE_ENVIRONMENT_PATH]
          [NO_SYSTEM_ENVIRONMENT_PATH]
          [NO_CMAKE_SYSTEM_PATH]
          [CMAKE_FIND_ROOT_PATH_BOTH |
           ONLY_CMAKE_FIND_ROOT_PATH |
           NO_CMAKE_FIND_ROOT_PATH]
         )

This command is used to find a directory containing the named file. A cache entry named by <VAR> is created to store the result of this command. If the file in a directory is found the result is stored in the variable and the search will not be repeated unless the variable is cleared. If nothing is found, the result will be <VAR>-NOTFOUND, and the search will be attempted again the next time find_path is invoked with the same variable.

Options include:

NAMES

Specify one or more possible names for the file in a directory.

When using this to specify names with and without a version suffix, we recommend specifying the unversioned name first so that locally-built packages can be found before those provided by distributions.

HINTS, PATHS
Specify directories to search in addition to the default locations. The ENV var sub-option reads paths from a system environment variable.
PATH_SUFFIXES
Specify additional subdirectories to check below each directory location otherwise considered.
DOC
Specify the documentation string for the <VAR> cache entry.

If NO_DEFAULT_PATH is specified, then no additional paths are added to the search. If NO_DEFAULT_PATH is not specified, the search process is as follows:

  1. If called from within a find module loaded by find_package(<PackageName>), search prefixes unique to the current package being found. Specifically look in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable. The package root variables are maintained as a stack so if called from nested find modules, root paths from the parent’s find module will be searched after paths from the current module, i.e. <CurrentPackage>_ROOT, ENV{<CurrentPackage>_ROOT}, <ParentPackage>_ROOT, ENV{<ParentPackage>_ROOT}, etc. This can be skipped if NO_PACKAGE_ROOT_PATH is passed. See policy CMP0074.
    • <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix> in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable if called from within a find module loaded by find_package(<PackageName>)
  2. Search paths specified in cmake-specific cache variables. These are intended to be used on the command line with a -DVAR=value. The values are interpreted as semicolon-separated lists. This can be skipped if NO_CMAKE_PATH is passed.
    • <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
    • CMAKE_INCLUDE_PATH
    • CMAKE_FRAMEWORK_PATH
  3. Search paths specified in cmake-specific environment variables. These are intended to be set in the user’s shell configuration, and therefore use the host’s native path separator (; on Windows and : on UNIX). This can be skipped if NO_CMAKE_ENVIRONMENT_PATH is passed.
    • <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
    • CMAKE_INCLUDE_PATH
    • CMAKE_FRAMEWORK_PATH
  4. Search the paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option.
  5. Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is an argument.
    • Directories in INCLUDE. On Windows hosts: <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix>/[s]bin in PATH, and <entry>/include for other entries in PATH, and the directories in PATH itself.
  6. Search cmake variables defined in the Platform files for the current system. This can be skipped if NO_CMAKE_SYSTEM_PATH is passed.
    • <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and <prefix>/include for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
    • CMAKE_SYSTEM_INCLUDE_PATH
    • CMAKE_SYSTEM_FRAMEWORK_PATH
  7. Search the paths specified by the PATHS option or in the short-hand version of the command. These are typically hard-coded guesses.

On macOS the CMAKE_FIND_FRAMEWORK and CMAKE_FIND_APPBUNDLE variables determine the order of preference between Apple-style and unix-style package components.

The CMake variable CMAKE_FIND_ROOT_PATH specifies one or more directories to be prepended to all other search directories. This effectively “re-roots” the entire search under given locations. Paths which are descendants of the CMAKE_STAGING_PREFIX are excluded from this re-rooting, because that variable is always a path on the host system. By default the CMAKE_FIND_ROOT_PATH is empty.

The CMAKE_SYSROOT variable can also be used to specify exactly one directory to use as a prefix. Setting CMAKE_SYSROOT also has other effects. See the documentation for that variable for more.

These variables are especially useful when cross-compiling to point to the root directory of the target environment and CMake will search there too. By default at first the directories listed in CMAKE_FIND_ROOT_PATH are searched, then the CMAKE_SYSROOT directory is searched, and then the non-rooted directories will be searched. The default behavior can be adjusted by setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE. This behavior can be manually overridden on a per-call basis using options:

CMAKE_FIND_ROOT_PATH_BOTH
Search in the order described above.
NO_CMAKE_FIND_ROOT_PATH
Do not use the CMAKE_FIND_ROOT_PATH variable.
ONLY_CMAKE_FIND_ROOT_PATH
Search only the re-rooted directories and directories below CMAKE_STAGING_PREFIX.

The default search order is designed to be most-specific to least-specific for common use cases. Projects may override the order by simply calling the command multiple times and using the NO_* options:

find_path (<VAR> NAMES name PATHS paths... NO_DEFAULT_PATH)
find_path (<VAR> NAMES name)

Once one of the calls succeeds the result variable will be set and stored in the cache so that no call will search again.

When searching for frameworks, if the file is specified as A/b.h, then the framework search will look for A.framework/Headers/b.h. If that is found the path will be set to the path to the framework. CMake will convert this to the correct -F option to include the file.

  • cmake-commands(7) »


find_program — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

find_program

A short-hand signature is:

find_program (<VAR> name1 [path1 path2 ...])

The general signature is:

find_program (
          <VAR>
          name | NAMES name1 [name2 ...] [NAMES_PER_DIR]
          [HINTS path1 [path2 ... ENV var]]
          [PATHS path1 [path2 ... ENV var]]
          [PATH_SUFFIXES suffix1 [suffix2 ...]]
          [DOC "cache documentation string"]
          [NO_DEFAULT_PATH]
          [NO_PACKAGE_ROOT_PATH]
          [NO_CMAKE_PATH]
          [NO_CMAKE_ENVIRONMENT_PATH]
          [NO_SYSTEM_ENVIRONMENT_PATH]
          [NO_CMAKE_SYSTEM_PATH]
          [CMAKE_FIND_ROOT_PATH_BOTH |
           ONLY_CMAKE_FIND_ROOT_PATH |
           NO_CMAKE_FIND_ROOT_PATH]
         )

This command is used to find a program. A cache entry named by <VAR> is created to store the result of this command. If the program is found the result is stored in the variable and the search will not be repeated unless the variable is cleared. If nothing is found, the result will be <VAR>-NOTFOUND, and the search will be attempted again the next time find_program is invoked with the same variable.

Options include:

NAMES

Specify one or more possible names for the program.

When using this to specify names with and without a version suffix, we recommend specifying the unversioned name first so that locally-built packages can be found before those provided by distributions.

HINTS, PATHS
Specify directories to search in addition to the default locations. The ENV var sub-option reads paths from a system environment variable.
PATH_SUFFIXES
Specify additional subdirectories to check below each directory location otherwise considered.
DOC
Specify the documentation string for the <VAR> cache entry.

If NO_DEFAULT_PATH is specified, then no additional paths are added to the search. If NO_DEFAULT_PATH is not specified, the search process is as follows:

  1. If called from within a find module loaded by find_package(<PackageName>), search prefixes unique to the current package being found. Specifically look in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable. The package root variables are maintained as a stack so if called from nested find modules, root paths from the parent’s find module will be searched after paths from the current module, i.e. <CurrentPackage>_ROOT, ENV{<CurrentPackage>_ROOT}, <ParentPackage>_ROOT, ENV{<ParentPackage>_ROOT}, etc. This can be skipped if NO_PACKAGE_ROOT_PATH is passed. See policy CMP0074.
    • <prefix>/[s]bin for each <prefix> in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable if called from within a find module loaded by find_package(<PackageName>)
  2. Search paths specified in cmake-specific cache variables. These are intended to be used on the command line with a -DVAR=value. The values are interpreted as semicolon-separated lists. This can be skipped if NO_CMAKE_PATH is passed.
    • <prefix>/[s]bin for each <prefix> in CMAKE_PREFIX_PATH
    • CMAKE_PROGRAM_PATH
    • CMAKE_APPBUNDLE_PATH
  3. Search paths specified in cmake-specific environment variables. These are intended to be set in the user’s shell configuration, and therefore use the host’s native path separator (; on Windows and : on UNIX). This can be skipped if NO_CMAKE_ENVIRONMENT_PATH is passed.
    • <prefix>/[s]bin for each <prefix> in CMAKE_PREFIX_PATH
    • CMAKE_PROGRAM_PATH
    • CMAKE_APPBUNDLE_PATH
  4. Search the paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option.
  5. Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is an argument.
    • PATH
  6. Search cmake variables defined in the Platform files for the current system. This can be skipped if NO_CMAKE_SYSTEM_PATH is passed.
    • <prefix>/[s]bin for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
    • CMAKE_SYSTEM_PROGRAM_PATH
    • CMAKE_SYSTEM_APPBUNDLE_PATH
  7. Search the paths specified by the PATHS option or in the short-hand version of the command. These are typically hard-coded guesses.

On macOS the CMAKE_FIND_FRAMEWORK and CMAKE_FIND_APPBUNDLE variables determine the order of preference between Apple-style and unix-style package components.

The CMake variable CMAKE_FIND_ROOT_PATH specifies one or more directories to be prepended to all other search directories. This effectively “re-roots” the entire search under given locations. Paths which are descendants of the CMAKE_STAGING_PREFIX are excluded from this re-rooting, because that variable is always a path on the host system. By default the CMAKE_FIND_ROOT_PATH is empty.

The CMAKE_SYSROOT variable can also be used to specify exactly one directory to use as a prefix. Setting CMAKE_SYSROOT also has other effects. See the documentation for that variable for more.

These variables are especially useful when cross-compiling to point to the root directory of the target environment and CMake will search there too. By default at first the directories listed in CMAKE_FIND_ROOT_PATH are searched, then the CMAKE_SYSROOT directory is searched, and then the non-rooted directories will be searched. The default behavior can be adjusted by setting CMAKE_FIND_ROOT_PATH_MODE_PROGRAM. This behavior can be manually overridden on a per-call basis using options:

CMAKE_FIND_ROOT_PATH_BOTH
Search in the order described above.
NO_CMAKE_FIND_ROOT_PATH
Do not use the CMAKE_FIND_ROOT_PATH variable.
ONLY_CMAKE_FIND_ROOT_PATH
Search only the re-rooted directories and directories below CMAKE_STAGING_PREFIX.

The default search order is designed to be most-specific to least-specific for common use cases. Projects may override the order by simply calling the command multiple times and using the NO_* options:

find_program (<VAR> NAMES name PATHS paths... NO_DEFAULT_PATH)
find_program (<VAR> NAMES name)

Once one of the calls succeeds the result variable will be set and stored in the cache so that no call will search again.

When more than one value is given to the NAMES option this command by default will consider one name at a time and search every directory for it. The NAMES_PER_DIR option tells this command to consider one directory at a time and search for all names in it.

  • cmake-commands(7) »


foreach — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

foreach

Evaluate a group of commands for each value in a list.

foreach(<loop_var> <items>)
  <commands>
endforeach()

where <items> is a list of items that are separated by semicolon or whitespace. All commands between foreach and the matching endforeach are recorded without being invoked. Once the endforeach is evaluated, the recorded list of commands is invoked once for each item in <items>. At the beginning of each iteration the variable loop_var will be set to the value of the current item.

The commands break() and continue() provide means to escape from the normal control flow.

Per legacy, the endforeach() command admits an optional <loop_var> argument. If used, it must be a verbatim repeat of the argument of the opening foreach command.

foreach(<loop_var> RANGE <stop>)

In this variant, foreach iterates over the numbers 0, 1, … up to (and including) the nonnegative integer <stop>.

foreach(<loop_var> RANGE <start> <stop> [<step>])

In this variant, foreach iterates over the numbers from <start> up to at most <stop> in steps of <step>. If <step> is not specified, then the step size is 1. The three arguments <start> <stop> <step> must all be nonnegative integers, and <stop> must not be smaller than <start>; otherwise you enter the danger zone of undocumented behavior that may change in future releases.

foreach(loop_var IN [LISTS [<lists>]] [ITEMS [<items>]])

In this variant, <lists> is a whitespace or semicolon separated list of list-valued variables. The foreach command iterates over each item in each given list. The <items> following the ITEMS keyword are processed as in the first variant of the foreach command. The forms LISTS A and ITEMS ${A} are equivalent.

The following example shows how the LISTS option is processed:

set(A 0;1)
set(B 2 3)
set(C "4 5")
set(D 6;7 8)
set(E "")
foreach(X IN LISTS A B C D E)
    message(STATUS "X=${X}")
endforeach()

yields

-- X=0
-- X=1
-- X=2
-- X=3
-- X=4 5
-- X=6
-- X=7
-- X=8

  • cmake-commands(7) »


function — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

function

Start recording a function for later invocation as a command.

function(<name> [<arg1> ...])
  <commands>
endfunction()

Defines a function named <name> that takes arguments named <arg1>, … The <commands> in the function definition are recorded; they are not executed until the function is invoked.

Per legacy, the endfunction() command admits an optional <name> argument. If used, it must be a verbatim repeat of the argument of the opening function command.

A function opens a new scope: see set(var PARENT_SCOPE) for details.

See the cmake_policy() command documentation for the behavior of policies inside functions.

See the macro() command documentation for differences between CMake functions and macros.

Invocation

The function invocation is case-insensitive. A function defined as

function(foo)
  <commands>
endfunction()

can be invoked through any of

foo()
Foo()
FOO()

and so on. However, it is strongly recommended to stay with the case chosen in the function definition. Typically functions use all-lowercase names.

Arguments

When the function is invoked, the recorded <commands> are first modified by replacing formal parameters (${arg1}, …) with the arguments passed, and then invoked as normal commands.

In addition to referencing the formal parameters you can reference the ARGC variable which will be set to the number of arguments passed into the function as well as ARGV0, ARGV1, ARGV2, … which will have the actual values of the arguments passed in. This facilitates creating functions with optional arguments.

Furthermore, ARGV holds the list of all arguments given to the function and ARGN holds the list of arguments past the last expected argument. Referencing to ARGV# arguments beyond ARGC have undefined behavior. Checking that ARGC is greater than # is the only way to ensure that ARGV# was passed to the function as an extra argument.

  • cmake-commands(7) »


get_cmake_property — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

get_cmake_property

Get a global property of the CMake instance.

get_cmake_property(<var> <property>)

Gets a global property from the CMake instance. The value of the <property> is stored in the variable <var>. If the property is not found, <var> will be set to "NOTFOUND". See the cmake-properties(7) manual for available properties.

See also the get_property() command GLOBAL option.

In addition to global properties, this command (for historical reasons) also supports the VARIABLES and MACROS directory properties. It also supports a special COMPONENTS global property that lists the components given to the install() command.

  • cmake-commands(7) »


get_directory_property — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

get_directory_property

Get a property of DIRECTORY scope.

get_directory_property(<variable> [DIRECTORY <dir>] <prop-name>)

Stores a property of directory scope in the named <variable>. The DIRECTORY argument specifies another directory from which to retrieve the property value instead of the current directory. The specified directory must have already been traversed by CMake.

If the property is not defined for the nominated directory scope, an empty string is returned. In the case of INHERITED properties, if the property is not found for the nominated directory scope, the search will chain to a parent scope as described for the define_property() command.

get_directory_property(<variable> [DIRECTORY <dir>]
                       DEFINITION <var-name>)

Get a variable definition from a directory. This form is useful to get a variable definition from another directory.

See also the more general get_property() command.

  • cmake-commands(7) »


get_filename_component — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

get_filename_component

Get a specific component of a full filename.

get_filename_component(<var> <FileName> <mode> [CACHE])

Sets <var> to a component of <FileName>, where <mode> is one of:

DIRECTORY = Directory without file name
NAME      = File name without directory
EXT       = File name longest extension (.b.c from d/a.b.c)
NAME_WE   = File name without directory or longest extension
LAST_EXT  = File name last extension (.c from d/a.b.c)
NAME_WLE  = File name without directory or last extension
PATH      = Legacy alias for DIRECTORY (use for CMake <= 2.8.11)

Paths are returned with forward slashes and have no trailing slashes. If the optional CACHE argument is specified, the result variable is added to the cache.

get_filename_component(<var> <FileName> <mode> [BASE_DIR <dir>] [CACHE])

Sets <var> to the absolute path of <FileName>, where <mode> is one of:

ABSOLUTE  = Full path to file
REALPATH  = Full path to existing file with symlinks resolved

If the provided <FileName> is a relative path, it is evaluated relative to the given base directory <dir>. If no base directory is provided, the default base directory will be CMAKE_CURRENT_SOURCE_DIR.

Paths are returned with forward slashes and have no trailing slashes. If the optional CACHE argument is specified, the result variable is added to the cache.

get_filename_component(<var> <FileName> PROGRAM [PROGRAM_ARGS <arg_var>] [CACHE])

The program in <FileName> will be found in the system search path or left as a full path. If PROGRAM_ARGS is present with PROGRAM, then any command-line arguments present in the <FileName> string are split from the program name and stored in <arg_var>. This is used to separate a program name from its arguments in a command line string.

  • cmake-commands(7) »


get_property — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

get_property

Get a property.

get_property(<variable>
             <GLOBAL             |
              DIRECTORY [<dir>]  |
              TARGET    <target> |
              SOURCE    <source> |
              INSTALL   <file>   |
              TEST      <test>   |
              CACHE     <entry>  |
              VARIABLE           >
             PROPERTY <name>
             [SET | DEFINED | BRIEF_DOCS | FULL_DOCS])

Gets one property from one object in a scope.

The first argument specifies the variable in which to store the result. The second argument determines the scope from which to get the property. It must be one of the following:

GLOBAL
Scope is unique and does not accept a name.
DIRECTORY
Scope defaults to the current directory but another directory (already processed by CMake) may be named by the full or relative path <dir>.
TARGET
Scope must name one existing target.
SOURCE
Scope must name one source file.
INSTALL
Scope must name one installed file path.
TEST
Scope must name one existing test.
CACHE
Scope must name one cache entry.
VARIABLE
Scope is unique and does not accept a name.

The required PROPERTY option is immediately followed by the name of the property to get. If the property is not set an empty value is returned, although some properties support inheriting from a parent scope if defined to behave that way (see define_property()).

If the SET option is given the variable is set to a boolean value indicating whether the property has been set. If the DEFINED option is given the variable is set to a boolean value indicating whether the property has been defined such as with the define_property() command.

If BRIEF_DOCS or FULL_DOCS is given then the variable is set to a string containing documentation for the requested property. If documentation is requested for a property that has not been defined NOTFOUND is returned.

  • cmake-commands(7) »


if — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

if

Conditionally execute a group of commands.

Synopsis

if(<condition>)
  <commands>
elseif(<condition>) # optional block, can be repeated
  <commands>
else()              # optional block
  <commands>
endif()

Evaluates the condition argument of the if clause according to the Condition syntax described below. If the result is true, then the commands in the if block are executed. Otherwise, optional elseif blocks are processed in the same way. Finally, if no condition is true, commands in the optional else block are executed.

Per legacy, the else() and endif() commands admit an optional <condition> argument. If used, it must be a verbatim repeat of the argument of the opening if command.

Condition Syntax

The following syntax applies to the condition argument of the if, elseif and while() clauses.

Compound conditions are evaluated in the following order of precedence: Innermost parentheses are evaluated first. Next come unary tests such as EXISTS, COMMAND, and DEFINED. Then binary tests such as EQUAL, LESS, LESS_EQUAL, GREATER, GREATER_EQUAL, STREQUAL, STRLESS, STRLESS_EQUAL, STRGREATER, STRGREATER_EQUAL, VERSION_EQUAL, VERSION_LESS, VERSION_LESS_EQUAL, VERSION_GREATER, VERSION_GREATER_EQUAL, and MATCHES. Then the boolean operators in the order NOT, AND, and finally OR.

Possible conditions are:

if(<constant>)
True if the constant is 1, ON, YES, TRUE, Y, or a non-zero number. False if the constant is 0, OFF, NO, FALSE, N, IGNORE, NOTFOUND, the empty string, or ends in the suffix -NOTFOUND. Named boolean constants are case-insensitive. If the argument is not one of these specific constants, it is treated as a variable or string and the following signature is used.
if(<variable|string>)
True if given a variable that is defined to a value that is not a false constant. False otherwise. (Note macro arguments are not variables.)
if(NOT <condition>)
True if the condition is not true.
if(<cond1> AND <cond2>)
True if both conditions would be considered true individually.
if(<cond1> OR <cond2>)
True if either condition would be considered true individually.
if(COMMAND command-name)
True if the given name is a command, macro or function that can be invoked.
if(POLICY policy-id)
True if the given name is an existing policy (of the form CMP<NNNN>).
if(TARGET target-name)
True if the given name is an existing logical target name created by a call to the add_executable(), add_library(), or add_custom_target() command that has already been invoked (in any directory).
if(TEST test-name)
True if the given name is an existing test name created by the add_test() command.
if(EXISTS path-to-file-or-directory)
True if the named file or directory exists. Behavior is well-defined only for full paths.
if(file1 IS_NEWER_THAN file2)
True if file1 is newer than file2 or if one of the two files doesn’t exist. Behavior is well-defined only for full paths. If the file time stamps are exactly the same, an IS_NEWER_THAN comparison returns true, so that any dependent build operations will occur in the event of a tie. This includes the case of passing the same file name for both file1 and file2.
if(IS_DIRECTORY path-to-directory)
True if the given name is a directory. Behavior is well-defined only for full paths.
if(IS_SYMLINK file-name)
True if the given name is a symbolic link. Behavior is well-defined only for full paths.
if(IS_ABSOLUTE path)
True if the given path is an absolute path.
if(<variable|string> MATCHES regex)
True if the given string or variable’s value matches the given regular condition. See Regex Specification for regex format. () groups are captured in CMAKE_MATCH_<n> variables.
if(<variable|string> LESS <variable|string>)
True if the given string or variable’s value is a valid number and less than that on the right.
if(<variable|string> GREATER <variable|string>)
True if the given string or variable’s value is a valid number and greater than that on the right.
if(<variable|string> EQUAL <variable|string>)
True if the given string or variable’s value is a valid number and equal to that on the right.
if(<variable|string> LESS_EQUAL <variable|string>)
True if the given string or variable’s value is a valid number and less than or equal to that on the right.
if(<variable|string> GREATER_EQUAL <variable|string>)
True if the given string or variable’s value is a valid number and greater than or equal to that on the right.
if(<variable|string> STRLESS <variable|string>)
True if the given string or variable’s value is lexicographically less than the string or variable on the right.
if(<variable|string> STRGREATER <variable|string>)
True if the given string or variable’s value is lexicographically greater than the string or variable on the right.
if(<variable|string> STREQUAL <variable|string>)
True if the given string or variable’s value is lexicographically equal to the string or variable on the right.
if(<variable|string> STRLESS_EQUAL <variable|string>)
True if the given string or variable’s value is lexicographically less than or equal to the string or variable on the right.
if(<variable|string> STRGREATER_EQUAL <variable|string>)
True if the given string or variable’s value is lexicographically greater than or equal to the string or variable on the right.
if(<variable|string> VERSION_LESS <variable|string>)
Component-wise integer version number comparison (version format is major[.minor[.patch[.tweak]]], omitted components are treated as zero). Any non-integer version component or non-integer trailing part of a version component effectively truncates the string at that point.
if(<variable|string> VERSION_GREATER <variable|string>)
Component-wise integer version number comparison (version format is major[.minor[.patch[.tweak]]], omitted components are treated as zero). Any non-integer version component or non-integer trailing part of a version component effectively truncates the string at that point.
if(<variable|string> VERSION_EQUAL <variable|string>)
Component-wise integer version number comparison (version format is major[.minor[.patch[.tweak]]], omitted components are treated as zero). Any non-integer version component or non-integer trailing part of a version component effectively truncates the string at that point.
if(<variable|string> VERSION_LESS_EQUAL <variable|string>)
Component-wise integer version number comparison (version format is major[.minor[.patch[.tweak]]], omitted components are treated as zero). Any non-integer version component or non-integer trailing part of a version component effectively truncates the string at that point.
if(<variable|string> VERSION_GREATER_EQUAL <variable|string>)
Component-wise integer version number comparison (version format is major[.minor[.patch[.tweak]]], omitted components are treated as zero). Any non-integer version component or non-integer trailing part of a version component effectively truncates the string at that point.
if(<variable|string> IN_LIST <variable>)
True if the given element is contained in the named list variable.
if(DEFINED <name>|CACHE{<name>}|ENV{<name>})
True if a variable, cache variable or environment variable with given <name> is defined. The value of the variable does not matter. Note that macro arguments are not variables.
if((condition) AND (condition OR (condition)))
The conditions inside the parenthesis are evaluated first and then the remaining condition is evaluated as in the previous examples. Where there are nested parenthesis the innermost are evaluated as part of evaluating the condition that contains them.

Variable Expansion

The if command was written very early in CMake’s history, predating the ${} variable evaluation syntax, and for convenience evaluates variables named by its arguments as shown in the above signatures. Note that normal variable evaluation with ${} applies before the if command even receives the arguments. Therefore code like

set(var1 OFF)
set(var2 "var1")
if(${var2})

appears to the if command as

if(var1)

and is evaluated according to the if(<variable>) case documented above. The result is OFF which is false. However, if we remove the ${} from the example then the command sees

if(var2)

which is true because var2 is defined to “var1” which is not a false constant.

Automatic evaluation applies in the other cases whenever the above-documented condition syntax accepts <variable|string>:

  • The left hand argument to MATCHES is first checked to see if it is a defined variable, if so the variable’s value is used, otherwise the original value is used.
  • If the left hand argument to MATCHES is missing it returns false without error
  • Both left and right hand arguments to LESS, GREATER, EQUAL, LESS_EQUAL, and GREATER_EQUAL, are independently tested to see if they are defined variables, if so their defined values are used otherwise the original value is used.
  • Both left and right hand arguments to STRLESS, STRGREATER, STREQUAL, STRLESS_EQUAL, and STRGREATER_EQUAL are independently tested to see if they are defined variables, if so their defined values are used otherwise the original value is used.
  • Both left and right hand arguments to VERSION_LESS, VERSION_GREATER, VERSION_EQUAL, VERSION_LESS_EQUAL, and VERSION_GREATER_EQUAL are independently tested to see if they are defined variables, if so their defined values are used otherwise the original value is used.
  • The right hand argument to NOT is tested to see if it is a boolean constant, if so the value is used, otherwise it is assumed to be a variable and it is dereferenced.
  • The left and right hand arguments to AND and OR are independently tested to see if they are boolean constants, if so they are used as such, otherwise they are assumed to be variables and are dereferenced.

To prevent ambiguity, potential variable or keyword names can be specified in a Quoted Argument or a Bracket Argument. A quoted or bracketed variable or keyword will be interpreted as a string and not dereferenced or interpreted. See policy CMP0054.

There is no automatic evaluation for environment or cache Variable References. Their values must be referenced as $ENV{<name>} or $CACHE{<name>} wherever the above-documented condition syntax accepts <variable|string>.

  • cmake-commands(7) »


include — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

include

Load and run CMake code from a file or module.

include(<file|module> [OPTIONAL] [RESULT_VARIABLE <var>]
                      [NO_POLICY_SCOPE])

Loads and runs CMake code from the file given. Variable reads and writes access the scope of the caller (dynamic scoping). If OPTIONAL is present, then no error is raised if the file does not exist. If RESULT_VARIABLE is given the variable <var> will be set to the full filename which has been included or NOTFOUND if it failed.

If a module is specified instead of a file, the file with name <modulename>.cmake is searched first in CMAKE_MODULE_PATH, then in the CMake module directory. There is one exception to this: if the file which calls include() is located itself in the CMake builtin module directory, then first the CMake builtin module directory is searched and CMAKE_MODULE_PATH afterwards. See also policy CMP0017.

See the cmake_policy() command documentation for discussion of the NO_POLICY_SCOPE option.

  • cmake-commands(7) »


include_guard — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

include_guard

Provides an include guard for the file currently being processed by CMake.

include_guard([DIRECTORY|GLOBAL])

Sets up an include guard for the current CMake file (see the CMAKE_CURRENT_LIST_FILE variable documentation).

CMake will end its processing of the current file at the location of the include_guard() command if the current file has already been processed for the applicable scope (see below). This provides functionality similar to the include guards commonly used in source headers or to the #pragma once directive. If the current file has been processed previously for the applicable scope, the effect is as though return() had been called. Do not call this command from inside a function being defined within the current file.

An optional argument specifying the scope of the guard may be provided. Possible values for the option are:

DIRECTORY
The include guard applies within the current directory and below. The file will only be included once within this directory scope, but may be included again by other files outside of this directory (i.e. a parent directory or another directory not pulled in by add_subdirectory() or include() from the current file or its children).
GLOBAL
The include guard applies globally to the whole build. The current file will only be included once regardless of the scope.

If no arguments given, include_guard has the same scope as a variable, meaning that the include guard effect is isolated by the most recent function scope or current directory if no inner function scopes exist. In this case the command behavior is the same as:

if(__CURRENT_FILE_VAR__)
  return()
endif()
set(__CURRENT_FILE_VAR__ TRUE)

  • cmake-commands(7) »


list — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

list

List operations.

Synopsis

Reading
  list(LENGTH <list> <out-var>)
  list(GET <list> <element index> [<index> ...] <out-var>)
  list(JOIN <list> <glue> <out-var>)
  list(SUBLIST <list> <begin> <length> <out-var>)

Search
  list(FIND <list> <value> <out-var>)

Modification
  list(APPEND <list> [<element>...])
  list(FILTER <list> {INCLUDE | EXCLUDE} REGEX <regex>)
  list(INSERT <list> <index> [<element>...])
  list(REMOVE_ITEM <list> <value>...)
  list(REMOVE_AT <list> <index>...)
  list(REMOVE_DUPLICATES <list>)
  list(TRANSFORM <list> <ACTION> [...])

Ordering
  list(REVERSE <list>)
  list(SORT <list> [...])

Introduction

The list subcommands APPEND, INSERT, FILTER, REMOVE_AT, REMOVE_ITEM, REMOVE_DUPLICATES, REVERSE and SORT may create new values for the list within the current CMake variable scope. Similar to the set() command, the LIST command creates new variable values in the current scope, even if the list itself is actually defined in a parent scope. To propagate the results of these operations upwards, use set() with PARENT_SCOPE, set() with CACHE INTERNAL, or some other means of value propagation.

Note

A list in cmake is a ; separated group of strings. To create a list the set command can be used. For example, set(var a b c d e) creates a list with a;b;c;d;e, and set(var "a b c d e") creates a string or a list with one item in it. (Note macro arguments are not variables, and therefore cannot be used in LIST commands.)

Note

When specifying index values, if <element index> is 0 or greater, it is indexed from the beginning of the list, with 0 representing the first list element. If <element index> is -1 or lesser, it is indexed from the end of the list, with -1 representing the last list element. Be careful when counting with negative indices: they do not start from 0. -0 is equivalent to 0, the first list element.

Reading

list(LENGTH <list> <output variable>)

Returns the list’s length.

list(GET <list> <element index> [<element index> ...] <output variable>)

Returns the list of elements specified by indices from the list.

list(JOIN <list> <glue> <output variable>)

Returns a string joining all list’s elements using the glue string. To join multiple strings, which are not part of a list, use JOIN operator from string() command.

list(SUBLIST <list> <begin> <length> <output variable>)

Returns a sublist of the given list. If <length> is 0, an empty list will be returned. If <length> is -1 or the list is smaller than <begin>+<length> then the remaining elements of the list starting at <begin> will be returned.

Search

list(FIND <list> <value> <output variable>)

Returns the index of the element specified in the list or -1 if it wasn’t found.

Modification

list(APPEND <list> [<element> ...])

Appends elements to the list.

list(FILTER <list> <INCLUDE|EXCLUDE> REGEX <regular_expression>)

Includes or removes items from the list that match the mode’s pattern. In REGEX mode, items will be matched against the given regular expression.

For more information on regular expressions see also the string() command.

list(INSERT <list> <element_index> <element> [<element> ...])

Inserts elements to the list to the specified location.

list(REMOVE_ITEM <list> <value> [<value> ...])

Removes the given items from the list.

list(REMOVE_AT <list> <index> [<index> ...])

Removes items at given indices from the list.

list(REMOVE_DUPLICATES <list>)

Removes duplicated items in the list.

list(TRANSFORM <list> <ACTION> [<SELECTOR>]
                      [OUTPUT_VARIABLE <output variable>])

Transforms the list by applying an action to all or, by specifying a <SELECTOR>, to the selected elements of the list, storing result in-place or in the specified output variable.

Note

TRANSFORM sub-command does not change the number of elements of the list. If a <SELECTOR> is specified, only some elements will be changed, the other ones will remain same as before the transformation.

<ACTION> specify the action to apply to the elements of list. The actions have exactly the same semantics as sub-commands of string() command.

The <ACTION> may be one of:

APPEND, PREPEND: Append, prepend specified value to each element of the list.

list(TRANSFORM <list> <APPEND|PREPEND> <value> ...)

TOUPPER, TOLOWER: Convert each element of the list to upper, lower characters.

list(TRANSFORM <list> <TOLOWER|TOUPPER> ...)

STRIP: Remove leading and trailing spaces from each element of the list.

list(TRANSFORM <list> STRIP ...)

GENEX_STRIP: Strip any generator expressions from each element of the list.

list(TRANSFORM <list> GENEX_STRIP ...)

REPLACE: Match the regular expression as many times as possible and substitute the replacement expression for the match for each element of the list (Same semantic as REGEX REPLACE from string() command).

list(TRANSFORM <list> REPLACE <regular_expression>
                              <replace_expression> ...)

<SELECTOR> select which elements of the list will be transformed. Only one type of selector can be specified at a time.

The <SELECTOR> may be one of:

AT: Specify a list of indexes.

list(TRANSFORM <list> <ACTION> AT <index> [<index> ...] ...)

FOR: Specify a range with, optionally, an increment used to iterate over the range.

list(TRANSFORM <list> <ACTION> FOR <start> <stop> [<step>] ...)

REGEX: Specify a regular expression. Only elements matching the regular expression will be transformed.

list(TRANSFORM <list> <ACTION> REGEX <regular_expression> ...)

Ordering

list(REVERSE <list>)

Reverses the contents of the list in-place.

list(SORT <list> [COMPARE <compare>] [CASE <case>] [ORDER <order>])

Sorts the list in-place alphabetically. Use the COMPARE keyword to select the comparison method for sorting. The <compare> option should be one of:

  • STRING: Sorts a list of strings alphabetically. This is the default behavior if the COMPARE option is not given.
  • FILE_BASENAME: Sorts a list of pathnames of files by their basenames.

Use the CASE keyword to select a case sensitive or case insensitive sort mode. The <case> option should be one of:

  • SENSITIVE: List items are sorted in a case-sensitive manner. This is the default behavior if the CASE option is not given.
  • INSENSITIVE: List items are sorted case insensitively. The order of items which differ only by upper/lowercase is not specified.

To control the sort order, the ORDER keyword can be given. The <order> option should be one of:

  • ASCENDING: Sorts the list in ascending order. This is the default behavior when the ORDER option is not given.
  • DESCENDING: Sorts the list in descending order.

  • cmake-commands(7) »


macro — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

macro

Start recording a macro for later invocation as a command

macro(<name> [<arg1> ...])
  <commands>
endmacro()

Defines a macro named <name> that takes arguments named <arg1>, … Commands listed after macro, but before the matching endmacro(), are not executed until the macro is invoked.

Per legacy, the endmacro() command admits an optional <name> argument. If used, it must be a verbatim repeat of the argument of the opening macro command.

See the cmake_policy() command documentation for the behavior of policies inside macros.

See the Macro vs Function section below for differences between CMake macros and functions.

Invocation

The macro invocation is case-insensitive. A macro defined as

macro(foo)
  <commands>
endmacro()

can be invoked through any of

foo()
Foo()
FOO()

and so on. However, it is strongly recommended to stay with the case chosen in the macro definition. Typically macros use all-lowercase names.

Arguments

When a macro is invoked, the commands recorded in the macro are first modified by replacing formal parameters (${arg1}, …) with the arguments passed, and then invoked as normal commands.

In addition to referencing the formal parameters you can reference the values ${ARGC} which will be set to the number of arguments passed into the function as well as ${ARGV0}, ${ARGV1}, ${ARGV2}, … which will have the actual values of the arguments passed in. This facilitates creating macros with optional arguments.

Furthermore, ${ARGV} holds the list of all arguments given to the macro and ${ARGN} holds the list of arguments past the last expected argument. Referencing to ${ARGV#} arguments beyond ${ARGC} have undefined behavior. Checking that ${ARGC} is greater than # is the only way to ensure that ${ARGV#} was passed to the function as an extra argument.

Macro vs Function

The macro command is very similar to the function() command. Nonetheless, there are a few important differences.

In a function, ARGN, ARGC, ARGV and ARGV0, ARGV1, … are true variables in the usual CMake sense. In a macro, they are not, they are string replacements much like the C preprocessor would do with a macro. This has a number of consequences, as explained in the Argument Caveats section below.

Another difference between macros and functions is the control flow. A function is executed by transferring control from the calling statement to the function body. A macro is executed as if the macro body were pasted in place of the calling statement. This has the consequence that a return() in a macro body does not just terminate execution of the macro; rather, control is returned from the scope of the macro call. To avoid confusion, it is recommended to avoid return() in macros altogether.

Argument Caveats

Since ARGN, ARGC, ARGV, ARGV0 etc. are not variables, you will NOT be able to use commands like

if(ARGV1) # ARGV1 is not a variable
if(DEFINED ARGV2) # ARGV2 is not a variable
if(ARGC GREATER 2) # ARGC is not a variable
foreach(loop_var IN LISTS ARGN) # ARGN is not a variable

In the first case, you can use if(${ARGV1}). In the second and third case, the proper way to check if an optional variable was passed to the macro is to use if(${ARGC} GREATER 2). In the last case, you can use foreach(loop_var ${ARGN}) but this will skip empty arguments. If you need to include them, you can use

set(list_var "${ARGN}")
foreach(loop_var IN LISTS list_var)

Note that if you have a variable with the same name in the scope from which the macro is called, using unreferenced names will use the existing variable instead of the arguments. For example:

macro(bar)
  foreach(arg IN LISTS ARGN)
    <commands>
  endforeach()
endmacro()

function(foo)
  bar(x y z)
endfunction()

foo(a b c)

Will loop over a;b;c and not over x;y;z as one might have expected. If you want true CMake variables and/or better CMake scope control you should look at the function command.

  • cmake-commands(7) »


mark_as_advanced — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

mark_as_advanced

Mark cmake cached variables as advanced.

mark_as_advanced([CLEAR|FORCE] <var1> ...)

Sets the advanced/non-advanced state of the named cached variables.

An advanced variable will not be displayed in any of the cmake GUIs unless the show advanced option is on. In script mode, the advanced/non-advanced state has no effect.

If the keyword CLEAR is given then advanced variables are changed back to unadvanced. If the keyword FORCE is given then the variables are made advanced. If neither FORCE nor CLEAR is specified, new values will be marked as advanced, but if a variable already has an advanced/non-advanced state, it will not be changed.

  • cmake-commands(7) »


math — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

math

Evaluate a mathematical expression.

math(EXPR <variable> "<expression>" [OUTPUT_FORMAT <format>])

Evaluates a mathematical <expression> and sets <variable> to the resulting value.

The mathematical expression must be given as a string (i.e. enclosed in double quotation marks). An example is "5 * (10 + 13)". Supported operators are +, -, *, /, %, |, &, ^, ~, <<, >>, and (...); they have the same meaning as in C code.

Hexadecimal numbers are recognized when prefixed with “0x”, as in C code.

The result is formatted according to the option OUTPUT_FORMAT, where <format> is one of

HEXADECIMAL
Hexadecimal notation as in C code, i. e. starting with “0x”.
DECIMAL
Decimal notation. Which is also used if no OUTPUT_FORMAT option is specified.

For example

math(EXPR value "100 * 0xA" OUTPUT_FORMAT DECIMAL)      # value is set to "1000"
math(EXPR value "100 * 0xA" OUTPUT_FORMAT HEXADECIMAL)  # value is set to "0x3e8"

  • cmake-commands(7) »


message — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

message

Display a message to the user.

message([<mode>] "message to display" ...)

The optional <mode> keyword determines the type of message:

(none)         = Important information
STATUS         = Incidental information
WARNING        = CMake Warning, continue processing
AUTHOR_WARNING = CMake Warning (dev), continue processing
SEND_ERROR     = CMake Error, continue processing,
                              but skip generation
FATAL_ERROR    = CMake Error, stop processing and generation
DEPRECATION    = CMake Deprecation Error or Warning if variable
                 CMAKE_ERROR_DEPRECATED or CMAKE_WARN_DEPRECATED
                 is enabled, respectively, else no message.

The CMake command-line tool displays STATUS messages on stdout and all other message types on stderr. The CMake GUI displays all messages in its log area. The interactive dialogs (ccmake and CMakeSetup) show STATUS messages one at a time on a status line and other messages in interactive pop-up boxes.

CMake Warning and Error message text displays using a simple markup language. Non-indented text is formatted in line-wrapped paragraphs delimited by newlines. Indented text is considered pre-formatted.

  • cmake-commands(7) »


option — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

option

Provide an option that the user can optionally select.

option(<variable> "<help_text>" [value])

Provides an option for the user to select as ON or OFF. If no initial <value> is provided, OFF is used. If <variable> is already set as a normal variable then the command does nothing (see policy CMP0077).

If you have options that depend on the values of other options, see the module help for CMakeDependentOption.

  • cmake-commands(7) »


return — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

return

Return from a file, directory or function.

return()

Returns from a file, directory or function. When this command is encountered in an included file (via include() or find_package()), it causes processing of the current file to stop and control is returned to the including file. If it is encountered in a file which is not included by another file, e.g. a CMakeLists.txt, control is returned to the parent directory if there is one. If return is called in a function, control is returned to the caller of the function.

Note that a macro, unlike a function, is expanded in place and therefore cannot handle return().

  • cmake-commands(7) »


separate_arguments — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

separate_arguments

Parse command-line arguments into a semicolon-separated list.

separate_arguments(<variable> <mode> <args>)

Parses a space-separated string <args> into a list of items, and stores this list in semicolon-separated standard form in <variable>.

This function is intended for parsing command-line arguments. The entire command line must be passed as one string in the argument <args>.

The exact parsing rules depend on the operating system. They are specified by the <mode> argument which must be one of the following keywords:

UNIX_COMMAND
Arguments are separated by by unquoted whitespace. Both single-quote and double-quote pairs are respected. A backslash escapes the next literal character (\" is "); there are no special escapes (\n is just n).
WINDOWS_COMMAND
A Windows command-line is parsed using the same syntax the runtime library uses to construct argv at startup. It separates arguments by whitespace that is not double-quoted. Backslashes are literal unless they precede double-quotes. See the MSDN article Parsing C Command-Line Arguments for details.
NATIVE_COMMAND
Proceeds as in WINDOWS_COMMAND mode if the host system is Windows. Otherwise proceeds as in UNIX_COMMAND mode.
separate_arguments(<var>)

Convert the value of <var> to a semi-colon separated list. All spaces are replaced with ‘;’. This helps with generating command lines.

  • cmake-commands(7) »


set — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

set

Set a normal, cache, or environment variable to a given value. See the cmake-language(7) variables documentation for the scopes and interaction of normal variables and cache entries.

Signatures of this command that specify a <value>... placeholder expect zero or more arguments. Multiple arguments will be joined as a semicolon-separated list to form the actual variable value to be set. Zero arguments will cause normal variables to be unset. See the unset() command to unset variables explicitly.

Set Normal Variable

set(<variable> <value>... [PARENT_SCOPE])

Sets the given <variable> in the current function or directory scope.

If the PARENT_SCOPE option is given the variable will be set in the scope above the current scope. Each new directory or function creates a new scope. This command will set the value of a variable into the parent directory or calling function (whichever is applicable to the case at hand). The previous state of the variable’s value stays the same in the current scope (e.g., if it was undefined before, it is still undefined and if it had a value, it is still that value).

Set Cache Entry

set(<variable> <value>... CACHE <type> <docstring> [FORCE])

Sets the given cache <variable> (cache entry). Since cache entries are meant to provide user-settable values this does not overwrite existing cache entries by default. Use the FORCE option to overwrite existing entries.

The <type> must be specified as one of:

BOOL
Boolean ON/OFF value. cmake-gui(1) offers a checkbox.
FILEPATH
Path to a file on disk. cmake-gui(1) offers a file dialog.
PATH
Path to a directory on disk. cmake-gui(1) offers a file dialog.
STRING
A line of text. cmake-gui(1) offers a text field or a drop-down selection if the STRINGS cache entry property is set.
INTERNAL
A line of text. cmake-gui(1) does not show internal entries. They may be used to store variables persistently across runs. Use of this type implies FORCE.

The <docstring> must be specified as a line of text providing a quick summary of the option for presentation to cmake-gui(1) users.

If the cache entry does not exist prior to the call or the FORCE option is given then the cache entry will be set to the given value. Furthermore, any normal variable binding in the current scope will be removed to expose the newly cached value to any immediately following evaluation.

It is possible for the cache entry to exist prior to the call but have no type set if it was created on the cmake(1) command line by a user through the -D<var>=<value> option without specifying a type. In this case the set command will add the type. Furthermore, if the <type> is PATH or FILEPATH and the <value> provided on the command line is a relative path, then the set command will treat the path as relative to the current working directory and convert it to an absolute path.

Set Environment Variable

set(ENV{<variable>} [<value>])

Sets an Environment Variable to the given value. Subsequent calls of $ENV{<variable>} will return this new value.

This command affects only the current CMake process, not the process from which CMake was called, nor the system environment at large, nor the environment of subsequent build or test processes.

If no argument is given after ENV{<variable>} or if <value> is an empty string, then this command will clear any existing value of the environment variable.

Arguments after <value> are ignored. If extra arguments are found, then an author warning is issued.

  • cmake-commands(7) »


set_directory_properties — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

set_directory_properties

Set properties of the current directory and subdirectories.

set_directory_properties(PROPERTIES prop1 value1 [prop2 value2] ...)

Sets properties of the current directory and its subdirectories in key-value pairs.

See also the set_property(DIRECTORY) command.

See Properties on Directories for the list of properties known to CMake and their individual documentation for the behavior of each property.

  • cmake-commands(7) »


set_property — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

set_property

Set a named property in a given scope.

set_property(<GLOBAL                      |
              DIRECTORY [<dir>]           |
              TARGET    [<target1> ...]   |
              SOURCE    [<src1> ...]      |
              INSTALL   [<file1> ...]     |
              TEST      [<test1> ...]     |
              CACHE     [<entry1> ...]    >
             [APPEND] [APPEND_STRING]
             PROPERTY <name> [value1 ...])

Sets one property on zero or more objects of a scope.

The first argument determines the scope in which the property is set. It must be one of the following:

GLOBAL
Scope is unique and does not accept a name.
DIRECTORY
Scope defaults to the current directory but another directory (already processed by CMake) may be named by full or relative path. See also the set_directory_properties() command.
TARGET
Scope may name zero or more existing targets. See also the set_target_properties() command.
SOURCE
Scope may name zero or more source files. Note that source file properties are visible only to targets added in the same directory (CMakeLists.txt). See also the set_source_files_properties() command.
INSTALL

Scope may name zero or more installed file paths. These are made available to CPack to influence deployment.

Both the property key and value may use generator expressions. Specific properties may apply to installed files and/or directories.

Path components have to be separated by forward slashes, must be normalized and are case sensitive.

To reference the installation prefix itself with a relative path use “.”.

Currently installed file properties are only defined for the WIX generator where the given paths are relative to the installation prefix.

TEST
Scope may name zero or more existing tests. See also the set_tests_properties() command.
CACHE
Scope must name zero or more cache existing entries.

The required PROPERTY option is immediately followed by the name of the property to set. Remaining arguments are used to compose the property value in the form of a semicolon-separated list.

If the APPEND option is given the list is appended to any existing property value. If the APPEND_STRING option is given the string is appended to any existing property value as string, i.e. it results in a longer string and not a list of strings. When using APPEND or APPEND_STRING with a property defined to support INHERITED behavior (see define_property()), no inheriting occurs when finding the initial value to append to. If the property is not already directly set in the nominated scope, the command will behave as though APPEND or APPEND_STRING had not been given.

See the cmake-properties(7) manual for a list of properties in each scope.

  • cmake-commands(7) »


site_name — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

site_name

Set the given variable to the name of the computer.

site_name(variable)

  • cmake-commands(7) »


string — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

string

String operations.

Synopsis

Search and Replace
  string(FIND <string> <substring> <out-var> [...])
  string(REPLACE <match-string> <replace-string> <out-var> <input>...)

Regular Expressions
  string(REGEX MATCH <match-regex> <out-var> <input>...)
  string(REGEX MATCHALL <match-regex> <out-var> <input>...)
  string(REGEX REPLACE <match-regex> <replace-expr> <out-var> <input>...)

Manipulation
  string(APPEND <string-var> [<input>...])
  string(PREPEND <string-var> [<input>...])
  string(CONCAT <out-var> [<input>...])
  string(JOIN <glue> <out-var> [<input>...])
  string(TOLOWER <string1> <out-var>)
  string(TOUPPER <string1> <out-var>)
  string(LENGTH <string> <out-var>)
  string(SUBSTRING <string> <begin> <length> <out-var>)
  string(STRIP <string> <out-var>)
  string(GENEX_STRIP <string> <out-var>)

Comparison
  string(COMPARE <op> <string1> <string2> <out-var>)

Hashing
  string(<HASH> <out-var> <input>)

Generation
  string(ASCII <number>... <out-var>)
  string(CONFIGURE <string1> <out-var> [...])
  string(MAKE_C_IDENTIFIER <string> <out-var>)
  string(RANDOM [<option>...] <out-var>)
  string(TIMESTAMP <out-var> [<format string>] [UTC])
  string(UUID <out-var> ...)

Search and Replace

string(FIND <string> <substring> <output variable> [REVERSE])

Return the position where the given substring was found in the supplied string. If the REVERSE flag was used, the command will search for the position of the last occurrence of the specified substring. If the substring is not found, a position of -1 is returned.

string(REPLACE <match_string>
       <replace_string> <output variable>
       <input> [<input>...])

Replace all occurrences of match_string in the input with replace_string and store the result in the output.

Regular Expressions

string(REGEX MATCH <regular_expression>
       <output variable> <input> [<input>...])

Match the regular expression once and store the match in the output variable. All <input> arguments are concatenated before matching.

string(REGEX MATCHALL <regular_expression>
       <output variable> <input> [<input>...])

Match the regular expression as many times as possible and store the matches in the output variable as a list. All <input> arguments are concatenated before matching.

string(REGEX REPLACE <regular_expression>
       <replace_expression> <output variable>
       <input> [<input>...])

Match the regular expression as many times as possible and substitute the replacement expression for the match in the output. All <input> arguments are concatenated before matching.

The replace expression may refer to paren-delimited subexpressions of the match using \1, \2, …, \9. Note that two backslashes (\\1) are required in CMake code to get a backslash through argument parsing.

Regex Specification

The following characters have special meaning in regular expressions:

^
Matches at beginning of input
$
Matches at end of input
.
Matches any single character
\<char>
Matches the single character specified by <char>. Use this to match special regex characters, e.g. \. for a literal . or \\ for a literal backslash \. Escaping a non-special character is unnecessary but allowed, e.g. \a matches a.
[ ]
Matches any character(s) inside the brackets
[^ ]
Matches any character(s) not inside the brackets
-
Inside brackets, specifies an inclusive range between characters on either side e.g. [a-f] is [abcdef] To match a literal - using brackets, make it the first or the last character e.g. [+*/-] matches basic mathematical operators.
*
Matches preceding pattern zero or more times
+
Matches preceding pattern one or more times
?
Matches preceding pattern zero or once only
|
Matches a pattern on either side of the |
()
Saves a matched subexpression, which can be referenced in the REGEX REPLACE operation. Additionally it is saved by all regular expression-related commands, including e.g. if(MATCHES), in the variables CMAKE_MATCH_<n> for <n> 0..9.

*, + and ? have higher precedence than concatenation. | has lower precedence than concatenation. This means that the regular expression ^ab+d$ matches abbd but not ababd, and the regular expression ^(ab|cd)$ matches ab but not abd.

CMake language Escape Sequences such as \t, \r, \n, and \\ may be used to construct literal tabs, carriage returns, newlines, and backslashes (respectively) to pass in a regex. For example:

  • The quoted argument "[ \t\r\n]" specifies a regex that matches any single whitespace character.
  • The quoted argument "[/\\]" specifies a regex that matches a single forward slash / or backslash \.
  • The quoted argument "[A-Za-z0-9_]" specifies a regex that matches any single “word” character in the C locale.
  • The quoted argument "\\(\\a\\+b\\)" specifies a regex that matches the exact string (a+b). Each \\ is parsed in a quoted argument as just \, so the regex itself is actually \(\a\+\b\). This can alternatively be specified in a Bracket Argument without having to escape the backslashes, e.g. [[\(\a\+\b\)]].

Manipulation

string(APPEND <string variable> [<input>...])

Append all the input arguments to the string.

string(PREPEND <string variable> [<input>...])

Prepend all the input arguments to the string.

string(CONCAT <output variable> [<input>...])

Concatenate all the input arguments together and store the result in the named output variable.

string(JOIN <glue> <output variable> [<input>...])

Join all the input arguments together using the glue string and store the result in the named output variable.

To join list’s elements, use preferably the JOIN operator from list() command. This allows for the elements to have special characters like ; in them.

string(TOLOWER <string1> <output variable>)

Convert string to lower characters.

string(TOUPPER <string1> <output variable>)

Convert string to upper characters.

string(LENGTH <string> <output variable>)

Store in an output variable a given string’s length.

string(SUBSTRING <string> <begin> <length> <output variable>)

Store in an output variable a substring of a given string. If length is -1 the remainder of the string starting at begin will be returned. If string is shorter than length then end of string is used instead.

Note

CMake 3.1 and below reported an error if length pointed past the end of string.

string(STRIP <string> <output variable>)

Store in an output variable a substring of a given string with leading and trailing spaces removed.

string(GENEX_STRIP <input string> <output variable>)

Strip any generator expressions from the input string and store the result in the output variable.

Comparison

string(COMPARE LESS <string1> <string2> <output variable>)
string(COMPARE GREATER <string1> <string2> <output variable>)
string(COMPARE EQUAL <string1> <string2> <output variable>)
string(COMPARE NOTEQUAL <string1> <string2> <output variable>)
string(COMPARE LESS_EQUAL <string1> <string2> <output variable>)
string(COMPARE GREATER_EQUAL <string1> <string2> <output variable>)

Compare the strings and store true or false in the output variable.

Hashing

string(<HASH> <output variable> <input>)

Compute a cryptographic hash of the input string. The supported <HASH> algorithm names are:

MD5
Message-Digest Algorithm 5, RFC 1321.
SHA1
US Secure Hash Algorithm 1, RFC 3174.
SHA224
US Secure Hash Algorithms, RFC 4634.
SHA256
US Secure Hash Algorithms, RFC 4634.
SHA384
US Secure Hash Algorithms, RFC 4634.
SHA512
US Secure Hash Algorithms, RFC 4634.
SHA3_224
Keccak SHA-3.
SHA3_256
Keccak SHA-3.
SHA3_384
Keccak SHA-3.
SHA3_512
Keccak SHA-3.

Generation

string(ASCII <number> [<number> ...] <output variable>)

Convert all numbers into corresponding ASCII characters.

string(CONFIGURE <string1> <output variable>
       [@ONLY] [ESCAPE_QUOTES])

Transform a string like configure_file() transforms a file.

string(MAKE_C_IDENTIFIER <input string> <output variable>)

Convert each non-alphanumeric character in the <input string> to an underscore and store the result in the <output variable>. If the first character of the string is a digit, an underscore will also be prepended to the result.

string(RANDOM [LENGTH <length>] [ALPHABET <alphabet>]
       [RANDOM_SEED <seed>] <output variable>)

Return a random string of given length consisting of characters from the given alphabet. Default length is 5 characters and default alphabet is all numbers and upper and lower case letters. If an integer RANDOM_SEED is given, its value will be used to seed the random number generator.

string(TIMESTAMP <output variable> [<format string>] [UTC])

Write a string representation of the current date and/or time to the output variable.

Should the command be unable to obtain a timestamp the output variable will be set to the empty string “”.

The optional UTC flag requests the current date/time representation to be in Coordinated Universal Time (UTC) rather than local time.

The optional <format string> may contain the following format specifiers:

%%        A literal percent sign (%).
%d        The day of the current month (01-31).
%H        The hour on a 24-hour clock (00-23).
%I        The hour on a 12-hour clock (01-12).
%j        The day of the current year (001-366).
%m        The month of the current year (01-12).
%b        Abbreviated month name (e.g. Oct).
%B        Full month name (e.g. October).
%M        The minute of the current hour (00-59).
%s        Seconds since midnight (UTC) 1-Jan-1970 (UNIX time).
%S        The second of the current minute.
          60 represents a leap second. (00-60)
%U        The week number of the current year (00-53).
%w        The day of the current week. 0 is Sunday. (0-6)
%a        Abbreviated weekday name (e.g. Fri).
%A        Full weekday name (e.g. Friday).
%y        The last two digits of the current year (00-99)
%Y        The current year.

Unknown format specifiers will be ignored and copied to the output as-is.

If no explicit <format string> is given it will default to:

%Y-%m-%dT%H:%M:%S    for local time.
%Y-%m-%dT%H:%M:%SZ   for UTC.

Note

If the SOURCE_DATE_EPOCH environment variable is set, its value will be used instead of the current time. See https://reproducible-builds.org/specs/source-date-epoch/ for details.

string(UUID <output variable> NAMESPACE <namespace> NAME <name>
       TYPE <MD5|SHA1> [UPPER])

Create a universally unique identifier (aka GUID) as per RFC4122 based on the hash of the combined values of <namespace> (which itself has to be a valid UUID) and <name>. The hash algorithm can be either MD5 (Version 3 UUID) or SHA1 (Version 5 UUID). A UUID has the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx where each x represents a lower case hexadecimal character. Where required an uppercase representation can be requested with the optional UPPER flag.

  • cmake-commands(7) »


unset — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

unset

Unset a variable, cache variable, or environment variable.

Unset Normal Variable or Cache Entry

unset(<variable> [CACHE | PARENT_SCOPE])

Removes a normal variable from the current scope, causing it to become undefined. If CACHE is present, then a cache variable is removed instead of a normal variable. Note that when evaluating Variable References of the form ${VAR}, CMake first searches for a normal variable with that name. If no such normal variable exists, CMake will then search for a cache entry with that name. Because of this unsetting a normal variable can expose a cache variable that was previously hidden. To force a variable reference of the form ${VAR} to return an empty string, use set(<variable> ""), which clears the normal variable but leaves it defined.

If PARENT_SCOPE is present then the variable is removed from the scope above the current scope. See the same option in the set() command for further details.

Unset Environment Variable

unset(ENV{<variable>})

Removes <variable> from the currently available Environment Variables. Subsequent calls of $ENV{<variable>} will return the empty string.

This command affects only the current CMake process, not the process from which CMake was called, nor the system environment at large, nor the environment of subsequent build or test processes.

  • cmake-commands(7) »


variable_watch — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

variable_watch

Watch the CMake variable for change.

variable_watch(<variable> [<command>])

If the specified <variable> changes, a message will be printed to inform about the change.

Additionally, if <command> is given, this command will be executed. The command will receive the following arguments: COMMAND(<variable> <access> <value> <current_list_file> <stack>)

  • cmake-commands(7) »


while — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

while

Evaluate a group of commands while a condition is true

while(<condition>)
  <commands>
endwhile()

All commands between while and the matching endwhile() are recorded without being invoked. Once the endwhile() is evaluated, the recorded list of commands is invoked as long as the <condition> is true.

The <condition> has the same syntax and is evaluated using the same logic as described at length for the if() command.

The commands break() and continue() provide means to escape from the normal control flow.

Per legacy, the endwhile() command admits an optional <condition> argument. If used, it must be a verbatim repeat of the argument of the opening while command.

  • cmake-commands(7) »


add_compile_definitions — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_compile_definitions

Add preprocessor definitions to the compilation of source files.

add_compile_definitions(<definition> ...)

Adds preprocessor definitions to the compiler command line for targets in the current directory and below (whether added before or after this command is invoked). See documentation of the directory and target COMPILE_DEFINITIONS properties.

Definitions are specified using the syntax VAR or VAR=value. Function-style definitions are not supported. CMake will automatically escape the value correctly for the native build system (note that CMake language syntax may require escapes to specify some values).

Arguments to add_compile_definitions may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-commands(7) »


add_compile_options — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_compile_options

Add options to the compilation of source files.

add_compile_options(<option> ...)

Adds options to the COMPILE_OPTIONS directory property. These options are used when compiling targets from the current directory and below.

Arguments

Arguments to add_compile_options may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

The final set of compile or link options used for a target is constructed by accumulating options from the current target and the usage requirements of it dependencies. The set of options is de-duplicated to avoid repetition. While beneficial for individual options, the de-duplication step can break up option groups. For example, -D A -D B becomes -D A B. One may specify a group of options using shell-like quoting along with a SHELL: prefix. The SHELL: prefix is dropped and the rest of the option string is parsed using the separate_arguments() UNIX_COMMAND mode. For example, "SHELL:-D A" "SHELL:-D B" becomes -D A -D B.

Example

Since different compilers support different options, a typical use of this command is in a compiler-specific conditional clause:

if (MSVC)
    # warning level 4 and all warnings as errors
    add_compile_options(/W4 /WX)
else()
    # lots of warnings and all warnings as errors
    add_compile_options(-Wall -Wextra -pedantic -Werror)
endif()

See Also

This command can be used to add any options. However, for adding preprocessor definitions and include directories it is recommended to use the more specific commands add_compile_definitions() and include_directories().

The command target_compile_options() adds target-specific options.

  • cmake-commands(7) »


add_custom_command — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_custom_command

Add a custom build rule to the generated build system.

There are two main signatures for add_custom_command.

Generating Files

The first signature is for adding a custom command to produce an output:

add_custom_command(OUTPUT output1 [output2 ...]
                   COMMAND command1 [ARGS] [args1...]
                   [COMMAND command2 [ARGS] [args2...] ...]
                   [MAIN_DEPENDENCY depend]
                   [DEPENDS [depends...]]
                   [BYPRODUCTS [files...]]
                   [IMPLICIT_DEPENDS <lang1> depend1
                                    [<lang2> depend2] ...]
                   [WORKING_DIRECTORY dir]
                   [COMMENT comment]
                   [DEPFILE depfile]
                   [VERBATIM] [APPEND] [USES_TERMINAL]
                   [COMMAND_EXPAND_LISTS])

This defines a command to generate specified OUTPUT file(s). A target created in the same directory (CMakeLists.txt file) that specifies any output of the custom command as a source file is given a rule to generate the file using the command at build time. Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict (instead use the add_custom_target() command to drive the command and make the other targets depend on that one). In makefile terms this creates a new target in the following form:

OUTPUT: MAIN_DEPENDENCY DEPENDS
        COMMAND

The options are:

APPEND
Append the COMMAND and DEPENDS option values to the custom command for the first output specified. There must have already been a previous call to this command with the same output. The COMMENT, MAIN_DEPENDENCY, and WORKING_DIRECTORY options are currently ignored when APPEND is given, but may be used in the future.
BYPRODUCTS

Specify the files the command is expected to produce but whose modification time may or may not be newer than the dependencies. If a byproduct name is a relative path it will be interpreted relative to the build tree directory corresponding to the current source directory. Each byproduct file will be marked with the GENERATED source file property automatically.

Explicit specification of byproducts is supported by the Ninja generator to tell the ninja build tool how to regenerate byproducts when they are missing. It is also useful when other build rules (e.g. custom commands) depend on the byproducts. Ninja requires a build rule for any generated file on which another rule depends even if there are order-only dependencies to ensure the byproducts will be available before their dependents build.

The BYPRODUCTS option is ignored on non-Ninja generators except to mark byproducts GENERATED.

COMMAND

Specify the command-line(s) to execute at build time. If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script. (To run a full script, use the configure_file() command or the file(GENERATE) command to create it, and then specify a COMMAND to launch it.) The optional ARGS argument is for backward compatibility and will be ignored.

If COMMAND specifies an executable target name (created by the add_executable() command) it will automatically be replaced by the location of the executable created at build time. If set, the CROSSCOMPILING_EMULATOR executable target property will also be prepended to the command to allow the executable to run on the host. (Use the TARGET_FILE generator expression to reference an executable later in the command line.) Additionally a target-level dependency will be added so that the executable target will be built before any target using this custom command. However this does NOT add a file-level dependency that would cause the custom command to re-run whenever the executable is recompiled.

Arguments to COMMAND may use generator expressions. References to target names in generator expressions imply target-level dependencies, but NOT file-level dependencies. List target names with the DEPENDS option to add file-level dependencies.

COMMENT
Display the given message before the commands are executed at build time.
DEPENDS

Specify files on which the command depends. If any dependency is an OUTPUT of another custom command in the same directory (CMakeLists.txt file) CMake automatically brings the other custom command into the target in which this command is built. If DEPENDS is not specified the command will run whenever the OUTPUT is missing; if the command does not actually create the OUTPUT then the rule will always run. If DEPENDS specifies any target (created by the add_custom_target(), add_executable(), or add_library() command) a target-level dependency is created to make sure the target is built before any target using this custom command. Additionally, if the target is an executable or library a file-level dependency is created to cause the custom command to re-run whenever the target is recompiled.

Arguments to DEPENDS may use generator expressions.

COMMAND_EXPAND_LISTS
Lists in COMMAND arguments will be expanded, including those created with generator expressions, allowing COMMAND arguments such as ${CC} "-I$<JOIN:$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>,;-I>" foo.cc to be properly expanded.
IMPLICIT_DEPENDS
Request scanning of implicit dependencies of an input file. The language given specifies the programming language whose corresponding dependency scanner should be used. Currently only C and CXX language scanners are supported. The language has to be specified for every file in the IMPLICIT_DEPENDS list. Dependencies discovered from the scanning are added to those of the custom command at build time. Note that the IMPLICIT_DEPENDS option is currently supported only for Makefile generators and will be ignored by other generators.
MAIN_DEPENDENCY
Specify the primary input source file to the command. This is treated just like any value given to the DEPENDS option but also suggests to Visual Studio generators where to hang the custom command. Each source file may have at most one command specifying it as its main dependency. A compile command (i.e. for a library or an executable) counts as an implicit main dependency which gets silently overwritten by a custom command specification.
OUTPUT
Specify the output files the command is expected to produce. If an output name is a relative path it will be interpreted relative to the build tree directory corresponding to the current source directory. Each output file will be marked with the GENERATED source file property automatically. If the output of the custom command is not actually created as a file on disk it should be marked with the SYMBOLIC source file property.
USES_TERMINAL
The command will be given direct access to the terminal if possible. With the Ninja generator, this places the command in the console pool.
VERBATIM
All arguments to the commands will be escaped properly for the build tool so that the invoked command receives each argument unchanged. Note that one level of escapes is still used by the CMake language processor before add_custom_command even sees the arguments. Use of VERBATIM is recommended as it enables correct behavior. When VERBATIM is not given the behavior is platform specific because there is no protection of tool-specific special characters.
WORKING_DIRECTORY

Execute the command with the given current working directory. If it is a relative path it will be interpreted relative to the build tree directory corresponding to the current source directory.

Arguments to WORKING_DIRECTORY may use generator expressions.

DEPFILE
Specify a .d depfile for the Ninja generator. A .d file holds dependencies usually emitted by the custom command itself. Using DEPFILE with other generators than Ninja is an error.

Build Events

The second signature adds a custom command to a target such as a library or executable. This is useful for performing an operation before or after building the target. The command becomes part of the target and will only execute when the target itself is built. If the target is already built, the command will not execute.

add_custom_command(TARGET <target>
                   PRE_BUILD | PRE_LINK | POST_BUILD
                   COMMAND command1 [ARGS] [args1...]
                   [COMMAND command2 [ARGS] [args2...] ...]
                   [BYPRODUCTS [files...]]
                   [WORKING_DIRECTORY dir]
                   [COMMENT comment]
                   [VERBATIM] [USES_TERMINAL])

This defines a new command that will be associated with building the specified <target>. The <target> must be defined in the current directory; targets defined in other directories may not be specified.

When the command will happen is determined by which of the following is specified:

PRE_BUILD
On Visual Studio Generators, run before any other rules are executed within the target. On other generators, run just before PRE_LINK commands.
PRE_LINK
Run after sources have been compiled but before linking the binary or running the librarian or archiver tool of a static library. This is not defined for targets created by the add_custom_target() command.
POST_BUILD
Run after all other rules within the target have been executed.

Note

Because generator expressions can be used in custom commands, it is possible to define COMMAND lines or whole custom commands which evaluate to empty strings for certain configurations. For Visual Studio 2010 (and newer) generators these command lines or custom commands will be omitted for the specific configuration and no “empty-string-command” will be added.

This allows to add individual build events for every configuration.

  • cmake-commands(7) »


add_custom_target — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_custom_target

Add a target with no output so it will always be built.

add_custom_target(Name [ALL] [command1 [args1...]]
                  [COMMAND command2 [args2...] ...]
                  [DEPENDS depend depend depend ... ]
                  [BYPRODUCTS [files...]]
                  [WORKING_DIRECTORY dir]
                  [COMMENT comment]
                  [VERBATIM] [USES_TERMINAL]
                  [COMMAND_EXPAND_LISTS]
                  [SOURCES src1 [src2...]])

Adds a target with the given name that executes the given commands. The target has no output file and is always considered out of date even if the commands try to create a file with the name of the target. Use the add_custom_command() command to generate a file with dependencies. By default nothing depends on the custom target. Use the add_dependencies() command to add dependencies to or from other targets.

The options are:

ALL
Indicate that this target should be added to the default build target so that it will be run every time (the command cannot be called ALL).
BYPRODUCTS

Specify the files the command is expected to produce but whose modification time may or may not be updated on subsequent builds. If a byproduct name is a relative path it will be interpreted relative to the build tree directory corresponding to the current source directory. Each byproduct file will be marked with the GENERATED source file property automatically.

Explicit specification of byproducts is supported by the Ninja generator to tell the ninja build tool how to regenerate byproducts when they are missing. It is also useful when other build rules (e.g. custom commands) depend on the byproducts. Ninja requires a build rule for any generated file on which another rule depends even if there are order-only dependencies to ensure the byproducts will be available before their dependents build.

The BYPRODUCTS option is ignored on non-Ninja generators except to mark byproducts GENERATED.

COMMAND

Specify the command-line(s) to execute at build time. If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script. (To run a full script, use the configure_file() command or the file(GENERATE) command to create it, and then specify a COMMAND to launch it.)

If COMMAND specifies an executable target name (created by the add_executable() command) it will automatically be replaced by the location of the executable created at build time. If set, the CROSSCOMPILING_EMULATOR executable target property will also be prepended to the command to allow the executable to run on the host. Additionally a target-level dependency will be added so that the executable target will be built before this custom target.

Arguments to COMMAND may use generator expressions. References to target names in generator expressions imply target-level dependencies.

The command and arguments are optional and if not specified an empty target will be created.

COMMENT
Display the given message before the commands are executed at build time.
DEPENDS

Reference files and outputs of custom commands created with add_custom_command() command calls in the same directory (CMakeLists.txt file). They will be brought up to date when the target is built.

Use the add_dependencies() command to add dependencies on other targets.

COMMAND_EXPAND_LISTS
Lists in COMMAND arguments will be expanded, including those created with generator expressions, allowing COMMAND arguments such as ${CC} "-I$<JOIN:$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>,;-I>" foo.cc to be properly expanded.
SOURCES
Specify additional source files to be included in the custom target. Specified source files will be added to IDE project files for convenience in editing even if they have no build rules.
VERBATIM
All arguments to the commands will be escaped properly for the build tool so that the invoked command receives each argument unchanged. Note that one level of escapes is still used by the CMake language processor before add_custom_target even sees the arguments. Use of VERBATIM is recommended as it enables correct behavior. When VERBATIM is not given the behavior is platform specific because there is no protection of tool-specific special characters.
USES_TERMINAL
The command will be given direct access to the terminal if possible. With the Ninja generator, this places the command in the console pool.
WORKING_DIRECTORY

Execute the command with the given current working directory. If it is a relative path it will be interpreted relative to the build tree directory corresponding to the current source directory.

Arguments to WORKING_DIRECTORY may use generator expressions.

  • cmake-commands(7) »


add_definitions — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_definitions

Add -D define flags to the compilation of source files.

add_definitions(-DFOO -DBAR ...)

Adds definitions to the compiler command line for targets in the current directory and below (whether added before or after this command is invoked). This command can be used to add any flags, but it is intended to add preprocessor definitions.

Note

This command has been superseded by alternatives:

  • Use add_compile_definitions() to add preprocessor definitions.
  • Use include_directories() to add include directories.
  • Use add_compile_options() to add other options.

Flags beginning in -D or /D that look like preprocessor definitions are automatically added to the COMPILE_DEFINITIONS directory property for the current directory. Definitions with non-trivial values may be left in the set of flags instead of being converted for reasons of backwards compatibility. See documentation of the directory, target, source file COMPILE_DEFINITIONS properties for details on adding preprocessor definitions to specific scopes and configurations.

See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-commands(7) »


add_dependencies — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_dependencies

Add a dependency between top-level targets.

add_dependencies(<target> [<target-dependency>]...)

Makes a top-level <target> depend on other top-level targets to ensure that they build before <target> does. A top-level target is one created by one of the add_executable(), add_library(), or add_custom_target() commands (but not targets generated by CMake like install).

Dependencies added to an imported target or an interface library are followed transitively in its place since the target itself does not build.

See the DEPENDS option of add_custom_target() and add_custom_command() commands for adding file-level dependencies in custom rules. See the OBJECT_DEPENDS source file property to add file-level dependencies to object files.

  • cmake-commands(7) »


add_executable — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_executable

Add an executable to the project using the specified source files.

add_executable(<name> [WIN32] [MACOSX_BUNDLE]
               [EXCLUDE_FROM_ALL]
               [source1] [source2 ...])

Adds an executable target called <name> to be built from the source files listed in the command invocation. (The source files can be omitted here if they are added later using target_sources().) The <name> corresponds to the logical target name and must be globally unique within a project. The actual file name of the executable built is constructed based on conventions of the native platform (such as <name>.exe or just <name>).

By default the executable file will be created in the build tree directory corresponding to the source tree directory in which the command was invoked. See documentation of the RUNTIME_OUTPUT_DIRECTORY target property to change this location. See documentation of the OUTPUT_NAME target property to change the <name> part of the final file name.

If WIN32 is given the property WIN32_EXECUTABLE will be set on the target created. See documentation of that target property for details.

If MACOSX_BUNDLE is given the corresponding property will be set on the created target. See documentation of the MACOSX_BUNDLE target property for details.

If EXCLUDE_FROM_ALL is given the corresponding property will be set on the created target. See documentation of the EXCLUDE_FROM_ALL target property for details.

Source arguments to add_executable may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

See also HEADER_FILE_ONLY on what to do if some sources are pre-processed, and you want to have the original sources reachable from within IDE.

add_executable(<name> IMPORTED [GLOBAL])

An IMPORTED executable target references an executable file located outside the project. No rules are generated to build it, and the IMPORTED target property is True. The target name has scope in the directory in which it is created and below, but the GLOBAL option extends visibility. It may be referenced like any target built within the project. IMPORTED executables are useful for convenient reference from commands like add_custom_command(). Details about the imported executable are specified by setting properties whose names begin in IMPORTED_. The most important such property is IMPORTED_LOCATION (and its per-configuration version IMPORTED_LOCATION_<CONFIG>) which specifies the location of the main executable file on disk. See documentation of the IMPORTED_* properties for more information.

add_executable(<name> ALIAS <target>)

Creates an Alias Target, such that <name> can be used to refer to <target> in subsequent commands. The <name> does not appear in the generated buildsystem as a make target. The <target> may not be a non-GLOBAL Imported Target or an ALIAS. ALIAS targets can be used as targets to read properties from, executables for custom commands and custom targets. They can also be tested for existence with the regular if(TARGET) subcommand. The <name> may not be used to modify properties of <target>, that is, it may not be used as the operand of set_property(), set_target_properties(), target_link_libraries() etc. An ALIAS target may not be installed or exported.

  • cmake-commands(7) »


add_library — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_library

Contents

  • add_library
    • Normal Libraries
    • Imported Libraries
    • Object Libraries
    • Alias Libraries
    • Interface Libraries

Add a library to the project using the specified source files.

Normal Libraries

add_library(<name> [STATIC | SHARED | MODULE]
            [EXCLUDE_FROM_ALL]
            [source1] [source2 ...])

Adds a library target called <name> to be built from the source files listed in the command invocation. (The source files can be omitted here if they are added later using target_sources().) The <name> corresponds to the logical target name and must be globally unique within a project. The actual file name of the library built is constructed based on conventions of the native platform (such as lib<name>.a or <name>.lib).

STATIC, SHARED, or MODULE may be given to specify the type of library to be created. STATIC libraries are archives of object files for use when linking other targets. SHARED libraries are linked dynamically and loaded at runtime. MODULE libraries are plugins that are not linked into other targets but may be loaded dynamically at runtime using dlopen-like functionality. If no type is given explicitly the type is STATIC or SHARED based on whether the current value of the variable BUILD_SHARED_LIBS is ON. For SHARED and MODULE libraries the POSITION_INDEPENDENT_CODE target property is set to ON automatically. A SHARED or STATIC library may be marked with the FRAMEWORK target property to create an macOS Framework.

If a library does not export any symbols, it must not be declared as a SHARED library. For example, a Windows resource DLL or a managed C++/CLI DLL that exports no unmanaged symbols would need to be a MODULE library. This is because CMake expects a SHARED library to always have an associated import library on Windows.

By default the library file will be created in the build tree directory corresponding to the source tree directory in which the command was invoked. See documentation of the ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and RUNTIME_OUTPUT_DIRECTORY target properties to change this location. See documentation of the OUTPUT_NAME target property to change the <name> part of the final file name.

If EXCLUDE_FROM_ALL is given the corresponding property will be set on the created target. See documentation of the EXCLUDE_FROM_ALL target property for details.

Source arguments to add_library may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

See also HEADER_FILE_ONLY on what to do if some sources are pre-processed, and you want to have the original sources reachable from within IDE.

Imported Libraries

add_library(<name> <SHARED|STATIC|MODULE|OBJECT|UNKNOWN> IMPORTED
            [GLOBAL])

An IMPORTED library target references a library file located outside the project. No rules are generated to build it, and the IMPORTED target property is True. The target name has scope in the directory in which it is created and below, but the GLOBAL option extends visibility. It may be referenced like any target built within the project. IMPORTED libraries are useful for convenient reference from commands like target_link_libraries(). Details about the imported library are specified by setting properties whose names begin in IMPORTED_ and INTERFACE_. The most important such property is IMPORTED_LOCATION (and its per-configuration variant IMPORTED_LOCATION_<CONFIG>) which specifies the location of the main library file on disk. Or, for object libraries, IMPORTED_OBJECTS (and IMPORTED_OBJECTS_<CONFIG>) specifies the locations of object files on disk. See documentation of the IMPORTED_* and INTERFACE_* properties for more information.

Object Libraries

add_library(<name> OBJECT <src>...)

Creates an Object Library. An object library compiles source files but does not archive or link their object files into a library. Instead other targets created by add_library() or add_executable() may reference the objects using an expression of the form $<TARGET_OBJECTS:objlib> as a source, where objlib is the object library name. For example:

add_library(... $<TARGET_OBJECTS:objlib> ...)
add_executable(... $<TARGET_OBJECTS:objlib> ...)

will include objlib’s object files in a library and an executable along with those compiled from their own sources. Object libraries may contain only sources that compile, header files, and other files that would not affect linking of a normal library (e.g. .txt). They may contain custom commands generating such sources, but not PRE_BUILD, PRE_LINK, or POST_BUILD commands. Some native build systems (such as Xcode) may not like targets that have only object files, so consider adding at least one real source file to any target that references $<TARGET_OBJECTS:objlib>.

Alias Libraries

add_library(<name> ALIAS <target>)

Creates an Alias Target, such that <name> can be used to refer to <target> in subsequent commands. The <name> does not appear in the generated buildsystem as a make target. The <target> may not be a non-GLOBAL Imported Target or an ALIAS. ALIAS targets can be used as linkable targets and as targets to read properties from. They can also be tested for existence with the regular if(TARGET) subcommand. The <name> may not be used to modify properties of <target>, that is, it may not be used as the operand of set_property(), set_target_properties(), target_link_libraries() etc. An ALIAS target may not be installed or exported.

Interface Libraries

add_library(<name> INTERFACE [IMPORTED [GLOBAL]])

Creates an Interface Library. An INTERFACE library target does not directly create build output, though it may have properties set on it and it may be installed, exported and imported. Typically the INTERFACE_* properties are populated on the interface target using the commands:

  • set_property(),
  • target_link_libraries(INTERFACE),
  • target_link_options(INTERFACE),
  • target_include_directories(INTERFACE),
  • target_compile_options(INTERFACE),
  • target_compile_definitions(INTERFACE), and
  • target_sources(INTERFACE),

and then it is used as an argument to target_link_libraries() like any other target.

An INTERFACE Imported Target may also be created with this signature. An IMPORTED library target references a library defined outside the project. The target name has scope in the directory in which it is created and below, but the GLOBAL option extends visibility. It may be referenced like any target built within the project. IMPORTED libraries are useful for convenient reference from commands like target_link_libraries().

  • cmake-commands(7) »


add_link_options — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_link_options

Add options to the link of shared library, module and executable targets.

add_link_options(<option> ...)

Adds options to the link step for targets in the current directory and below that are added after this command is invoked. See documentation of the directory and target LINK_OPTIONS properties.

This command can be used to add any options, but alternative commands exist to add libraries ( target_link_libraries() or link_libraries()).

Arguments to add_link_options may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

The final set of compile or link options used for a target is constructed by accumulating options from the current target and the usage requirements of it dependencies. The set of options is de-duplicated to avoid repetition. While beneficial for individual options, the de-duplication step can break up option groups. For example, -D A -D B becomes -D A B. One may specify a group of options using shell-like quoting along with a SHELL: prefix. The SHELL: prefix is dropped and the rest of the option string is parsed using the separate_arguments() UNIX_COMMAND mode. For example, "SHELL:-D A" "SHELL:-D B" becomes -D A -D B.

To pass options to the linker tool, each compiler driver has is own syntax. The LINKER: prefix can be used to specify, in a portable way, options to pass to the linker tool. The LINKER: prefix is replaced by the required driver option and the rest of the option string defines linker arguments using , as separator. These arguments will be formatted according to 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 alternate syntax, specification of arguments using SHELL: prefix and space as separator. Previous example becomes "LINKER:SHELL:-z defs".

Note

Specifying SHELL: prefix elsewhere than at the beginning of the LINKER: prefix is not supported.

  • cmake-commands(7) »


add_subdirectory — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_subdirectory

Add a subdirectory to the build.

add_subdirectory(source_dir [binary_dir] [EXCLUDE_FROM_ALL])

Adds a subdirectory to the build. The source_dir specifies the directory in which the source CMakeLists.txt and code files are located. If it is a relative path it will be evaluated with respect to the current directory (the typical usage), but it may also be an absolute path. The binary_dir specifies the directory in which to place the output files. If it is a relative path it will be evaluated with respect to the current output directory, but it may also be an absolute path. If binary_dir is not specified, the value of source_dir, before expanding any relative path, will be used (the typical usage). The CMakeLists.txt file in the specified source directory will be processed immediately by CMake before processing in the current input file continues beyond this command.

If the EXCLUDE_FROM_ALL argument is provided then targets in the subdirectory will not be included in the ALL target of the parent directory by default, and will be excluded from IDE project files. Users must explicitly build targets in the subdirectory. This is meant for use when the subdirectory contains a separate part of the project that is useful but not necessary, such as a set of examples. Typically the subdirectory should contain its own project() command invocation so that a full build system will be generated in the subdirectory (such as a VS IDE solution file). Note that inter-target dependencies supersede this exclusion. If a target built by the parent project depends on a target in the subdirectory, the dependee target will be included in the parent project build system to satisfy the dependency.

  • cmake-commands(7) »


add_test — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

add_test

Add a test to the project to be run by ctest(1).

add_test(NAME <name> COMMAND <command> [<arg>...]
         [CONFIGURATIONS <config>...]
         [WORKING_DIRECTORY <dir>])

Adds a test called <name>. The test name may not contain spaces, quotes, or other characters special in CMake syntax. The options are:

COMMAND
Specify the test command-line. If <command> specifies an executable target (created by add_executable()) it will automatically be replaced by the location of the executable created at build time.
CONFIGURATIONS
Restrict execution of the test only to the named configurations.
WORKING_DIRECTORY
Set the WORKING_DIRECTORY test property to specify the working directory in which to execute the test. If not specified the test will be run with the current working directory set to the build directory corresponding to the current source directory.

The given test command is expected to exit with code 0 to pass and non-zero to fail, or vice-versa if the WILL_FAIL test property is set. Any output written to stdout or stderr will be captured by ctest(1) but does not affect the pass/fail status unless the PASS_REGULAR_EXPRESSION or FAIL_REGULAR_EXPRESSION test property is used.

The COMMAND and WORKING_DIRECTORY options may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions.

Example usage:

add_test(NAME mytest
         COMMAND testDriver --config $<CONFIGURATION>
                            --exe $<TARGET_FILE:myexe>)

This creates a test mytest whose command runs a testDriver tool passing the configuration name and the full path to the executable file produced by target myexe.

Note

CMake will generate tests only if the enable_testing() command has been invoked. The CTest module invokes the command automatically when the BUILD_TESTING option is ON.

add_test(<name> <command> [<arg>...])

Add a test called <name> with the given command-line. Unlike the above NAME signature no transformation is performed on the command-line to support target names or generator expressions.

  • cmake-commands(7) »


aux_source_directory — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

aux_source_directory

Find all source files in a directory.

aux_source_directory(<dir> <variable>)

Collects the names of all the source files in the specified directory and stores the list in the <variable> provided. This command is intended to be used by projects that use explicit template instantiation. Template instantiation files can be stored in a “Templates” subdirectory and collected automatically using this command to avoid manually listing all instantiations.

It is tempting to use this command to avoid writing the list of source files for a library or executable target. While this seems to work, there is no way for CMake to generate a build system that knows when a new source file has been added. Normally the generated build system knows when it needs to rerun CMake because the CMakeLists.txt file is modified to add a new source. When the source is just added to the directory without modifying this file, one would have to manually rerun CMake to generate a build system incorporating the new file.

  • cmake-commands(7) »


build_command — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

build_command

Get a command line to build the current project. This is mainly intended for internal use by the CTest module.

build_command(<variable>
              [CONFIGURATION <config>]
              [TARGET <target>]
              [PROJECT_NAME <projname>] # legacy, causes warning
             )

Sets the given <variable> to a command-line string of the form:

<cmake> --build . [--config <config>] [--target <target>] [-- -i]

where <cmake> is the location of the cmake(1) command-line tool, and <config> and <target> are the values provided to the CONFIGURATION and TARGET options, if any. The trailing -- -i option is added for Makefile Generators if policy CMP0061 is not set to NEW.

When invoked, this cmake --build command line will launch the underlying build system tool.

build_command(<cachevariable> <makecommand>)

This second signature is deprecated, but still available for backwards compatibility. Use the first signature instead.

It sets the given <cachevariable> to a command-line string as above but without the --target option. The <makecommand> is ignored but should be the full path to devenv, nmake, make or one of the end user build tools for legacy invocations.

Note

In CMake versions prior to 3.0 this command returned a command line that directly invokes the native build tool for the current generator. Their implementation of the PROJECT_NAME option had no useful effects, so CMake now warns on use of the option.

  • cmake-commands(7) »


create_test_sourcelist — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

create_test_sourcelist

Create a test driver and source list for building test programs.

create_test_sourcelist(sourceListName driverName
                       test1 test2 test3
                       EXTRA_INCLUDE include.h
                       FUNCTION function)

A test driver is a program that links together many small tests into a single executable. This is useful when building static executables with large libraries to shrink the total required size. The list of source files needed to build the test driver will be in sourceListName. driverName is the name of the test driver program. The rest of the arguments consist of a list of test source files, can be semicolon separated. Each test source file should have a function in it that is the same name as the file with no extension (foo.cxx should have int foo(int, char*[]);) driverName will be able to call each of the tests by name on the command line. If EXTRA_INCLUDE is specified, then the next argument is included into the generated file. If FUNCTION is specified, then the next argument is taken as a function name that is passed a pointer to ac and av. This can be used to add extra command line processing to each test. The CMAKE_TESTDRIVER_BEFORE_TESTMAIN cmake variable can be set to have code that will be placed directly before calling the test main function. CMAKE_TESTDRIVER_AFTER_TESTMAIN can be set to have code that will be placed directly after the call to the test main function.

  • cmake-commands(7) »


define_property — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

define_property

Define and document custom properties.

define_property(<GLOBAL | DIRECTORY | TARGET | SOURCE |
                 TEST | VARIABLE | CACHED_VARIABLE>
                 PROPERTY <name> [INHERITED]
                 BRIEF_DOCS <brief-doc> [docs...]
                 FULL_DOCS <full-doc> [docs...])

Defines one property in a scope for use with the set_property() and get_property() commands. This is primarily useful to associate documentation with property names that may be retrieved with the get_property() command. The first argument determines the kind of scope in which the property should be used. It must be one of the following:

GLOBAL    = associated with the global namespace
DIRECTORY = associated with one directory
TARGET    = associated with one target
SOURCE    = associated with one source file
TEST      = associated with a test named with add_test
VARIABLE  = documents a CMake language variable
CACHED_VARIABLE = documents a CMake cache variable

Note that unlike set_property() and get_property() no actual scope needs to be given; only the kind of scope is important.

The required PROPERTY option is immediately followed by the name of the property being defined.

If the INHERITED option is given, then the get_property() command will chain up to the next higher scope when the requested property is not set in the scope given to the command.

  • DIRECTORY scope chains to its parent directory’s scope, continuing the walk up parent directories until a directory has the property set or there are no more parents. If still not found at the top level directory, it chains to the GLOBAL scope.
  • TARGET, SOURCE and TEST properties chain to DIRECTORY scope, including further chaining up the directories, etc. as needed.

Note that this scope chaining behavior only applies to calls to get_property(), get_directory_property(), get_target_property(), get_source_file_property() and get_test_property(). There is no inheriting behavior when setting properties, so using APPEND or APPEND_STRING with the set_property() command will not consider inherited values when working out the contents to append to.

The BRIEF_DOCS and FULL_DOCS options are followed by strings to be associated with the property as its brief and full documentation. Corresponding options to the get_property() command will retrieve the documentation.

  • cmake-commands(7) »


enable_language — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

enable_language

Enable a language (CXX/C/Fortran/etc)

enable_language(<lang> [OPTIONAL] )

Enables support for the named language in CMake. This is the same as the project() command but does not create any of the extra variables that are created by the project command. Example languages are CXX, C, CUDA, Fortran, and ASM.

If enabling ASM, enable it last so that CMake can check whether compilers for other languages like C work for assembly too.

This command must be called in file scope, not in a function call. Furthermore, it must be called in the highest directory common to all targets using the named language directly for compiling sources or indirectly through link dependencies. It is simplest to enable all needed languages in the top-level directory of a project.

The OPTIONAL keyword is a placeholder for future implementation and does not currently work. Instead you can use the CheckLanguage module to verify support before enabling.

  • cmake-commands(7) »


enable_testing — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

enable_testing

Enable testing for current directory and below.

enable_testing()

Enables testing for this directory and below. See also the add_test() command. Note that ctest expects to find a test file in the build directory root. Therefore, this command should be in the source directory root.

  • cmake-commands(7) »


export — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

export

Export targets from the build tree for use by outside projects.

export(EXPORT <export-name> [NAMESPACE <namespace>] [FILE <filename>])

Creates a file <filename> that may be included by outside projects to import targets from the current project’s build tree. This is useful during cross-compiling to build utility executables that can run on the host platform in one project and then import them into another project being compiled for the target platform. If the NAMESPACE option is given the <namespace> string will be prepended to all target names written to the file.

Target installations are associated with the export <export-name> using the EXPORT option of the install(TARGETS) command.

The file created by this command is specific to the build tree and should never be installed. See the install(EXPORT) command to export targets from an installation tree.

The properties set on the generated IMPORTED targets will have the same values as the final values of the input TARGETS.

export(TARGETS [target1 [target2 [...]]] [NAMESPACE <namespace>]
       [APPEND] FILE <filename> [EXPORT_LINK_INTERFACE_LIBRARIES])

This signature is similar to the EXPORT signature, but targets are listed explicitly rather than specified as an export-name. If the APPEND option is given the generated code will be appended to the file instead of overwriting it. The EXPORT_LINK_INTERFACE_LIBRARIES keyword, if present, causes the contents of the properties matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)? to be exported, when policy CMP0022 is NEW. If a library target is included in the export but a target to which it links is not included the behavior is unspecified.

Note

Object Libraries under Xcode have special handling if multiple architectures are listed in CMAKE_OSX_ARCHITECTURES. In this case they will be exported as Interface Libraries with no object files available to clients. This is sufficient to satisfy transitive usage requirements of other targets that link to the object libraries in their implementation.

export(PACKAGE <PackageName>)

Store the current build directory in the CMake user package registry for package <PackageName>. The find_package command may consider the directory while searching for package <PackageName>. This helps dependent projects find and use a package from the current project’s build tree without help from the user. Note that the entry in the package registry that this command creates works only in conjunction with a package configuration file (<PackageName>Config.cmake) that works with the build tree. 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.

export(TARGETS [target1 [target2 [...]]]  [ANDROID_MK <filename>])

This signature exports cmake built targets to the android ndk build system by creating an Android.mk file that references the prebuilt targets. The Android NDK supports the use of prebuilt libraries, both static and shared. This allows cmake to build the libraries of a project and make them available to an ndk build system complete with transitive dependencies, include flags and defines required to use the libraries. The signature takes a list of targets and puts them in the Android.mk file specified by the <filename> given. This signature can only be used if policy CMP0022 is NEW for all targets given. A error will be issued if that policy is set to OLD for one of the targets.

  • cmake-commands(7) »


fltk_wrap_ui — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

fltk_wrap_ui

Create FLTK user interfaces Wrappers.

fltk_wrap_ui(resultingLibraryName source1
             source2 ... sourceN )

Produce .h and .cxx files for all the .fl and .fld files listed. The resulting .h and .cxx files will be added to a variable named resultingLibraryName_FLTK_UI_SRCS which should be added to your library.

  • cmake-commands(7) »


get_source_file_property — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

get_source_file_property

Get a property for a source file.

get_source_file_property(VAR file property)

Gets a property from a source file. The value of the property is stored in the variable VAR. If the source property is not found, the behavior depends on whether it has been defined to be an INHERITED property or not (see define_property()). Non-inherited properties will set VAR to “NOTFOUND”, whereas inherited properties will search the relevant parent scope as described for the define_property() command and if still unable to find the property, VAR will be set to an empty string.

Use set_source_files_properties() to set property values. Source file properties usually control how the file is built. One property that is always there is LOCATION.

See also the more general get_property() command.

  • cmake-commands(7) »


get_target_property — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

get_target_property

Get a property from a target.

get_target_property(VAR target property)

Get a property from a target. The value of the property is stored in the variable VAR. If the target property is not found, the behavior depends on whether it has been defined to be an INHERITED property or not (see define_property()). Non-inherited properties will set VAR to “NOTFOUND”, whereas inherited properties will search the relevant parent scope as described for the define_property() command and if still unable to find the property, VAR will be set to an empty string.

Use set_target_properties() to set target property values. Properties are usually used to control how a target is built, but some query the target instead. This command can get properties for any target so far created. The targets do not need to be in the current CMakeLists.txt file.

See also the more general get_property() command.

See Properties on Targets for the list of properties known to CMake.

  • cmake-commands(7) »


get_test_property — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

get_test_property

Get a property of the test.

get_test_property(test property VAR)

Get a property from the test. The value of the property is stored in the variable VAR. If the test property is not found, the behavior depends on whether it has been defined to be an INHERITED property or not (see define_property()). Non-inherited properties will set VAR to “NOTFOUND”, whereas inherited properties will search the relevant parent scope as described for the define_property() command and if still unable to find the property, VAR will be set to an empty string.

For a list of standard properties you can type cmake --help-property-list.

See also the more general get_property() command.

  • cmake-commands(7) »


include_directories — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

include_directories

Add include directories to the build.

include_directories([AFTER|BEFORE] [SYSTEM] dir1 [dir2 ...])

Add the given directories to those the compiler uses to search for include files. Relative paths are interpreted as relative to the current source directory.

The include directories are added to the INCLUDE_DIRECTORIES directory property for the current CMakeLists file. They are also added to the INCLUDE_DIRECTORIES target property for each target in the current CMakeLists file. The target property values are the ones used by the generators.

By default the directories specified are appended onto the current list of directories. This default behavior can be changed by setting CMAKE_INCLUDE_DIRECTORIES_BEFORE to ON. By using AFTER or BEFORE explicitly, you can select between appending and prepending, independent of the default.

If the SYSTEM option is given, the compiler will be told the directories are meant as system include directories on some platforms. Signalling this setting might achieve effects such as the compiler skipping warnings, or these fixed-install system files not being considered in dependency calculations - see compiler docs.

Arguments to include_directories may use “generator expressions” with the syntax “$<…>”. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Note

Prefer the target_include_directories() command to add include directories to individual targets and optionally propagate/export them to dependents.

  • cmake-commands(7) »


include_external_msproject — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

include_external_msproject

Include an external Microsoft project file in a workspace.

include_external_msproject(projectname location
                           [TYPE projectTypeGUID]
                           [GUID projectGUID]
                           [PLATFORM platformName]
                           dep1 dep2 ...)

Includes an external Microsoft project in the generated workspace file. Currently does nothing on UNIX. This will create a target named [projectname]. This can be used in the add_dependencies() command to make things depend on the external project.

TYPE, GUID and PLATFORM are optional parameters that allow one to specify the type of project, id (GUID) of the project and the name of the target platform. This is useful for projects requiring values other than the default (e.g. WIX projects).

If the imported project has different configuration names than the current project, set the MAP_IMPORTED_CONFIG_<CONFIG> target property to specify the mapping.

  • cmake-commands(7) »


include_regular_expression — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

include_regular_expression

Set the regular expression used for dependency checking.

include_regular_expression(regex_match [regex_complain])

Sets the regular expressions used in dependency checking. Only files matching regex_match will be traced as dependencies. Only files matching regex_complain will generate warnings if they cannot be found (standard header paths are not searched). The defaults are:

regex_match    = "^.*$" (match everything)
regex_complain = "^$" (match empty string only)

  • cmake-commands(7) »


install — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

install

Specify rules to run at install time.

Synopsis

install(TARGETS <target>... [...])
install({FILES | PROGRAMS} <file>... [...])
install(DIRECTORY <dir>... [...])
install(SCRIPT <file> [...])
install(CODE <code> [...])
install(EXPORT <export-name> [...])

Introduction

This command generates installation rules for a project. Rules specified by calls to this command within a source directory are executed in order during installation. The order across directories is not defined.

There are multiple signatures for this command. Some of them define installation options for files and targets. Options common to multiple signatures are covered here but they are valid only for signatures that specify them. The common options are:

DESTINATION
Specify the directory on disk to which a file will be installed. If a full path (with a leading slash or drive letter) is given it is used directly. If a relative path is given it is interpreted relative to the value of the CMAKE_INSTALL_PREFIX variable. The prefix can be relocated at install time using the DESTDIR mechanism explained in the CMAKE_INSTALL_PREFIX variable documentation.
PERMISSIONS
Specify permissions for installed files. Valid permissions are OWNER_READ, OWNER_WRITE, OWNER_EXECUTE, GROUP_READ, GROUP_WRITE, GROUP_EXECUTE, WORLD_READ, WORLD_WRITE, WORLD_EXECUTE, SETUID, and SETGID. Permissions that do not make sense on certain platforms are ignored on those platforms.
CONFIGURATIONS

Specify a list of build configurations for which the install rule applies (Debug, Release, etc.). Note that the values specified for this option only apply to options listed AFTER the CONFIGURATIONS option. For example, to set separate install paths for the Debug and Release configurations, do the following:

install(TARGETS target
        CONFIGURATIONS Debug
        RUNTIME DESTINATION Debug/bin)
install(TARGETS target
        CONFIGURATIONS Release
        RUNTIME DESTINATION Release/bin)

Note that CONFIGURATIONS appears BEFORE RUNTIME DESTINATION.

COMPONENT
Specify an installation component name with which the install rule is associated, such as “runtime” or “development”. During component-specific installation only install rules associated with the given component name will be executed. During a full installation all components are installed unless marked with EXCLUDE_FROM_ALL. If COMPONENT is not provided a default component “Unspecified” is created. The default component name may be controlled with the CMAKE_INSTALL_DEFAULT_COMPONENT_NAME variable.
EXCLUDE_FROM_ALL
Specify that the file is excluded from a full installation and only installed as part of a component-specific installation
RENAME
Specify a name for an installed file that may be different from the original file. Renaming is allowed only when a single file is installed by the command.
OPTIONAL
Specify that it is not an error if the file to be installed does not exist.

Command signatures that install files may print messages during installation. Use the CMAKE_INSTALL_MESSAGE variable to control which messages are printed.

Many of the install() variants implicitly create the directories containing the installed files. If CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS is set, these directories will be created with the permissions specified. Otherwise, they will be created according to the uname rules on Unix-like platforms. Windows platforms are unaffected.

Installing Targets

install(TARGETS targets... [EXPORT <export-name>]
        [[ARCHIVE|LIBRARY|RUNTIME|OBJECTS|FRAMEWORK|BUNDLE|
          PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
         [DESTINATION <dir>]
         [PERMISSIONS permissions...]
         [CONFIGURATIONS [Debug|Release|...]]
         [COMPONENT <component>]
         [NAMELINK_COMPONENT <component>]
         [OPTIONAL] [EXCLUDE_FROM_ALL]
         [NAMELINK_ONLY|NAMELINK_SKIP]
        ] [...]
        [INCLUDES DESTINATION [<dir> ...]]
        )

The TARGETS form specifies rules for installing targets from a project. There are several kinds of target files that may be installed:

ARCHIVE
Static libraries are treated as ARCHIVE targets, except those marked with the FRAMEWORK property on macOS (see FRAMEWORK below.) For DLL platforms (all Windows-based systems including Cygwin), the DLL import library is treated as an ARCHIVE target.
LIBRARY
Module libraries are always treated as LIBRARY targets. For non- DLL platforms shared libraries are treated as LIBRARY targets, except those marked with the FRAMEWORK property on macOS (see FRAMEWORK below.)
RUNTIME
Executables are treated as RUNTIME objects, except those marked with the MACOSX_BUNDLE property on macOS (see BUNDLE below.) For DLL platforms (all Windows-based systems including Cygwin), the DLL part of a shared library is treated as a RUNTIME target.
OBJECTS
Object libraries (a simple group of object files) are always treated as OBJECTS targets.
FRAMEWORK
Both static and shared libraries marked with the FRAMEWORK property are treated as FRAMEWORK targets on macOS.
BUNDLE
Executables marked with the MACOSX_BUNDLE property are treated as BUNDLE targets on macOS.
PUBLIC_HEADER
Any PUBLIC_HEADER files associated with a library are installed in the destination specified by the PUBLIC_HEADER argument on non-Apple platforms. Rules defined by this argument are ignored for FRAMEWORK libraries on Apple platforms because the associated files are installed into the appropriate locations inside the framework folder. See PUBLIC_HEADER for details.
PRIVATE_HEADER
Similar to PUBLIC_HEADER, but for PRIVATE_HEADER files. See PRIVATE_HEADER for details.
RESOURCE
Similar to PUBLIC_HEADER and PRIVATE_HEADER, but for RESOURCE files. See RESOURCE for details.

For each of these arguments given, the arguments following them only apply to the target or file type specified in the argument. If none is given, the installation properties apply to all target types. If only one is given then only targets of that type will be installed (which can be used to install just a DLL or just an import library.)

For regular executables, static libraries and shared libraries, the DESTINATION argument is not required. For these target types, when DESTINATION is omitted, a default destination will be taken from the appropriate variable from GNUInstallDirs, or set to a built-in default value if that variable is not defined. The same is true for the public and private headers associated with the installed targets through the PUBLIC_HEADER and PRIVATE_HEADER target properties. A destination must always be provided for module libraries, Apple bundles and frameworks. A destination can be omitted for interface and object libraries, but they are handled differently (see the discussion of this topic toward the end of this section).

The following table shows the target types with their associated variables and built-in defaults that apply when no destination is given:

Target Type | GNUInstallDirs Variable | Built-In Default
RUNTIME | ${CMAKE_INSTALL_BINDIR} | bin
LIBRARY | ${CMAKE_INSTALL_LIBDIR} | lib
ARCHIVE | ${CMAKE_INSTALL_LIBDIR} | lib
PRIVATE_HEADER | ${CMAKE_INSTALL_INCLUDEDIR} | include
PUBLIC_HEADER | ${CMAKE_INSTALL_INCLUDEDIR} | include

Projects wishing to follow the common practice of installing headers into a project-specific subdirectory will need to provide a destination rather than rely on the above.

To make packages compliant with distribution filesystem layout policies, if projects must specify a DESTINATION, it is recommended that they use a path that begins with the appropriate GNUInstallDirs variable. This allows package maintainers to control the install destination by setting the appropriate cache variables. The following example shows a static library being installed to the default destination provided by GNUInstallDirs, but with its headers installed to a project-specific subdirectory that follows the above recommendation:

add_library(mylib STATIC ...)
set_target_properties(mylib PROPERTIES PUBLIC_HEADER mylib.h)
include(GNUInstallDirs)
install(TARGETS mylib
        PUBLIC_HEADER
          DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/myproj
)

In addition to the common options listed above, each target can accept the following additional arguments:

NAMELINK_COMPONENT

On some platforms a versioned shared library has a symbolic link such as:

lib<name>.so -> lib<name>.so.1

where lib<name>.so.1 is the soname of the library and lib<name>.so is a “namelink” allowing linkers to find the library when given -l<name>. The NAMELINK_COMPONENT option is similar to the COMPONENT option, but it changes the installation component of a shared library namelink if one is generated. If not specified, this defaults to the value of COMPONENT. It is an error to use this parameter outside of a LIBRARY block.

Consider the following example:

install(TARGETS mylib
        LIBRARY
          COMPONENT Libraries
          NAMELINK_COMPONENT Development
        PUBLIC_HEADER
          COMPONENT Development
       )

In this scenario, if you choose to install only the Development component, both the headers and namelink will be installed without the library. (If you don’t also install the Libraries component, the namelink will be a dangling symlink, and projects that link to the library will have build errors.) If you install only the Libraries component, only the library will be installed, without the headers and namelink.

This option is typically used for package managers that have separate runtime and development packages. For example, on Debian systems, the library is expected to be in the runtime package, and the headers and namelink are expected to be in the development package.

See the VERSION and SOVERSION target properties for details on creating versioned shared libraries.

NAMELINK_ONLY

This option causes the installation of only the namelink when a library target is installed. On platforms where versioned shared libraries do not have namelinks or when a library is not versioned, the NAMELINK_ONLY option installs nothing. It is an error to use this parameter outside of a LIBRARY block.

When NAMELINK_ONLY is given, either NAMELINK_COMPONENT or COMPONENT may be used to specify the installation component of the namelink, but COMPONENT should generally be preferred.

NAMELINK_SKIP

Similar to NAMELINK_ONLY, but it has the opposite effect: it causes the installation of library files other than the namelink when a library target is installed. When neither NAMELINK_ONLY or NAMELINK_SKIP are given, both portions are installed. On platforms where versioned shared libraries do not have symlinks or when a library is not versioned, NAMELINK_SKIP installs the library. It is an error to use this parameter outside of a LIBRARY block.

If NAMELINK_SKIP is specified, NAMELINK_COMPONENT has no effect. It is not recommended to use NAMELINK_SKIP in conjunction with NAMELINK_COMPONENT.

The install(TARGETS) command can also accept the following options at the top level:

EXPORT
This option associates the installed target files with an export called <export-name>. It must appear before any target options. To actually install the export file itself, call install(EXPORT), documented below.
INCLUDES DESTINATION
This option specifies a list of directories which will be added to the INTERFACE_INCLUDE_DIRECTORIES target property of the <targets> when exported by the install(EXPORT) command. If a relative path is specified, it is treated as relative to the $<INSTALL_PREFIX>.

One or more groups of properties may be specified in a single call to the TARGETS form of this command. A target may be installed more than once to different locations. Consider hypothetical targets myExe, mySharedLib, and myStaticLib. The code:

install(TARGETS myExe mySharedLib myStaticLib
        RUNTIME DESTINATION bin
        LIBRARY DESTINATION lib
        ARCHIVE DESTINATION lib/static)
install(TARGETS mySharedLib DESTINATION /some/full/path)

will install myExe to <prefix>/bin and myStaticLib to <prefix>/lib/static. On non-DLL platforms mySharedLib will be installed to <prefix>/lib and /some/full/path. On DLL platforms the mySharedLib DLL will be installed to <prefix>/bin and /some/full/path and its import library will be installed to <prefix>/lib/static and /some/full/path.

Interface Libraries may be listed among the targets to install. They install no artifacts but will be included in an associated EXPORT. If Object Libraries are listed but given no destination for their object files, they will be exported as Interface Libraries. This is sufficient to satisfy transitive usage requirements of other targets that link to the object libraries in their implementation.

Installing a target with the EXCLUDE_FROM_ALL target property set to TRUE has undefined behavior.

install(TARGETS) can install targets that were created in other directories. When using such cross-directory install rules, running make install (or similar) from a subdirectory will not guarantee that targets from other directories are up-to-date. You can use target_link_libraries() or add_dependencies() to ensure that such out-of-directory targets are built before the subdirectory-specific install rules are run.

An install destination given as a DESTINATION argument may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions.

Installing Files

install(<FILES|PROGRAMS> files...
        TYPE <type> | DESTINATION <dir>
        [PERMISSIONS permissions...]
        [CONFIGURATIONS [Debug|Release|...]]
        [COMPONENT <component>]
        [RENAME <name>] [OPTIONAL] [EXCLUDE_FROM_ALL])

The FILES form specifies rules for installing files for a project. File names given as relative paths are interpreted with respect to the current source directory. Files installed by this form are by default given permissions OWNER_WRITE, OWNER_READ, GROUP_READ, and WORLD_READ if no PERMISSIONS argument is given.

The PROGRAMS form is identical to the FILES form except that the default permissions for the installed file also include OWNER_EXECUTE, GROUP_EXECUTE, and WORLD_EXECUTE. This form is intended to install programs that are not targets, such as shell scripts. Use the TARGETS form to install targets built within the project.

The list of files... given to FILES or PROGRAMS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. However, if any item begins in a generator expression it must evaluate to a full path.

Either a TYPE or a DESTINATION must be provided, but not both. A TYPE argument specifies the generic file type of the files being installed. A destination will then be set automatically by taking the corresponding variable from GNUInstallDirs, or by using a built-in default if that variable is not defined. See the table below for the supported file types and their corresponding variables and built-in defaults. Projects can provide a DESTINATION argument instead of a file type if they wish to explicitly define the install destination.

TYPE Argument | GNUInstallDirs Variable | Built-In Default
BIN | ${CMAKE_INSTALL_BINDIR} | bin
SBIN | ${CMAKE_INSTALL_SBINDIR} | sbin
LIB | ${CMAKE_INSTALL_LIBDIR} | lib
INCLUDE | ${CMAKE_INSTALL_INCLUDEDIR} | include
SYSCONF | ${CMAKE_INSTALL_SYSCONFDIR} | etc
SHAREDSTATE | ${CMAKE_INSTALL_SHARESTATEDIR} | com
LOCALSTATE | ${CMAKE_INSTALL_LOCALSTATEDIR} | var
RUNSTATE | ${CMAKE_INSTALL_RUNSTATEDIR} | <LOCALSTATE dir>/run
DATA | ${CMAKE_INSTALL_DATADIR} | <DATAROOT dir>
INFO | ${CMAKE_INSTALL_INFODIR} | <DATAROOT dir>/info
LOCALE | ${CMAKE_INSTALL_LOCALEDIR} | <DATAROOT dir>/locale
MAN | ${CMAKE_INSTALL_MANDIR} | <DATAROOT dir>/man
DOC | ${CMAKE_INSTALL_DOCDIR} | <DATAROOT dir>/doc

Projects wishing to follow the common practice of installing headers into a project-specific subdirectory will need to provide a destination rather than rely on the above.

Note that some of the types’ built-in defaults use the DATAROOT directory as a prefix. The DATAROOT prefix is calculated similarly to the types, with CMAKE_INSTALL_DATAROOTDIR as the variable and share as the built-in default. You cannot use DATAROOT as a TYPE parameter; please use DATA instead.

To make packages compliant with distribution filesystem layout policies, if projects must specify a DESTINATION, it is recommended that they use a path that begins with the appropriate GNUInstallDirs variable. This allows package maintainers to control the install destination by setting the appropriate cache variables. The following example shows how to follow this advice while installing headers to a project-specific subdirectory:

include(GNUInstallDirs)
install(FILES mylib.h
        DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/myproj
)

An install destination given as a DESTINATION argument may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions.

Installing Directories

install(DIRECTORY dirs...
        TYPE <type> | DESTINATION <dir>
        [FILE_PERMISSIONS permissions...]
        [DIRECTORY_PERMISSIONS permissions...]
        [USE_SOURCE_PERMISSIONS] [OPTIONAL] [MESSAGE_NEVER]
        [CONFIGURATIONS [Debug|Release|...]]
        [COMPONENT <component>] [EXCLUDE_FROM_ALL]
        [FILES_MATCHING]
        [[PATTERN <pattern> | REGEX <regex>]
         [EXCLUDE] [PERMISSIONS permissions...]] [...])

The DIRECTORY form installs contents of one or more directories to a given destination. The directory structure is copied verbatim to the destination. The last component of each directory name is appended to the destination directory but a trailing slash may be used to avoid this because it leaves the last component empty. Directory names given as relative paths are interpreted with respect to the current source directory. If no input directory names are given the destination directory will be created but nothing will be installed into it. The FILE_PERMISSIONS and DIRECTORY_PERMISSIONS options specify permissions given to files and directories in the destination. If USE_SOURCE_PERMISSIONS is specified and FILE_PERMISSIONS is not, file permissions will be copied from the source directory structure. If no permissions are specified files will be given the default permissions specified in the FILES form of the command, and the directories will be given the default permissions specified in the PROGRAMS form of the command.

The MESSAGE_NEVER option disables file installation status output.

Installation of directories may be controlled with fine granularity using the PATTERN or REGEX options. These “match” options specify a globbing pattern or regular expression to match directories or files encountered within input directories. They may be used to apply certain options (see below) to a subset of the files and directories encountered. The full path to each input file or directory (with forward slashes) is matched against the expression. A PATTERN will match only complete file names: the portion of the full path matching the pattern must occur at the end of the file name and be preceded by a slash. A REGEX will match any portion of the full path but it may use / and $ to simulate the PATTERN behavior. By default all files and directories are installed whether or not they are matched. The FILES_MATCHING option may be given before the first match option to disable installation of files (but not directories) not matched by any expression. For example, the code

install(DIRECTORY src/ DESTINATION include/myproj
        FILES_MATCHING PATTERN "*.h")

will extract and install header files from a source tree.

Some options may follow a PATTERN or REGEX expression and are applied only to files or directories matching them. The EXCLUDE option will skip the matched file or directory. The PERMISSIONS option overrides the permissions setting for the matched file or directory. For example the code

install(DIRECTORY icons scripts/ DESTINATION share/myproj
        PATTERN "CVS" EXCLUDE
        PATTERN "scripts/*"
        PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ
                    GROUP_EXECUTE GROUP_READ)

will install the icons directory to share/myproj/icons and the scripts directory to share/myproj. The icons will get default file permissions, the scripts will be given specific permissions, and any CVS directories will be excluded.

Either a TYPE or a DESTINATION must be provided, but not both. A TYPE argument specifies the generic file type of the files within the listed directories being installed. A destination will then be set automatically by taking the corresponding variable from GNUInstallDirs, or by using a built-in default if that variable is not defined. See the table below for the supported file types and their corresponding variables and built-in defaults. Projects can provide a DESTINATION argument instead of a file type if they wish to explicitly define the install destination.

TYPE Argument | GNUInstallDirs Variable | Built-In Default
BIN | ${CMAKE_INSTALL_BINDIR} | bin
SBIN | ${CMAKE_INSTALL_SBINDIR} | sbin
LIB | ${CMAKE_INSTALL_LIBDIR} | lib
INCLUDE | ${CMAKE_INSTALL_INCLUDEDIR} | include
SYSCONF | ${CMAKE_INSTALL_SYSCONFDIR} | etc
SHAREDSTATE | ${CMAKE_INSTALL_SHARESTATEDIR} | com
LOCALSTATE | ${CMAKE_INSTALL_LOCALSTATEDIR} | var
RUNSTATE | ${CMAKE_INSTALL_RUNSTATEDIR} | <LOCALSTATE dir>/run
DATA | ${CMAKE_INSTALL_DATADIR} | <DATAROOT dir>
INFO | ${CMAKE_INSTALL_INFODIR} | <DATAROOT dir>/info
LOCALE | ${CMAKE_INSTALL_LOCALEDIR} | <DATAROOT dir>/locale
MAN | ${CMAKE_INSTALL_MANDIR} | <DATAROOT dir>/man
DOC | ${CMAKE_INSTALL_DOCDIR} | <DATAROOT dir>/doc

Note that some of the types’ built-in defaults use the DATAROOT directory as a prefix. The DATAROOT prefix is calculated similarly to the types, with CMAKE_INSTALL_DATAROOTDIR as the variable and share as the built-in default. You cannot use DATAROOT as a TYPE parameter; please use DATA instead.

To make packages compliant with distribution filesystem layout policies, if projects must specify a DESTINATION, it is recommended that they use a path that begins with the appropriate GNUInstallDirs variable. This allows package maintainers to control the install destination by setting the appropriate cache variables.

The list of dirs... given to DIRECTORY and an install destination given as a DESTINATION argument may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions.

Custom Installation Logic

install([[SCRIPT <file>] [CODE <code>]]
        [COMPONENT <component>] [EXCLUDE_FROM_ALL] [...])

The SCRIPT form will invoke the given CMake script files during installation. If the script file name is a relative path it will be interpreted with respect to the current source directory. The CODE form will invoke the given CMake code during installation. Code is specified as a single argument inside a double-quoted string. For example, the code

install(CODE "MESSAGE(\"Sample install message.\")")

will print a message during installation.

<file> or <code> may use “generator expressions” with the syntax $<...> (in the case of <file>, this refers to their use in the file name, not the file’s contents). See the cmake-generator-expressions(7) manual for available expressions.

Installing Exports

install(EXPORT <export-name> DESTINATION <dir>
        [NAMESPACE <namespace>] [[FILE <name>.cmake]|
        [PERMISSIONS permissions...]
        [CONFIGURATIONS [Debug|Release|...]]
        [EXPORT_LINK_INTERFACE_LIBRARIES]
        [COMPONENT <component>]
        [EXCLUDE_FROM_ALL])
install(EXPORT_ANDROID_MK <export-name> DESTINATION <dir> [...])

The EXPORT form generates and installs a CMake file containing code to import targets from the installation tree into another project. Target installations are associated with the export <export-name> using the EXPORT option of the install(TARGETS) signature documented above. The NAMESPACE option will prepend <namespace> to the target names as they are written to the import file. By default the generated file will be called <export-name>.cmake but the FILE option may be used to specify a different name. The value given to the FILE option must be a file name with the .cmake extension. If a CONFIGURATIONS option is given then the file will only be installed when one of the named configurations is installed. Additionally, the generated import file will reference only the matching target configurations. The EXPORT_LINK_INTERFACE_LIBRARIES keyword, if present, causes the contents of the properties matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)? to be exported, when policy CMP0022 is NEW.

When a COMPONENT option is given, the listed <component> implicitly depends on all components mentioned in the export set. The exported <name>.cmake file will require each of the exported components to be present in order for dependent projects to build properly. For example, a project may define components Runtime and Development, with shared libraries going into the Runtime component and static libraries and headers going into the Development component. The export set would also typically be part of the Development component, but it would export targets from both the Runtime and Development components. Therefore, the Runtime component would need to be installed if the Development component was installed, but not vice versa. If the Development component was installed without the Runtime component, dependent projects that try to link against it would have build errors. Package managers, such as APT and RPM, typically handle this by listing the Runtime component as a dependency of the Development component in the package metadata, ensuring that the library is always installed if the headers and CMake export file are present.

In addition to cmake language files, the EXPORT_ANDROID_MK mode maybe used to specify an export to the android ndk build system. This mode accepts the same options as the normal export mode. The Android NDK supports the use of prebuilt libraries, both static and shared. This allows cmake to build the libraries of a project and make them available to an ndk build system complete with transitive dependencies, include flags and defines required to use the libraries.

The EXPORT form is useful to help outside projects use targets built and installed by the current project. For example, the code

install(TARGETS myexe EXPORT myproj DESTINATION bin)
install(EXPORT myproj NAMESPACE mp_ DESTINATION lib/myproj)
install(EXPORT_ANDROID_MK myexp DESTINATION share/ndk-modules)

will install the executable myexe to <prefix>/bin and code to import it in the file <prefix>/lib/myproj/myproj.cmake and <prefix>/share/ndk-modules/Android.mk. An outside project may load this file with the include command and reference the myexe executable from the installation tree using the imported target name mp_myexe as if the target were built in its own tree.

Note

This command supercedes the install_targets() command and the PRE_INSTALL_SCRIPT and POST_INSTALL_SCRIPT target properties. It also replaces the FILES forms of the install_files() and install_programs() commands. The processing order of these install rules relative to those generated by install_targets(), install_files(), and install_programs() commands is not defined.

Generated Installation Script

The install() command generates a file, cmake_install.cmake, inside the build directory, which is used internally by the generated install target and by CPack. You can also invoke this script manually with cmake -P. This script accepts several variables:

COMPONENT
Set this variable to install only a single CPack component as opposed to all of them. For example, if you only want to install the Development component, run cmake -DCOMPONENT=Development -P cmake_install.cmake.
BUILD_TYPE
Set this variable to change the build type if you are using a multi-config generator. For example, to install with the Debug configuration, run cmake -DBUILD_TYPE=Debug -P cmake_install.cmake.
DESTDIR
This is an environment variable rather than a CMake variable. It allows you to change the installation prefix on UNIX systems. See DESTDIR for details.

  • cmake-commands(7) »


link_directories — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

link_directories

Add directories in which the linker will look for libraries.

link_directories([AFTER|BEFORE] directory1 [directory2 ...])

Adds the paths in which the linker should search for libraries. Relative paths given to this command are interpreted as relative to the current source directory, see CMP0015.

The directories are added to the LINK_DIRECTORIES directory property for the current CMakeLists.txt file, converting relative paths to absolute as needed. The command will apply only to targets created after it is called.

By default the directories specified are appended onto the current list of directories. This default behavior can be changed by setting CMAKE_LINK_DIRECTORIES_BEFORE to ON. By using AFTER or BEFORE explicitly, you can select between appending and prepending, independent of the default.

Arguments to link_directories may use “generator expressions” with the syntax “$<…>”. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Note

This command is rarely necessary and should be avoided where there are other choices. Prefer to pass full absolute paths to libraries where possible, since this ensures the correct library will always be linked. The find_library() command provides the full path, which can generally be used directly in calls to target_link_libraries(). Situations where a library search path may be needed include:

  • Project generators like Xcode where the user can switch target architecture at build time, but a full path to a library cannot be used because it only provides one architecture (i.e. it is not a universal binary).
  • Libraries may themselves have other private library dependencies that expect to be found via RPATH mechanisms, but some linkers are not able to fully decode those paths (e.g. due to the presence of things like $ORIGIN).

If a library search path must be provided, prefer to localize the effect where possible by using the target_link_directories() command rather than link_directories(). The target-specific command can also control how the search directories propagate to other dependent targets.

  • cmake-commands(7) »


link_libraries — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

link_libraries

Link libraries to all targets added later.

link_libraries([item1 [item2 [...]]]
               [[debug|optimized|general] <item>] ...)

Specify libraries or flags to use when linking any targets created later in the current directory or below by commands such as add_executable() or add_library(). See the target_link_libraries() command for meaning of arguments.

Note

The target_link_libraries() command should be preferred whenever possible. Library dependencies are chained automatically, so directory-wide specification of link libraries is rarely needed.

  • cmake-commands(7) »


load_cache — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

load_cache

Load in the values from another project’s CMake cache.

load_cache(pathToCacheFile READ_WITH_PREFIX prefix entry1...)

Reads the cache and store the requested entries in variables with their name prefixed with the given prefix. This only reads the values, and does not create entries in the local project’s cache.

load_cache(pathToCacheFile [EXCLUDE entry1...]
           [INCLUDE_INTERNALS entry1...])

Loads in the values from another cache and store them in the local project’s cache as internal entries. This is useful for a project that depends on another project built in a different tree. EXCLUDE option can be used to provide a list of entries to be excluded. INCLUDE_INTERNALS can be used to provide a list of internal entries to be included. Normally, no internal entries are brought in. Use of this form of the command is strongly discouraged, but it is provided for backward compatibility.

  • cmake-commands(7) »


project — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

project

Set the name of the project.

Synopsis

project(<PROJECT-NAME> [<language-name>...])
project(<PROJECT-NAME>
        [VERSION <major>[.<minor>[.<patch>[.<tweak>]]]]
        [DESCRIPTION <project-description-string>]
        [HOMEPAGE_URL <url-string>]
        [LANGUAGES <language-name>...])

Sets the name of the project, and stores it in the variable PROJECT_NAME. When called from the top-level CMakeLists.txt also stores the project name in the variable CMAKE_PROJECT_NAME.

Also sets the variables

  • PROJECT_SOURCE_DIR, <PROJECT-NAME>_SOURCE_DIR
  • PROJECT_BINARY_DIR, <PROJECT-NAME>_BINARY_DIR

Further variables are set by the optional arguments described in the following. If any of these arguments is not used, then the corresponding variables are set to the empty string.

If the variable CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE exists, the file pointed to by that variable will be included as the last step of the project command.

Options

The options are:

VERSION <version>

Optional; may not be used unless policy CMP0048 is set to NEW.

Takes a <version> argument composed of non-negative integer components, i.e. <major>[.<minor>[.<patch>[.<tweak>]]], and sets the variables

  • PROJECT_VERSION, <PROJECT-NAME>_VERSION
  • PROJECT_VERSION_MAJOR, <PROJECT-NAME>_VERSION_MAJOR
  • PROJECT_VERSION_MINOR, <PROJECT-NAME>_VERSION_MINOR
  • PROJECT_VERSION_PATCH, <PROJECT-NAME>_VERSION_PATCH
  • PROJECT_VERSION_TWEAK, <PROJECT-NAME>_VERSION_TWEAK.

When the project() command is called from the top-level CMakeLists.txt, then the version is also stored in the variable CMAKE_PROJECT_VERSION.

DESCRIPTION <project-description-string>

Optional. Sets the variables

  • PROJECT_DESCRIPTION, <PROJECT-NAME>_DESCRIPTION

to <project-description-string>. It is recommended that this description is a relatively short string, usually no more than a few words.

When the project() command is called from the top-level CMakeLists.txt, then the description is also stored in the variable CMAKE_PROJECT_DESCRIPTION.

HOMEPAGE_URL <url-string>

Optional. Sets the variables

  • PROJECT_HOMEPAGE_URL, <PROJECT-NAME>_HOMEPAGE_URL

to <url-string>, which should be the canonical home URL for the project.

When the project() command is called from the top-level CMakeLists.txt, then the URL also is stored in the variable CMAKE_PROJECT_HOMEPAGE_URL.

LANGUAGES <language-name>...

Optional. Can also be specified without LANGUAGES keyword per the first, short signature.

Selects which programming languages are needed to build the project. Supported languages include C, CXX (i.e. C++), CUDA, Fortran, and ASM. By default C and CXX are enabled if no language options are given. Specify language NONE, or use the LANGUAGES keyword and list no languages, to skip enabling any languages.

If enabling ASM, list it last so that CMake can check whether compilers for other languages like C work for assembly too.

The variables set through the VERSION, DESCRIPTION and HOMEPAGE_URL options are intended for use as default values in package metadata and documentation.

Usage

The top-level CMakeLists.txt file for a project must contain a literal, direct call to the project() command; loading one through the include() command is not sufficient. If no such call exists CMake will implicitly add one to the top that enables the default languages (C and CXX).

Note

Call the cmake_minimum_required() command at the beginning of the top-level CMakeLists.txt file even before calling the project() command. It is important to establish version and policy settings before invoking other commands whose behavior they may affect. See also policy CMP0000.

  • cmake-commands(7) »


remove_definitions — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

remove_definitions

Remove -D define flags added by add_definitions().

remove_definitions(-DFOO -DBAR ...)

Removes flags (added by add_definitions()) from the compiler command line for sources in the current directory and below.

  • cmake-commands(7) »


set_source_files_properties — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

set_source_files_properties

Source files can have properties that affect how they are built.

set_source_files_properties([file1 [file2 [...]]]
                            PROPERTIES prop1 value1
                            [prop2 value2 [...]])

Sets properties associated with source files using a key/value paired list.

See also the set_property(SOURCE) command.

See Properties on Source Files for the list of properties known to CMake. Source file properties are visible only to targets added in the same directory (CMakeLists.txt).

  • cmake-commands(7) »


set_target_properties — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

set_target_properties

Targets can have properties that affect how they are built.

set_target_properties(target1 target2 ...
                      PROPERTIES prop1 value1
                      prop2 value2 ...)

Sets properties on targets. The syntax for the command is to list all the targets you want to change, and then provide the values you want to set next. You can use any prop value pair you want and extract it later with the get_property() or get_target_property() command.

See also the set_property(TARGET) command.

See Properties on Targets for the list of properties known to CMake.

  • cmake-commands(7) »


set_tests_properties — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

set_tests_properties

Set a property of the tests.

set_tests_properties(test1 [test2...] PROPERTIES prop1 value1 prop2 value2)

Sets a property for the tests. If the test is not found, CMake will report an error. Generator expressions will be expanded the same as supported by the test’s add_test() call.

See also the set_property(TEST) command.

See Properties on Tests for the list of properties known to CMake.

  • cmake-commands(7) »


source_group — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

source_group

Define a grouping for source files in IDE project generation. There are two different signatures to create source groups.

source_group(<name> [FILES <src>...] [REGULAR_EXPRESSION <regex>])
source_group(TREE <root> [PREFIX <prefix>] [FILES <src>...])

Defines a group into which sources will be placed in project files. This is intended to set up file tabs in Visual Studio. The options are:

TREE
CMake will automatically detect, from <src> files paths, source groups it needs to create, to keep structure of source groups analogically to the actual files and directories structure in the project. Paths of <src> files will be cut to be relative to <root>.
PREFIX
Source group and files located directly in <root> path, will be placed in <prefix> source groups.
FILES
Any source file specified explicitly will be placed in group <name>. Relative paths are interpreted with respect to the current source directory.
REGULAR_EXPRESSION
Any source file whose name matches the regular expression will be placed in group <name>.

If a source file matches multiple groups, the last group that explicitly lists the file with FILES will be favored, if any. If no group explicitly lists the file, the last group whose regular expression matches the file will be favored.

The <name> of the group and <prefix> argument may contain backslashes to specify subgroups:

source_group(outer\\inner ...)
source_group(TREE <root> PREFIX sources\\inc ...)

For backwards compatibility, the short-hand signature

source_group(<name> <regex>)

is equivalent to

source_group(<name> REGULAR_EXPRESSION <regex>)

  • cmake-commands(7) »


target_compile_definitions — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

target_compile_definitions

Add compile definitions to a target.

target_compile_definitions(<target>
  <INTERFACE|PUBLIC|PRIVATE> [items1...]
  [<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])

Specifies compile definitions to use when compiling a given <target>. The named <target> must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target.

The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the following arguments. PRIVATE and PUBLIC items will populate the COMPILE_DEFINITIONS property of <target>. PUBLIC and INTERFACE items will populate the INTERFACE_COMPILE_DEFINITIONS property of <target>. (IMPORTED targets only support INTERFACE items.) The following arguments specify compile definitions. Repeated calls for the same <target> append items in the order called.

Arguments to target_compile_definitions may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Any leading -D on an item will be removed. Empty items are ignored. For example, the following are all equivalent:

target_compile_definitions(foo PUBLIC FOO)
target_compile_definitions(foo PUBLIC -DFOO)  # -D removed
target_compile_definitions(foo PUBLIC "" FOO) # "" ignored
target_compile_definitions(foo PUBLIC -D FOO) # -D becomes "", then ignored

  • cmake-commands(7) »


target_compile_features — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

target_compile_features

Add expected compiler features to a target.

target_compile_features(<target> <PRIVATE|PUBLIC|INTERFACE> <feature> [...])

Specifies compiler features required when compiling a given target. If the feature is not listed in the CMAKE_C_COMPILE_FEATURES variable or CMAKE_CXX_COMPILE_FEATURES variable, then an error will be reported by CMake. If the use of the feature requires an additional compiler flag, such as -std=gnu++11, the flag will be added automatically.

The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the features. PRIVATE and PUBLIC items will populate the COMPILE_FEATURES property of <target>. PUBLIC and INTERFACE items will populate the INTERFACE_COMPILE_FEATURES property of <target>. (IMPORTED targets only support INTERFACE items.) Repeated calls for the same <target> append items.

The named <target> must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target.

Arguments to target_compile_features may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

  • cmake-commands(7) »


target_compile_options — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

target_compile_options

Add compile options to a target.

target_compile_options(<target> [BEFORE]
  <INTERFACE|PUBLIC|PRIVATE> [items1...]
  [<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])

Adds options to the COMPILE_OPTIONS or INTERFACE_COMPILE_OPTIONS target properties. These options are used when compiling the given <target>, which must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target.

Arguments

If BEFORE is specified, the content will be prepended to the property instead of being appended.

The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the following arguments. PRIVATE and PUBLIC items will populate the COMPILE_OPTIONS property of <target>. PUBLIC and INTERFACE items will populate the INTERFACE_COMPILE_OPTIONS property of <target>. (IMPORTED targets only support INTERFACE items.) The following arguments specify compile options. Repeated calls for the same <target> append items in the order called.

Arguments to target_compile_options may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

The final set of compile or link options used for a target is constructed by accumulating options from the current target and the usage requirements of it dependencies. The set of options is de-duplicated to avoid repetition. While beneficial for individual options, the de-duplication step can break up option groups. For example, -D A -D B becomes -D A B. One may specify a group of options using shell-like quoting along with a SHELL: prefix. The SHELL: prefix is dropped and the rest of the option string is parsed using the separate_arguments() UNIX_COMMAND mode. For example, "SHELL:-D A" "SHELL:-D B" becomes -D A -D B.

See Also

This command can be used to add any options. However, for adding preprocessor definitions and include directories it is recommended to use the more specific commands target_compile_definitions() and target_include_directories().

For directory-wide settings, there is the command add_compile_options().

  • cmake-commands(7) »


target_include_directories — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

target_include_directories

Add include directories to a target.

target_include_directories(<target> [SYSTEM] [BEFORE]
  <INTERFACE|PUBLIC|PRIVATE> [items1...]
  [<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])

Specifies include directories to use when compiling a given target. The named <target> must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target.

If BEFORE is specified, the content will be prepended to the property instead of being appended.

The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the following arguments. PRIVATE and PUBLIC items will populate the INCLUDE_DIRECTORIES property of <target>. PUBLIC and INTERFACE items will populate the INTERFACE_INCLUDE_DIRECTORIES property of <target>. (IMPORTED targets only support INTERFACE items.) The following arguments specify include directories.

Specified include directories may be absolute paths or relative paths. Repeated calls for the same <target> append items in the order called. If SYSTEM is specified, the compiler will be told the directories are meant as system include directories on some platforms (signalling this setting might achieve effects such as the compiler skipping warnings, or these fixed-install system files not being considered in dependency calculations - see compiler docs). If SYSTEM is used together with PUBLIC or INTERFACE, the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property will be populated with the specified directories.

Arguments to target_include_directories may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Include directories usage requirements commonly differ between the build-tree and the install-tree. The BUILD_INTERFACE and INSTALL_INTERFACE generator expressions can be used to describe separate usage requirements based on the usage location. Relative paths are allowed within the INSTALL_INTERFACE expression and are interpreted relative to the installation prefix. For example:

target_include_directories(mylib PUBLIC
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include/mylib>
  $<INSTALL_INTERFACE:include/mylib>  # <prefix>/include/mylib
)

Creating Relocatable Packages

Note that it is not advisable to populate the INSTALL_INTERFACE of the INTERFACE_INCLUDE_DIRECTORIES of a target with absolute paths to the include directories of dependencies. That would hard-code into installed packages the include directory paths for dependencies as found on the machine the package was made on.

The INSTALL_INTERFACE of the INTERFACE_INCLUDE_DIRECTORIES is only suitable for specifying the required include directories for headers provided with the target itself, not those provided by the transitive dependencies listed in its INTERFACE_LINK_LIBRARIES target property. Those dependencies should themselves be targets that specify their own header locations in INTERFACE_INCLUDE_DIRECTORIES.

See the Creating Relocatable Packages section of the cmake-packages(7) manual for discussion of additional care that must be taken when specifying usage requirements while creating packages for redistribution.

  • cmake-commands(7) »


target_link_directories — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

target_link_directories

Add link directories to a target.

target_link_directories(<target> [BEFORE]
  <INTERFACE|PUBLIC|PRIVATE> [items1...]
  [<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])

Specifies the paths in which the linker should search for libraries when linking a given target. Each item can be an absolute or relative path, with the latter being interpreted as relative to the current source directory. These items will be added to the link command.

The named <target> must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target.

The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the items that follow them. PRIVATE and PUBLIC items will populate the LINK_DIRECTORIES property of <target>. PUBLIC and INTERFACE items will populate the INTERFACE_LINK_DIRECTORIES property of <target> (IMPORTED targets only support INTERFACE items). Each item specifies a link directory and will be converted to an absolute path if necessary before adding it to the relevant property. Repeated calls for the same <target> append items in the order called.

If BEFORE is specified, the content will be prepended to the relevant property instead of being appended.

Arguments to target_link_directories may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Note

This command is rarely necessary and should be avoided where there are other choices. Prefer to pass full absolute paths to libraries where possible, since this ensures the correct library will always be linked. The find_library() command provides the full path, which can generally be used directly in calls to target_link_libraries(). Situations where a library search path may be needed include:

  • Project generators like Xcode where the user can switch target architecture at build time, but a full path to a library cannot be used because it only provides one architecture (i.e. it is not a universal binary).
  • Libraries may themselves have other private library dependencies that expect to be found via RPATH mechanisms, but some linkers are not able to fully decode those paths (e.g. due to the presence of things like $ORIGIN).

  • cmake-commands(7) »


target_link_libraries — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

target_link_libraries

Contents

  • target_link_libraries
    • Overview
    • Libraries for a Target and/or its Dependents
    • Libraries for both a Target and its Dependents
    • Libraries for a Target and/or its Dependents (Legacy)
    • Libraries for Dependents Only (Legacy)
    • Linking Object Libraries
    • Cyclic Dependencies of Static Libraries
    • Creating Relocatable Packages

Specify libraries or flags to use when linking a given target and/or its dependents. Usage requirements from linked library targets will be propagated. Usage requirements of a target’s dependencies affect compilation of its own sources.

Overview

This command has several signatures as detailed in subsections below. All of them have the general form

target_link_libraries(<target> ... <item>... ...)

The named <target> must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target. If policy CMP0079 is not set to NEW then the target must have been created in the current directory. Repeated calls for the same <target> append items in the order called.

Each <item> may be:

  • A library target name: The generated link line will have the full path to the linkable library file associated with the target. The buildsystem will have a dependency to re-link <target> if the library file changes.

    The named target must be created by add_library() within the project or as an IMPORTED library. If it is created within the project an ordering dependency will automatically be added in the build system to make sure the named library target is up-to-date before the <target> links.

    If an imported library has the IMPORTED_NO_SONAME target property set, CMake may ask the linker to search for the library instead of using the full path (e.g. /usr/lib/libfoo.so becomes -lfoo).

    The full path to the target’s artifact will be quoted/escaped for the shell automatically.

  • A full path to a library file: The generated link line will normally preserve the full path to the file. The buildsystem will have a dependency to re-link <target> if the library file changes.

    There are some cases where CMake may ask the linker to search for the library (e.g. /usr/lib/libfoo.so becomes -lfoo), such as when a shared library is detected to have no SONAME field. See policy CMP0060 for discussion of another case.

    If the library file is in a Mac OSX framework, the Headers directory of the framework will also be processed as a usage requirement. This has the same effect as passing the framework directory as an include directory.

    On Visual Studio Generators for VS 2010 and above, library files ending in .targets will be treated as MSBuild targets files and imported into generated project files. This is not supported by other generators.

    The full path to the library file will be quoted/escaped for the shell automatically.

  • A plain library name: The generated link line will ask the linker to search for the library (e.g. foo becomes -lfoo or foo.lib).

    The library name/flag is treated as a command-line string fragment and will be used with no extra quoting or escaping.

  • A link flag: Item names starting with -, but not -l or -framework, are treated as linker flags. Note that such flags will be treated like any other library link item for purposes of transitive dependencies, so they are generally safe to specify only as private link items that will not propagate to dependents.

    Link flags specified here are inserted into the link command in the same place as the link libraries. This might not be correct, depending on the linker. Use the LINK_OPTIONS target property or target_link_options() command to add link flags explicitly. The flags will then be placed at the toolchain-defined flag position in the link command.

    The link flag is treated as a command-line string fragment and will be used with no extra quoting or escaping.

  • A generator expression: A $<...> generator expression may evaluate to any of the above items or to a semicolon-separated list of them. If the ... contains any ; characters, e.g. after evaluation of a ${list} variable, be sure to use an explicitly quoted argument "$<...>" so that this command receives it as a single <item>.

    Additionally, a generator expression may be used as a fragment of any of the above items, e.g. foo$<1:_d>.

    Note that generator expressions will not be used in OLD handling of policy CMP0003 or policy CMP0004.

  • A debug, optimized, or general keyword immediately followed by another <item>. The item following such a keyword will be used only for the corresponding build configuration. The debug keyword corresponds to the Debug configuration (or to configurations named in the DEBUG_CONFIGURATIONS global property if it is set). The optimized keyword corresponds to all other configurations. The general keyword corresponds to all configurations, and is purely optional. Higher granularity may be achieved for per-configuration rules by creating and linking to IMPORTED library targets. These keywords are interpreted immediately by this command and therefore have no special meaning when produced by a generator expression.

Items containing ::, such as Foo::Bar, are assumed to be IMPORTED or ALIAS library target names and will cause an error if no such target exists. See policy CMP0028.

See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Libraries for a Target and/or its Dependents

target_link_libraries(<target>
                      <PRIVATE|PUBLIC|INTERFACE> <item>...
                     [<PRIVATE|PUBLIC|INTERFACE> <item>...]...)

The PUBLIC, PRIVATE and INTERFACE keywords can be used to specify both the link dependencies and the link interface in one command. Libraries and targets following PUBLIC are linked to, and are made part of the link interface. Libraries and targets following PRIVATE are linked to, but are not made part of the link interface. Libraries following INTERFACE are appended to the link interface and are not used for linking <target>.

Libraries for both a Target and its Dependents

target_link_libraries(<target> <item>...)

Library dependencies are transitive by default with this signature. When this target is linked into another target then the libraries linked to this target will appear on the link line for the other target too. This transitive “link interface” is stored in the INTERFACE_LINK_LIBRARIES target property and may be overridden by setting the property directly. When CMP0022 is not set to NEW, transitive linking is built in but may be overridden by the LINK_INTERFACE_LIBRARIES property. Calls to other signatures of this command may set the property making any libraries linked exclusively by this signature private.

Libraries for a Target and/or its Dependents (Legacy)

target_link_libraries(<target>
                      <LINK_PRIVATE|LINK_PUBLIC> <lib>...
                     [<LINK_PRIVATE|LINK_PUBLIC> <lib>...]...)

The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify both the link dependencies and the link interface in one command.

This signature is for compatibility only. Prefer the PUBLIC or PRIVATE keywords instead.

Libraries and targets following LINK_PUBLIC are linked to, and are made part of the INTERFACE_LINK_LIBRARIES. If policy CMP0022 is not NEW, they are also made part of the LINK_INTERFACE_LIBRARIES. Libraries and targets following LINK_PRIVATE are linked to, but are not made part of the INTERFACE_LINK_LIBRARIES (or LINK_INTERFACE_LIBRARIES).

Libraries for Dependents Only (Legacy)

target_link_libraries(<target> LINK_INTERFACE_LIBRARIES <item>...)

The LINK_INTERFACE_LIBRARIES mode appends the libraries to the INTERFACE_LINK_LIBRARIES target property instead of using them for linking. If policy CMP0022 is not NEW, then this mode also appends libraries to the LINK_INTERFACE_LIBRARIES and its per-configuration equivalent.

This signature is for compatibility only. Prefer the INTERFACE mode instead.

Libraries specified as debug are wrapped in a generator expression to correspond to debug builds. If policy CMP0022 is not NEW, the libraries are also appended to the LINK_INTERFACE_LIBRARIES_DEBUG property (or to the properties corresponding to configurations listed in the DEBUG_CONFIGURATIONS global property if it is set). Libraries specified as optimized are appended to the INTERFACE_LINK_LIBRARIES property. If policy CMP0022 is not NEW, they are also appended to the LINK_INTERFACE_LIBRARIES property. Libraries specified as general (or without any keyword) are treated as if specified for both debug and optimized.

Linking Object Libraries

Object Libraries may be used as the <target> (first) argument of target_link_libraries to specify dependencies of their sources on other libraries. For example, the code

add_library(A SHARED a.c)
target_compile_definitions(A PUBLIC A)

add_library(obj OBJECT obj.c)
target_compile_definitions(obj PUBLIC OBJ)
target_link_libraries(obj PUBLIC A)

compiles obj.c with -DA -DOBJ and establishes usage requirements for obj that propagate to its dependents.

Normal libraries and executables may link to Object Libraries to get their objects and usage requirements. Continuing the above example, the code

add_library(B SHARED b.c)
target_link_libraries(B PUBLIC obj)

compiles b.c with -DA -DOBJ, creates shared library B with object files from b.c and obj.c, and links B to A. Furthermore, the code

add_executable(main main.c)
target_link_libraries(main B)

compiles main.c with -DA -DOBJ and links executable main to B and A. The object library’s usage requirements are propagated transitively through B, but its object files are not.

Object Libraries may “link” to other object libraries to get usage requirements, but since they do not have a link step nothing is done with their object files. Continuing from the above example, the code:

add_library(obj2 OBJECT obj2.c)
target_link_libraries(obj2 PUBLIC obj)

add_executable(main2 main2.c)
target_link_libraries(main2 obj2)

compiles obj2.c with -DA -DOBJ, creates executable main2 with object files from main2.c and obj2.c, and links main2 to A.

In other words, when Object Libraries appear in a target’s INTERFACE_LINK_LIBRARIES property they will be treated as Interface Libraries, but when they appear in a target’s LINK_LIBRARIES property their object files will be included in the link too.

Cyclic Dependencies of Static Libraries

The library dependency graph is normally acyclic (a DAG), but in the case of mutually-dependent STATIC libraries CMake allows the graph to contain cycles (strongly connected components). When another target links to one of the libraries, CMake repeats the entire connected component. For example, the code

add_library(A STATIC a.c)
add_library(B STATIC b.c)
target_link_libraries(A B)
target_link_libraries(B A)
add_executable(main main.c)
target_link_libraries(main A)

links main to A B A B. While one repetition is usually sufficient, pathological object file and symbol arrangements can require more. One may handle such cases by using the LINK_INTERFACE_MULTIPLICITY target property or by manually repeating the component in the last target_link_libraries call. However, if two archives are really so interdependent they should probably be combined into a single archive, perhaps by using Object Libraries.

Creating Relocatable Packages

Note that it is not advisable to populate the INTERFACE_LINK_LIBRARIES of a target with absolute paths to dependencies. That would hard-code into installed packages the library file paths for dependencies as found on the machine the package was made on.

See the Creating Relocatable Packages section of the cmake-packages(7) manual for discussion of additional care that must be taken when specifying usage requirements while creating packages for redistribution.

  • cmake-commands(7) »


target_link_options — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

target_link_options

Add link options to a target.

target_link_options(<target> [BEFORE]
  <INTERFACE|PUBLIC|PRIVATE> [items1...]
  [<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])

Specifies link options to use when linking a given target. The named <target> must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target.

If BEFORE is specified, the content will be prepended to the property instead of being appended.

This command can be used to add any options, but alternative commands exist to add libraries ( target_link_libraries() and link_libraries()). See documentation of the directory and target LINK_OPTIONS properties.

The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the following arguments. PRIVATE and PUBLIC items will populate the LINK_OPTIONS property of <target>. PUBLIC and INTERFACE items will populate the INTERFACE_LINK_OPTIONS property of <target>. (IMPORTED targets only support INTERFACE items.) The following arguments specify link options. Repeated calls for the same <target> append items in the order called.

Arguments to target_link_options may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

The final set of compile or link options used for a target is constructed by accumulating options from the current target and the usage requirements of it dependencies. The set of options is de-duplicated to avoid repetition. While beneficial for individual options, the de-duplication step can break up option groups. For example, -D A -D B becomes -D A B. One may specify a group of options using shell-like quoting along with a SHELL: prefix. The SHELL: prefix is dropped and the rest of the option string is parsed using the separate_arguments() UNIX_COMMAND mode. For example, "SHELL:-D A" "SHELL:-D B" becomes -D A -D B.

To pass options to the linker tool, each compiler driver has is own syntax. The LINKER: prefix can be used to specify, in a portable way, options to pass to the linker tool. The LINKER: prefix is replaced by the required driver option and the rest of the option string defines linker arguments using , as separator. These arguments will be formatted according to 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 alternate syntax, specification of arguments using SHELL: prefix and space as separator. Previous example becomes "LINKER:SHELL:-z defs".

Note

Specifying SHELL: prefix elsewhere than at the beginning of the LINKER: prefix is not supported.

  • cmake-commands(7) »


target_sources — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

target_sources

Add sources to a target.

target_sources(<target>
  <INTERFACE|PUBLIC|PRIVATE> [items1...]
  [<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])

Specifies sources to use when compiling a given target. Relative source file paths are interpreted as being relative to the current source directory (i.e. CMAKE_CURRENT_SOURCE_DIR). The named <target> must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target.

The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the following arguments. PRIVATE and PUBLIC items will populate the SOURCES property of <target>. PUBLIC and INTERFACE items will populate the INTERFACE_SOURCES property of <target>. (IMPORTED targets only support INTERFACE items.) The following arguments specify sources. Repeated calls for the same <target> append items in the order called.

Arguments to target_sources may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

See also the CMP0076 policy for older behavior related to the handling of relative source file paths.

  • cmake-commands(7) »


try_compile — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

try_compile

Contents

  • try_compile
    • Try Compiling Whole Projects
    • Try Compiling Source Files
    • Other Behavior Settings

Try building some code.

Try Compiling Whole Projects

try_compile(<resultVar> <bindir> <srcdir>
            <projectName> [<targetName>] [CMAKE_FLAGS <flags>...]
            [OUTPUT_VARIABLE <var>])

Try building a project. The success or failure of the try_compile, i.e. TRUE or FALSE respectively, is returned in <resultVar>.

In this form, <srcdir> should contain a complete CMake project with a CMakeLists.txt file and all sources. The <bindir> and <srcdir> will not be deleted after this command is run. Specify <targetName> to build a specific target instead of the all or ALL_BUILD target. See below for the meaning of other options.

Try Compiling Source Files

try_compile(<resultVar> <bindir> <srcfile|SOURCES srcfile...>
            [CMAKE_FLAGS <flags>...]
            [COMPILE_DEFINITIONS <defs>...]
            [LINK_OPTIONS <options>...]
            [LINK_LIBRARIES <libs>...]
            [OUTPUT_VARIABLE <var>]
            [COPY_FILE <fileName> [COPY_FILE_ERROR <var>]]
            [<LANG>_STANDARD <std>]
            [<LANG>_STANDARD_REQUIRED <bool>]
            [<LANG>_EXTENSIONS <bool>]
            )

Try building an executable or static library from one or more source files (which one is determined by the CMAKE_TRY_COMPILE_TARGET_TYPE variable). The success or failure of the try_compile, i.e. TRUE or FALSE respectively, is returned in <resultVar>.

In this form, one or more source files must be provided. If CMAKE_TRY_COMPILE_TARGET_TYPE is unset or is set to EXECUTABLE, the sources must include a definition for main and CMake will create a CMakeLists.txt file to build the source(s) as an executable. If CMAKE_TRY_COMPILE_TARGET_TYPE is set to STATIC_LIBRARY, a static library will be built instead and no definition for main is required. For an executable, the generated CMakeLists.txt file would contain something like the following:

add_definitions(<expanded COMPILE_DEFINITIONS from caller>)
include_directories(${INCLUDE_DIRECTORIES})
link_directories(${LINK_DIRECTORIES})
add_executable(cmTryCompileExec <srcfile>...)
target_link_options(cmTryCompileExec PRIVATE <LINK_OPTIONS from caller>)
target_link_libraries(cmTryCompileExec ${LINK_LIBRARIES})

The options are:

CMAKE_FLAGS <flags>...
Specify flags of the form -DVAR:TYPE=VALUE to be passed to the cmake command-line used to drive the test build. The above example shows how values for variables INCLUDE_DIRECTORIES, LINK_DIRECTORIES, and LINK_LIBRARIES are used.
COMPILE_DEFINITIONS <defs>...
Specify -Ddefinition arguments to pass to add_definitions() in the generated test project.
COPY_FILE <fileName>
Copy the built executable or static library to the given <fileName>.
COPY_FILE_ERROR <var>
Use after COPY_FILE to capture into variable <var> any error message encountered while trying to copy the file.
LINK_LIBRARIES <libs>...

Specify libraries to be linked in the generated project. The list of libraries may refer to system libraries and to Imported Targets from the calling project.

If this option is specified, any -DLINK_LIBRARIES=... value given to the CMAKE_FLAGS option will be ignored.

LINK_OPTIONS <options>...
Specify link step options to pass to target_link_options() or to set the STATIC_LIBRARY_OPTIONS target property in the generated project, depending on the CMAKE_TRY_COMPILE_TARGET_TYPE variable.
OUTPUT_VARIABLE <var>
Store the output from the build process in the given variable.
<LANG>_STANDARD <std>
Specify the C_STANDARD, CXX_STANDARD, or CUDA_STANDARD target property of the generated project.
<LANG>_STANDARD_REQUIRED <bool>
Specify the C_STANDARD_REQUIRED, CXX_STANDARD_REQUIRED, or CUDA_STANDARD_REQUIRED target property of the generated project.
<LANG>_EXTENSIONS <bool>
Specify the C_EXTENSIONS, CXX_EXTENSIONS, or CUDA_EXTENSIONS target property of the generated project.

In this version all files in <bindir>/CMakeFiles/CMakeTmp will be cleaned automatically. For debugging, --debug-trycompile can be passed to cmake to avoid this clean. However, multiple sequential try_compile operations reuse this single output directory. If you use --debug-trycompile, you can only debug one try_compile call at a time. The recommended procedure is to protect all try_compile calls in your project by if(NOT DEFINED <resultVar>) logic, configure with cmake all the way through once, then delete the cache entry associated with the try_compile call of interest, and then re-run cmake again with --debug-trycompile.

Other Behavior Settings

If set, the following variables are passed in to the generated try_compile CMakeLists.txt to initialize compile target properties with default values:

  • CMAKE_ENABLE_EXPORTS
  • CMAKE_LINK_SEARCH_START_STATIC
  • CMAKE_LINK_SEARCH_END_STATIC
  • CMAKE_POSITION_INDEPENDENT_CODE

If CMP0056 is set to NEW, then CMAKE_EXE_LINKER_FLAGS is passed in as well.

If CMP0083 is set to NEW, then in order to obtain correct behavior at link time, the check_pie_supported() command from the CheckPIESupported module must be called before using the try_compile() command.

The current settings of CMP0065 and CMP0083 are propagated through to the generated test project.

Set the CMAKE_TRY_COMPILE_CONFIGURATION variable to choose a build configuration.

Set the CMAKE_TRY_COMPILE_TARGET_TYPE variable to specify the type of target used for the source file signature.

Set the CMAKE_TRY_COMPILE_PLATFORM_VARIABLES variable to specify variables that must be propagated into the test project. This variable is meant for use only in toolchain files and is only honored by the try_compile() command for the source files form, not when given a whole project.

If CMP0067 is set to NEW, or any of the <LANG>_STANDARD, <LANG>_STANDARD_REQUIRED, or <LANG>_EXTENSIONS options are used, then the language standard variables are honored:

  • CMAKE_C_STANDARD
  • CMAKE_C_STANDARD_REQUIRED
  • CMAKE_C_EXTENSIONS
  • CMAKE_CXX_STANDARD
  • CMAKE_CXX_STANDARD_REQUIRED
  • CMAKE_CXX_EXTENSIONS
  • CMAKE_CUDA_STANDARD
  • CMAKE_CUDA_STANDARD_REQUIRED
  • CMAKE_CUDA_EXTENSIONS

Their values are used to set the corresponding target properties in the generated project (unless overridden by an explicit option).

For the Green Hills MULTI generator the GHS toolset and target system customization cache variables are also propagated into the test project.

  • cmake-commands(7) »


try_run — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

try_run

Contents

  • try_run
    • Try Compiling and Running Source Files
    • Other Behavior Settings
    • Behavior when Cross Compiling

Try compiling and then running some code.

Try Compiling and Running Source Files

try_run(<runResultVar> <compileResultVar>
        <bindir> <srcfile> [CMAKE_FLAGS <flags>...]
        [COMPILE_DEFINITIONS <defs>...]
        [LINK_OPTIONS <options>...]
        [LINK_LIBRARIES <libs>...]
        [COMPILE_OUTPUT_VARIABLE <var>]
        [RUN_OUTPUT_VARIABLE <var>]
        [OUTPUT_VARIABLE <var>]
        [ARGS <args>...])

Try compiling a <srcfile>. Returns TRUE or FALSE for success or failure in <compileResultVar>. If the compile succeeded, runs the executable and returns its exit code in <runResultVar>. If the executable was built, but failed to run, then <runResultVar> will be set to FAILED_TO_RUN. See the try_compile() command for information on how the test project is constructed to build the source file.

The options are:

CMAKE_FLAGS <flags>...
Specify flags of the form -DVAR:TYPE=VALUE to be passed to the cmake command-line used to drive the test build. The example in try_compile() shows how values for variables INCLUDE_DIRECTORIES, LINK_DIRECTORIES, and LINK_LIBRARIES are used.
COMPILE_DEFINITIONS <defs>...
Specify -Ddefinition arguments to pass to add_definitions() in the generated test project.
COMPILE_OUTPUT_VARIABLE <var>
Report the compile step build output in a given variable.
LINK_LIBRARIES <libs>...

Specify libraries to be linked in the generated project. The list of libraries may refer to system libraries and to Imported Targets from the calling project.

If this option is specified, any -DLINK_LIBRARIES=... value given to the CMAKE_FLAGS option will be ignored.

LINK_OPTIONS <options>...
Specify link step options to pass to target_link_options() in the generated project.
OUTPUT_VARIABLE <var>
Report the compile build output and the output from running the executable in the given variable. This option exists for legacy reasons. Prefer COMPILE_OUTPUT_VARIABLE and RUN_OUTPUT_VARIABLE instead.
RUN_OUTPUT_VARIABLE <var>
Report the output from running the executable in a given variable.

Other Behavior Settings

Set the CMAKE_TRY_COMPILE_CONFIGURATION variable to choose a build configuration.

Behavior when Cross Compiling

When cross compiling, the executable compiled in the first step usually cannot be run on the build host. The try_run command checks the CMAKE_CROSSCOMPILING variable to detect whether CMake is in cross-compiling mode. If that is the case, it will still try to compile the executable, but it will not try to run the executable unless the CMAKE_CROSSCOMPILING_EMULATOR variable is set. Instead it will create cache variables which must be filled by the user or by presetting them in some CMake script file to the values the executable would have produced if it had been run on its actual target platform. These cache entries are:

<runResultVar>
Exit code if the executable were to be run on the target platform.
<runResultVar>__TRYRUN_OUTPUT
Output from stdout and stderr if the executable were to be run on the target platform. This is created only if the RUN_OUTPUT_VARIABLE or OUTPUT_VARIABLE option was used.

In order to make cross compiling your project easier, use try_run only if really required. If you use try_run, use the RUN_OUTPUT_VARIABLE or OUTPUT_VARIABLE options only if really required. Using them will require that when cross-compiling, the cache variables will have to be set manually to the output of the executable. You can also “guard” the calls to try_run with an if() block checking the CMAKE_CROSSCOMPILING variable and provide an easy-to-preset alternative for this case.

  • cmake-commands(7) »


ctest_build — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_build

Perform the CTest Build Step as a Dashboard Client.

ctest_build([BUILD <build-dir>] [APPEND]
            [CONFIGURATION <config>]
            [FLAGS <flags>]
            [PROJECT_NAME <project-name>]
            [TARGET <target-name>]
            [NUMBER_ERRORS <num-err-var>]
            [NUMBER_WARNINGS <num-warn-var>]
            [RETURN_VALUE <result-var>]
            [CAPTURE_CMAKE_ERROR <result-var>]
            )

Build the project and store results in Build.xml for submission with the ctest_submit() command.

The CTEST_BUILD_COMMAND variable may be set to explicitly specify the build command line. Otherwise the build command line is computed automatically based on the options given.

The options are:

BUILD <build-dir>
Specify the top-level build directory. If not given, the CTEST_BINARY_DIRECTORY variable is used.
APPEND
Mark Build.xml for append to results previously submitted to a dashboard server since the last ctest_start() call. Append semantics are defined by the dashboard server in use. This does not cause results to be appended to a .xml file produced by a previous call to this command.
CONFIGURATION <config>
Specify the build configuration (e.g. Debug). If not specified the CTEST_BUILD_CONFIGURATION variable will be checked. Otherwise the -C <cfg> option given to the ctest(1) command will be used, if any.
FLAGS <flags>
Pass additional arguments to the underlying build command. If not specified the CTEST_BUILD_FLAGS variable will be checked. This can, e.g., be used to trigger a parallel build using the -j option of make. See the ProcessorCount module for an example.
PROJECT_NAME <project-name>
Ignored. This was once used but is no longer needed.
TARGET <target-name>
Specify the name of a target to build. If not specified the CTEST_BUILD_TARGET variable will be checked. Otherwise the default target will be built. This is the “all” target (called ALL_BUILD in Visual Studio Generators).
NUMBER_ERRORS <num-err-var>
Store the number of build errors detected in the given variable.
NUMBER_WARNINGS <num-warn-var>
Store the number of build warnings detected in the given variable.
RETURN_VALUE <result-var>
Store the return value of the native build tool in the given variable.
CAPTURE_CMAKE_ERROR <result-var>
Store in the <result-var> variable -1 if there are any errors running the command and prevent ctest from returning non-zero if an error occurs.
QUIET
Suppress any CTest-specific non-error output that would have been printed to the console otherwise. The summary of warnings / errors, as well as the output from the native build tool is unaffected by this option.

  • cmake-commands(7) »


ctest_configure — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_configure

Perform the CTest Configure Step as a Dashboard Client.

ctest_configure([BUILD <build-dir>] [SOURCE <source-dir>] [APPEND]
                [OPTIONS <options>] [RETURN_VALUE <result-var>] [QUIET]
                [CAPTURE_CMAKE_ERROR <result-var>])

Configure the project build tree and record results in Configure.xml for submission with the ctest_submit() command.

The options are:

BUILD <build-dir>
Specify the top-level build directory. If not given, the CTEST_BINARY_DIRECTORY variable is used.
SOURCE <source-dir>
Specify the source directory. If not given, the CTEST_SOURCE_DIRECTORY variable is used.
APPEND
Mark Configure.xml for append to results previously submitted to a dashboard server since the last ctest_start() call. Append semantics are defined by the dashboard server in use. This does not cause results to be appended to a .xml file produced by a previous call to this command.
OPTIONS <options>
Specify command-line arguments to pass to the configuration tool.
RETURN_VALUE <result-var>
Store in the <result-var> variable the return value of the native configuration tool.
CAPTURE_CMAKE_ERROR <result-var>
Store in the <result-var> variable -1 if there are any errors running the command and prevent ctest from returning non-zero if an error occurs.
QUIET
Suppress any CTest-specific non-error messages that would have otherwise been printed to the console. Output from the underlying configure command is not affected.

  • cmake-commands(7) »


ctest_coverage — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_coverage

Perform the CTest Coverage Step as a Dashboard Client.

ctest_coverage([BUILD <build-dir>] [APPEND]
               [LABELS <label>...]
               [RETURN_VALUE <result-var>]
               [CAPTURE_CMAKE_ERROR <result-var]
               [QUIET]
               )

Collect coverage tool results and stores them in Coverage.xml for submission with the ctest_submit() command.

The options are:

BUILD <build-dir>
Specify the top-level build directory. If not given, the CTEST_BINARY_DIRECTORY variable is used.
APPEND
Mark Coverage.xml for append to results previously submitted to a dashboard server since the last ctest_start() call. Append semantics are defined by the dashboard server in use. This does not cause results to be appended to a .xml file produced by a previous call to this command.
LABELS
Filter the coverage report to include only source files labeled with at least one of the labels specified.
RETURN_VALUE <result-var>
Store in the <result-var> variable 0 if coverage tools ran without error and non-zero otherwise.
CAPTURE_CMAKE_ERROR <result-var>
Store in the <result-var> variable -1 if there are any errors running the command and prevent ctest from returning non-zero if an error occurs.
QUIET
Suppress any CTest-specific non-error output that would have been printed to the console otherwise. The summary indicating how many lines of code were covered is unaffected by this option.

  • cmake-commands(7) »


ctest_empty_binary_directory — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_empty_binary_directory

empties the binary directory

ctest_empty_binary_directory( directory )

Removes a binary directory. This command will perform some checks prior to deleting the directory in an attempt to avoid malicious or accidental directory deletion.

  • cmake-commands(7) »


ctest_memcheck — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_memcheck

Perform the CTest MemCheck Step as a Dashboard Client.

ctest_memcheck([BUILD <build-dir>] [APPEND]
               [START <start-number>]
               [END <end-number>]
               [STRIDE <stride-number>]
               [EXCLUDE <exclude-regex>]
               [INCLUDE <include-regex>]
               [EXCLUDE_LABEL <label-exclude-regex>]
               [INCLUDE_LABEL <label-include-regex>]
               [EXCLUDE_FIXTURE <regex>]
               [EXCLUDE_FIXTURE_SETUP <regex>]
               [EXCLUDE_FIXTURE_CLEANUP <regex>]
               [PARALLEL_LEVEL <level>]
               [TEST_LOAD <threshold>]
               [SCHEDULE_RANDOM <ON|OFF>]
               [STOP_TIME <time-of-day>]
               [RETURN_VALUE <result-var>]
               [DEFECT_COUNT <defect-count-var>]
               [QUIET]
               )

Run tests with a dynamic analysis tool and store results in MemCheck.xml for submission with the ctest_submit() command.

Most options are the same as those for the ctest_test() command.

The options unique to this command are:

DEFECT_COUNT <defect-count-var>
Store in the <defect-count-var> the number of defects found.

  • cmake-commands(7) »


ctest_read_custom_files — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_read_custom_files

read CTestCustom files.

ctest_read_custom_files( directory ... )

Read all the CTestCustom.ctest or CTestCustom.cmake files from the given directory.

By default, invoking ctest(1) without a script will read custom files from the binary directory.

  • cmake-commands(7) »


ctest_run_script — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_run_script

runs a ctest -S script

ctest_run_script([NEW_PROCESS] script_file_name script_file_name1
            script_file_name2 ... [RETURN_VALUE var])

Runs a script or scripts much like if it was run from ctest -S. If no argument is provided then the current script is run using the current settings of the variables. If NEW_PROCESS is specified then each script will be run in a separate process.If RETURN_VALUE is specified the return value of the last script run will be put into var.

  • cmake-commands(7) »


ctest_sleep — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_sleep

sleeps for some amount of time

ctest_sleep(<seconds>)

Sleep for given number of seconds.

ctest_sleep(<time1> <duration> <time2>)

Sleep for t=(time1 + duration - time2) seconds if t > 0.

  • cmake-commands(7) »


ctest_start — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_start

Starts the testing for a given model

ctest_start(<model> [<source> [<binary>]] [TRACK <track>] [QUIET])

ctest_start([<model> [<source> [<binary>]]] [TRACK <track>] APPEND [QUIET])

Starts the testing for a given model. The command should be called after the binary directory is initialized.

The parameters are as follows:

<model>
Set the dashboard model. Must be one of Experimental, Continuous, or Nightly. This parameter is required unless APPEND is specified.
<source>
Set the source directory. If not specified, the value of CTEST_SOURCE_DIRECTORY is used instead.
<binary>
Set the binary directory. If not specified, the value of CTEST_BINARY_DIRECTORY is used instead.
TRACK <track>
If TRACK is used, the submissions will go to the specified track on the CDash server. If no TRACK is specified, the name of the model is used by default.
APPEND

If APPEND is used, the existing TAG is used rather than creating a new one based on the current time stamp. If you use APPEND, you can omit the <model> and TRACK <track> parameters, because they will be read from the generated TAG file. For example:

ctest_start(Experimental TRACK TrackExperimental)

Later, in another ctest -S script:

ctest_start(APPEND)

When the second script runs ctest_start(APPEND), it will read the Experimental model and TrackExperimental track from the TAG file generated by the first ctest_start() command. Please note that if you call ctest_start(APPEND) and specify a different model or track than in the first ctest_start() command, a warning will be issued, and the new model and track will be used.

QUIET
If QUIET is used, CTest will suppress any non-error messages that it otherwise would have printed to the console.

The parameters for ctest_start() can be issued in any order, with the exception that <model>, <source>, and <binary> have to appear in that order with respect to each other. The following are all valid and equivalent:

ctest_start(Experimental path/to/source path/to/binary TRACK SomeTrack QUIET APPEND)

ctest_start(TRACK SomeTrack Experimental QUIET path/to/source APPEND path/to/binary)

ctest_start(APPEND QUIET Experimental path/to/source TRACK SomeTrack path/to/binary)

However, for the sake of readability, it is recommended that you order your parameters in the order listed at the top of this page.

If the CTEST_CHECKOUT_COMMAND variable (or the CTEST_CVS_CHECKOUT variable) is set, its content is treated as command-line. The command is invoked with the current working directory set to the parent of the source directory, even if the source directory already exists. This can be used to create the source tree from a version control repository.

  • cmake-commands(7) »


ctest_submit — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_submit

Perform the CTest Submit Step as a Dashboard Client.

ctest_submit([PARTS <part>...] [FILES <file>...]
             [SUBMIT_URL <url>]
             [HTTPHEADER <header>]
             [RETRY_COUNT <count>]
             [RETRY_DELAY <delay>]
             [RETURN_VALUE <result-var>]
             [CAPTURE_CMAKE_ERROR <result-var>]
             [QUIET]
             )

Submit results to a dashboard server. By default all available parts are submitted.

The options are:

PARTS <part>...

Specify a subset of parts to submit. Valid part names are:

Start      = nothing
Update     = ctest_update results, in Update.xml
Configure  = ctest_configure results, in Configure.xml
Build      = ctest_build results, in Build.xml
Test       = ctest_test results, in Test.xml
Coverage   = ctest_coverage results, in Coverage.xml
MemCheck   = ctest_memcheck results, in DynamicAnalysis.xml
Notes      = Files listed by CTEST_NOTES_FILES, in Notes.xml
ExtraFiles = Files listed by CTEST_EXTRA_SUBMIT_FILES
Upload     = Files prepared for upload by ctest_upload(), in Upload.xml
Submit     = nothing
Done       = Build is complete, in Done.xml
FILES <file>...
Specify an explicit list of specific files to be submitted. Each individual file must exist at the time of the call.
SUBMIT_URL <url>
The http or https URL of the dashboard server to send the submission to. If not given, the CTEST_SUBMIT_URL variable is used.
HTTPHEADER <HTTP-header>
Specify HTTP header to be included in the request to CDash during submission. This suboption can be repeated several times.
RETRY_COUNT <count>
Specify how many times to retry a timed-out submission.
RETRY_DELAY <delay>
Specify how long (in seconds) to wait after a timed-out submission before attempting to re-submit.
RETURN_VALUE <result-var>
Store in the <result-var> variable 0 for success and non-zero on failure.
CAPTURE_CMAKE_ERROR <result-var>
Store in the <result-var> variable -1 if there are any errors running the command and prevent ctest from returning non-zero if an error occurs.
QUIET
Suppress all non-error messages that would have otherwise been printed to the console.

Submit to CDash Upload API

ctest_submit(CDASH_UPLOAD <file> [CDASH_UPLOAD_TYPE <type>]
             [SUBMIT_URL <url>]
             [HTTPHEADER <header>]
             [RETRY_COUNT <count>]
             [RETRY_DELAY <delay>]
             [RETURN_VALUE <result-var>]
             [QUIET])

This second signature is used to upload files to CDash via the CDash file upload API. The API first sends a request to upload to CDash along with a content hash of the file. If CDash does not already have the file, then it is uploaded. Along with the file, a CDash type string is specified to tell CDash which handler to use to process the data.

This signature accepts the SUBMIT_URL, HTTPHEADER, RETRY_COUNT, RETRY_DELAY, RETURN_VALUE and QUIET options as described above.

  • cmake-commands(7) »


ctest_test — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_test

Perform the CTest Test Step as a Dashboard Client.

ctest_test([BUILD <build-dir>] [APPEND]
           [START <start-number>]
           [END <end-number>]
           [STRIDE <stride-number>]
           [EXCLUDE <exclude-regex>]
           [INCLUDE <include-regex>]
           [EXCLUDE_LABEL <label-exclude-regex>]
           [INCLUDE_LABEL <label-include-regex>]
           [EXCLUDE_FIXTURE <regex>]
           [EXCLUDE_FIXTURE_SETUP <regex>]
           [EXCLUDE_FIXTURE_CLEANUP <regex>]
           [PARALLEL_LEVEL <level>]
           [TEST_LOAD <threshold>]
           [SCHEDULE_RANDOM <ON|OFF>]
           [STOP_TIME <time-of-day>]
           [RETURN_VALUE <result-var>]
           [CAPTURE_CMAKE_ERROR <result-var>]
           [QUIET]
           )

Run tests in the project build tree and store results in Test.xml for submission with the ctest_submit() command.

The options are:

BUILD <build-dir>
Specify the top-level build directory. If not given, the CTEST_BINARY_DIRECTORY variable is used.
APPEND
Mark Test.xml for append to results previously submitted to a dashboard server since the last ctest_start() call. Append semantics are defined by the dashboard server in use. This does not cause results to be appended to a .xml file produced by a previous call to this command.
START <start-number>
Specify the beginning of a range of test numbers.
END <end-number>
Specify the end of a range of test numbers.
STRIDE <stride-number>
Specify the stride by which to step across a range of test numbers.
EXCLUDE <exclude-regex>
Specify a regular expression matching test names to exclude.
INCLUDE <include-regex>
Specify a regular expression matching test names to include. Tests not matching this expression are excluded.
EXCLUDE_LABEL <label-exclude-regex>
Specify a regular expression matching test labels to exclude.
INCLUDE_LABEL <label-include-regex>
Specify a regular expression matching test labels to include. Tests not matching this expression are excluded.
EXCLUDE_FIXTURE <regex>
If a test in the set of tests to be executed requires a particular fixture, that fixture’s setup and cleanup tests would normally be added to the test set automatically. This option prevents adding setup or cleanup tests for fixtures matching the <regex>. Note that all other fixture behavior is retained, including test dependencies and skipping tests that have fixture setup tests that fail.
EXCLUDE_FIXTURE_SETUP <regex>
Same as EXCLUDE_FIXTURE except only matching setup tests are excluded.
EXCLUDE_FIXTURE_CLEANUP <regex>
Same as EXCLUDE_FIXTURE except only matching cleanup tests are excluded.
PARALLEL_LEVEL <level>
Specify a positive number representing the number of tests to be run in parallel.
TEST_LOAD <threshold>
While running tests in parallel, try not to start tests when they may cause the CPU load to pass above a given threshold. If not specified the CTEST_TEST_LOAD variable will be checked, and then the --test-load command-line argument to ctest(1). See also the TestLoad setting in the CTest Test Step.
SCHEDULE_RANDOM <ON|OFF>
Launch tests in a random order. This may be useful for detecting implicit test dependencies.
STOP_TIME <time-of-day>
Specify a time of day at which the tests should all stop running.
RETURN_VALUE <result-var>
Store in the <result-var> variable 0 if all tests passed. Store non-zero if anything went wrong.
CAPTURE_CMAKE_ERROR <result-var>
Store in the <result-var> variable -1 if there are any errors running the command and prevent ctest from returning non-zero if an error occurs.
QUIET
Suppress any CTest-specific non-error messages that would have otherwise been printed to the console. Output from the underlying test command is not affected. Summary info detailing the percentage of passing tests is also unaffected by the QUIET option.

See also the CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE and CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE variables.

  • cmake-commands(7) »


ctest_update — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_update

Perform the CTest Update Step as a Dashboard Client.

ctest_update([SOURCE <source-dir>]
             [RETURN_VALUE <result-var>]
             [CAPTURE_CMAKE_ERROR <result-var>]
             [QUIET])

Update the source tree from version control and record results in Update.xml for submission with the ctest_submit() command.

The options are:

SOURCE <source-dir>
Specify the source directory. If not given, the CTEST_SOURCE_DIRECTORY variable is used.
RETURN_VALUE <result-var>
Store in the <result-var> variable the number of files updated or -1 on error.
CAPTURE_CMAKE_ERROR <result-var>
Store in the <result-var> variable -1 if there are any errors running the command and prevent ctest from returning non-zero if an error occurs.
QUIET
Tell CTest to suppress most non-error messages that it would have otherwise printed to the console. CTest will still report the new revision of the repository and any conflicting files that were found.

The update always follows the version control branch currently checked out in the source directory. See the CTest Update Step documentation for more information.

  • cmake-commands(7) »


ctest_upload — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

ctest_upload

Upload files to a dashboard server as a Dashboard Client.

ctest_upload(FILES <file>... [QUIET] [CAPTURE_CMAKE_ERROR <result-var>])

The options are:

FILES <file>...
Specify a list of files to be sent along with the build results to the dashboard server.
QUIET
Suppress any CTest-specific non-error output that would have been printed to the console otherwise.
CAPTURE_CMAKE_ERROR <result-var>
Store in the <result-var> variable -1 if there are any errors running the command and prevent ctest from returning non-zero if an error occurs.

  • cmake-commands(7) »


build_name — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

build_name

Disallowed since version 3.0. See CMake Policy CMP0036.

Use ${CMAKE_SYSTEM} and ${CMAKE_CXX_COMPILER} instead.

build_name(variable)

Sets the specified variable to a string representing the platform and compiler settings. These values are now available through the CMAKE_SYSTEM and CMAKE_CXX_COMPILER variables.

  • cmake-commands(7) »


exec_program — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

exec_program

Deprecated since version 3.0: Use the execute_process() command instead.

Run an executable program during the processing of the CMakeList.txt file.

exec_program(Executable [directory in which to run]
             [ARGS <arguments to executable>]
             [OUTPUT_VARIABLE <var>]
             [RETURN_VALUE <var>])

The executable is run in the optionally specified directory. The executable can include arguments if it is double quoted, but it is better to use the optional ARGS argument to specify arguments to the program. This is because cmake will then be able to escape spaces in the executable path. An optional argument OUTPUT_VARIABLE specifies a variable in which to store the output. To capture the return value of the execution, provide a RETURN_VALUE. If OUTPUT_VARIABLE is specified, then no output will go to the stdout/stderr of the console running cmake.

  • cmake-commands(7) »


export_library_dependencies — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

export_library_dependencies

Disallowed since version 3.0. See CMake Policy CMP0033.

Use install(EXPORT) or export() command.

This command generates an old-style library dependencies file. Projects requiring CMake 2.6 or later should not use the command. Use instead the install(EXPORT) command to help export targets from an installation tree and the export() command to export targets from a build tree.

The old-style library dependencies file does not take into account per-configuration names of libraries or the LINK_INTERFACE_LIBRARIES target property.

export_library_dependencies(<file> [APPEND])

Create a file named <file> that can be included into a CMake listfile with the INCLUDE command. The file will contain a number of SET commands that will set all the variables needed for library dependency information. This should be the last command in the top level CMakeLists.txt file of the project. If the APPEND option is specified, the SET commands will be appended to the given file instead of replacing it.

  • cmake-commands(7) »


install_files — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

install_files

Deprecated since version 3.0: Use the install(FILES) command instead.

This command has been superceded by the install() command. It is provided for compatibility with older CMake code. The FILES form is directly replaced by the FILES form of the install() command. The regexp form can be expressed more clearly using the GLOB form of the file() command.

install_files(<dir> extension file file ...)

Create rules to install the listed files with the given extension into the given directory. Only files existing in the current source tree or its corresponding location in the binary tree may be listed. If a file specified already has an extension, that extension will be removed first. This is useful for providing lists of source files such as foo.cxx when you want the corresponding foo.h to be installed. A typical extension is ‘.h’.

install_files(<dir> regexp)

Any files in the current source directory that match the regular expression will be installed.

install_files(<dir> FILES file file ...)

Any files listed after the FILES keyword will be installed explicitly from the names given. Full paths are allowed in this form.

The directory <dir> is relative to the installation prefix, which is stored in the variable CMAKE_INSTALL_PREFIX.

  • cmake-commands(7) »


install_programs — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

install_programs

Deprecated since version 3.0: Use the install(PROGRAMS) command instead.

This command has been superceded by the install() command. It is provided for compatibility with older CMake code. The FILES form is directly replaced by the PROGRAMS form of the install() command. The regexp form can be expressed more clearly using the GLOB form of the file() command.

install_programs(<dir> file1 file2 [file3 ...])
install_programs(<dir> FILES file1 [file2 ...])

Create rules to install the listed programs into the given directory. Use the FILES argument to guarantee that the file list version of the command will be used even when there is only one argument.

install_programs(<dir> regexp)

In the second form any program in the current source directory that matches the regular expression will be installed.

This command is intended to install programs that are not built by cmake, such as shell scripts. See the TARGETS form of the install() command to create installation rules for targets built by cmake.

The directory <dir> is relative to the installation prefix, which is stored in the variable CMAKE_INSTALL_PREFIX.

  • cmake-commands(7) »


install_targets — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

install_targets

Deprecated since version 3.0: Use the install(TARGETS) command instead.

This command has been superceded by the install() command. It is provided for compatibility with older CMake code.

install_targets(<dir> [RUNTIME_DIRECTORY dir] target target)

Create rules to install the listed targets into the given directory. The directory <dir> is relative to the installation prefix, which is stored in the variable CMAKE_INSTALL_PREFIX. If RUNTIME_DIRECTORY is specified, then on systems with special runtime files (Windows DLL), the files will be copied to that directory.

  • cmake-commands(7) »


load_command — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

load_command

Disallowed since version 3.0. See CMake Policy CMP0031.

Load a command into a running CMake.

load_command(COMMAND_NAME <loc1> [loc2 ...])

The given locations are searched for a library whose name is cmCOMMAND_NAME. If found, it is loaded as a module and the command is added to the set of available CMake commands. Usually, try_compile() is used before this command to compile the module. If the command is successfully loaded a variable named

CMAKE_LOADED_COMMAND_<COMMAND_NAME>

will be set to the full path of the module that was loaded. Otherwise the variable will not be set.

  • cmake-commands(7) »


make_directory — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

make_directory

Deprecated since version 3.0: Use the file(MAKE_DIRECTORY) command instead.

make_directory(directory)

Creates the specified directory. Full paths should be given. Any parent directories that do not exist will also be created. Use with care.

  • cmake-commands(7) »


output_required_files — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

output_required_files

Disallowed since version 3.0. See CMake Policy CMP0032.

Approximate C preprocessor dependency scanning.

This command exists only because ancient CMake versions provided it. CMake handles preprocessor dependency scanning automatically using a more advanced scanner.

output_required_files(srcfile outputfile)

Outputs a list of all the source files that are required by the specified srcfile. This list is written into outputfile. This is similar to writing out the dependencies for srcfile except that it jumps from .h files into .cxx, .c and .cpp files if possible.

  • cmake-commands(7) »


qt_wrap_cpp — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

qt_wrap_cpp

Deprecated since version 3.14: This command was originally added to support Qt 3 before the add_custom_command() command was sufficiently mature. The FindQt4 module provides the qt4_wrap_cpp() macro, which should be used instead for Qt 4 projects. For projects using Qt 5 or later, use the equivalent macro provided by Qt itself (e.g. Qt 5 provides qt5_wrap_cpp()).

Manually create Qt Wrappers.

qt_wrap_cpp(resultingLibraryName DestName SourceLists ...)

Produces moc files for all the .h files listed in the SourceLists. The moc files will be added to the library using the DestName source list.

Consider updating the project to use the AUTOMOC target property instead for a more automated way of invoking the moc tool.

  • cmake-commands(7) »


qt_wrap_ui — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

qt_wrap_ui

Deprecated since version 3.14: This command was originally added to support Qt 3 before the add_custom_command() command was sufficiently mature. The FindQt4 module provides the qt4_wrap_ui() macro, which should be used instead for Qt 4 projects. For projects using Qt 5 or later, use the equivalent macro provided by Qt itself (e.g. Qt 5 provides qt5_wrap_ui()).

Manually create Qt user interfaces Wrappers.

qt_wrap_ui(resultingLibraryName HeadersDestName
           SourcesDestName SourceLists ...)

Produces .h and .cxx files for all the .ui files listed in the SourceLists. The .h files will be added to the library using the HeadersDestNamesource list. The .cxx files will be added to the library using the SourcesDestNamesource list.

Consider updating the project to use the AUTOUIC target property instead for a more automated way of invoking the uic tool.

  • cmake-commands(7) »


remove — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

remove

Deprecated since version 3.0: Use the list(REMOVE_ITEM) command instead.

remove(VAR VALUE VALUE ...)

Removes VALUE from the variable VAR. This is typically used to remove entries from a vector (e.g. semicolon separated list). VALUE is expanded.

  • cmake-commands(7) »


subdir_depends — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

subdir_depends

Disallowed since version 3.0. See CMake Policy CMP0029.

Does nothing.

subdir_depends(subdir dep1 dep2 ...)

Does not do anything. This command used to help projects order parallel builds correctly. This functionality is now automatic.

  • cmake-commands(7) »


subdirs — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

subdirs

Deprecated since version 3.0: Use the add_subdirectory() command instead.

Add a list of subdirectories to the build.

subdirs(dir1 dir2 ...[EXCLUDE_FROM_ALL exclude_dir1 exclude_dir2 ...]
        [PREORDER] )

Add a list of subdirectories to the build. The add_subdirectory() command should be used instead of subdirs although subdirs will still work. This will cause any CMakeLists.txt files in the sub directories to be processed by CMake. Any directories after the PREORDER flag are traversed first by makefile builds, the PREORDER flag has no effect on IDE projects. Any directories after the EXCLUDE_FROM_ALL marker will not be included in the top level makefile or project file. This is useful for having CMake create makefiles or projects for a set of examples in a project. You would want CMake to generate makefiles or project files for all the examples at the same time, but you would not want them to show up in the top level project or be built each time make is run from the top.

  • cmake-commands(7) »


use_mangled_mesa — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

use_mangled_mesa

Disallowed since version 3.0. See CMake Policy CMP0030.

Copy mesa headers for use in combination with system GL.

use_mangled_mesa(PATH_TO_MESA OUTPUT_DIRECTORY)

The path to mesa includes, should contain gl_mangle.h. The mesa headers are copied to the specified output directory. This allows mangled mesa headers to override other GL headers by being added to the include directory path earlier.

  • cmake-commands(7) »


utility_source — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

utility_source

Disallowed since version 3.0. See CMake Policy CMP0034.

Specify the source tree of a third-party utility.

utility_source(cache_entry executable_name
               path_to_source [file1 file2 ...])

When a third-party utility’s source is included in the distribution, this command specifies its location and name. The cache entry will not be set unless the path_to_source and all listed files exist. It is assumed that the source tree of the utility will have been built before it is needed.

When cross compiling CMake will print a warning if a utility_source() command is executed, because in many cases it is used to build an executable which is executed later on. This doesn’t work when cross compiling, since the executable can run only on their target platform. So in this case the cache entry has to be adjusted manually so it points to an executable which is runnable on the build host.

  • cmake-commands(7) »


variable_requires — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

variable_requires

Disallowed since version 3.0. See CMake Policy CMP0035.

Use the if() command instead.

Assert satisfaction of an option’s required variables.

variable_requires(TEST_VARIABLE RESULT_VARIABLE
                  REQUIRED_VARIABLE1
                  REQUIRED_VARIABLE2 ...)

The first argument (TEST_VARIABLE) is the name of the variable to be tested, if that variable is false nothing else is done. If TEST_VARIABLE is true, then the next argument (RESULT_VARIABLE) is a variable that is set to true if all the required variables are set. The rest of the arguments are variables that must be true or not set to NOTFOUND to avoid an error. If any are not true, an error is reported.

  • cmake-commands(7) »


write_file — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-commands(7) »

write_file

Deprecated since version 3.0: Use the file(WRITE) command instead.

write_file(filename "message to write"... [APPEND])

The first argument is the file name, the rest of the arguments are messages to write. If the argument APPEND is specified, then the message will be appended.

NOTE 1: file(WRITE) and file(APPEND) do exactly the same as this one but add some more functionality.

NOTE 2: When using write_file the produced file cannot be used as an input to CMake (CONFIGURE_FILE, source file …) because it will lead to an infinite loop. Use configure_file() if you want to generate input files to CMake.

  • cmake-commands(7) »


cmake-compile-features(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-compile-features(7)

Contents

  • cmake-compile-features(7)
    • Introduction
    • Compile Feature Requirements
      • Requiring Language Standards
      • Availability of Compiler Extensions
    • Optional Compile Features
    • Conditional Compilation Options
    • Supported Compilers

Introduction

Project source code may depend on, or be conditional on, the availability of certain features of the compiler. There are three use-cases which arise: Compile Feature Requirements, Optional Compile Features and Conditional Compilation Options.

While features are typically specified in programming language standards, CMake provides a primary user interface based on granular handling of the features, not the language standard that introduced the feature.

The CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES global properties contain all the features known to CMake, regardless of compiler support for the feature. The CMAKE_C_COMPILE_FEATURES and CMAKE_CXX_COMPILE_FEATURES variables contain all features CMake knows are known to the compiler, regardless of language standard or compile flags needed to use them.

Features known to CMake are named mostly following the same convention as the Clang feature test macros. The are some exceptions, such as CMake using cxx_final and cxx_override instead of the single cxx_override_control used by Clang.

Compile Feature Requirements

Compile feature requirements may be specified with the target_compile_features() command. For example, if a target must be compiled with compiler support for the cxx_constexpr feature:

add_library(mylib requires_constexpr.cpp)
target_compile_features(mylib PRIVATE cxx_constexpr)

In processing the requirement for the cxx_constexpr feature, cmake(1) will ensure that the in-use C++ compiler is capable of the feature, and will add any necessary flags such as -std=gnu++11 to the compile lines of C++ files in the mylib target. A FATAL_ERROR is issued if the compiler is not capable of the feature.

The exact compile flags and language standard are deliberately not part of the user interface for this use-case. CMake will compute the appropriate compile flags to use by considering the features specified for each target.

Such compile flags are added even if the compiler supports the particular feature without the flag. For example, the GNU compiler supports variadic templates (with a warning) even if -std=gnu++98 is used. CMake adds the -std=gnu++11 flag if cxx_variadic_templates is specified as a requirement.

In the above example, mylib requires cxx_constexpr when it is built itself, but consumers of mylib are not required to use a compiler which supports cxx_constexpr. If the interface of mylib does require the cxx_constexpr feature (or any other known feature), that may be specified with the PUBLIC or INTERFACE signatures of target_compile_features():

add_library(mylib requires_constexpr.cpp)
# cxx_constexpr is a usage-requirement
target_compile_features(mylib PUBLIC cxx_constexpr)

# main.cpp will be compiled with -std=gnu++11 on GNU for cxx_constexpr.
add_executable(myexe main.cpp)
target_link_libraries(myexe mylib)

Feature requirements are evaluated transitively by consuming the link implementation. See cmake-buildsystem(7) for more on transitive behavior of build properties and usage requirements.

Requiring Language Standards

In projects that use a large number of commonly available features from a particular language standard (e.g. C++ 11) one may specify a meta-feature (e.g. cxx_std_11) that requires use of a compiler mode aware of that standard. This is simpler than specifying all the features individually, but does not guarantee the existence of any particular feature. Diagnosis of use of unsupported features will be delayed until compile time.

For example, if C++ 11 features are used extensively in a project’s header files, then clients must use a compiler mode aware of C++ 11 or above. This can be requested with the code:

target_compile_features(mylib PUBLIC cxx_std_11)

In this example, CMake will ensure the compiler is invoked in a mode that is aware of C++ 11 (or above), adding flags such as -std=gnu++11 if necessary. This applies to sources within mylib as well as any dependents (that may include headers from mylib).

Availability of Compiler Extensions

Because the CXX_EXTENSIONS target property is ON by default, CMake uses extended variants of language dialects by default, such as -std=gnu++11 instead of -std=c++11. That target property may be set to OFF to use the non-extended variant of the dialect flag. Note that because most compilers enable extensions by default, this could expose cross-platform bugs in user code or in the headers of third-party dependencies.

Optional Compile Features

Compile features may be preferred if available, without creating a hard requirement. For example, a library may provides alternative implementations depending on whether the cxx_variadic_templates feature is available:

#if Foo_COMPILER_CXX_VARIADIC_TEMPLATES
template<int I, int... Is>
struct Interface;

template<int I>
struct Interface<I>
{
  static int accumulate()
  {
    return I;
  }
};

template<int I, int... Is>
struct Interface
{
  static int accumulate()
  {
    return I + Interface<Is...>::accumulate();
  }
};
#else
template<int I1, int I2 = 0, int I3 = 0, int I4 = 0>
struct Interface
{
  static int accumulate() { return I1 + I2 + I3 + I4; }
};
#endif

Such an interface depends on using the correct preprocessor defines for the compiler features. CMake can generate a header file containing such defines using the WriteCompilerDetectionHeader module. The module contains the write_compiler_detection_header function which accepts parameters to control the content of the generated header file:

write_compiler_detection_header(
  FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
  PREFIX Foo
  COMPILERS GNU
  FEATURES
    cxx_variadic_templates
)

Such a header file may be used internally in the source code of a project, and it may be installed and used in the interface of library code.

For each feature listed in FEATURES, a preprocessor definition is created in the header file, and defined to either 1 or 0.

Additionally, some features call for additional defines, such as the cxx_final and cxx_override features. Rather than being used in #ifdef code, the final keyword is abstracted by a symbol which is defined to either final, a compiler-specific equivalent, or to empty. That way, C++ code can be written to unconditionally use the symbol, and compiler support determines what it is expanded to:

struct Interface {
  virtual void Execute() = 0;
};

struct Concrete Foo_FINAL {
  void Execute() Foo_OVERRIDE;
};

In this case, Foo_FINAL will expand to final if the compiler supports the keyword, or to empty otherwise.

In this use-case, the CMake code will wish to enable a particular language standard if available from the compiler. The CXX_STANDARD target property variable may be set to the desired language standard for a particular target, and the CMAKE_CXX_STANDARD may be set to influence all following targets:

write_compiler_detection_header(
  FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
  PREFIX Foo
  COMPILERS GNU
  FEATURES
    cxx_final cxx_override
)

# Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
# which will expand to 'final' if the compiler supports the requested
# CXX_STANDARD.
add_library(foo foo.cpp)
set_property(TARGET foo PROPERTY CXX_STANDARD 11)

# Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
# which will expand to 'final' if the compiler supports the feature,
# even though CXX_STANDARD is not set explicitly.  The requirement of
# cxx_constexpr causes CMake to set CXX_STANDARD internally, which
# affects the compile flags.
add_library(foo_impl foo_impl.cpp)
target_compile_features(foo_impl PRIVATE cxx_constexpr)

The write_compiler_detection_header function also creates compatibility code for other features which have standard equivalents. For example, the cxx_static_assert feature is emulated with a template and abstracted via the <PREFIX>_STATIC_ASSERT and <PREFIX>_STATIC_ASSERT_MSG function-macros.

Conditional Compilation Options

Libraries may provide entirely different header files depending on requested compiler features.

For example, a header at with_variadics/interface.h may contain:

template<int I, int... Is>
struct Interface;

template<int I>
struct Interface<I>
{
  static int accumulate()
  {
    return I;
  }
};

template<int I, int... Is>
struct Interface
{
  static int accumulate()
  {
    return I + Interface<Is...>::accumulate();
  }
};

while a header at no_variadics/interface.h may contain:

template<int I1, int I2 = 0, int I3 = 0, int I4 = 0>
struct Interface
{
  static int accumulate() { return I1 + I2 + I3 + I4; }
};

It would be possible to write a abstraction interface.h header containing something like:

#include "foo_compiler_detection.h"
#if Foo_COMPILER_CXX_VARIADIC_TEMPLATES
#include "with_variadics/interface.h"
#else
#include "no_variadics/interface.h"
#endif

However this could be unmaintainable if there are many files to abstract. What is needed is to use alternative include directories depending on the compiler capabilities.

CMake provides a COMPILE_FEATURES generator expression to implement such conditions. This may be used with the build-property commands such as target_include_directories() and target_link_libraries() to set the appropriate buildsystem properties:

add_library(foo INTERFACE)
set(with_variadics ${CMAKE_CURRENT_SOURCE_DIR}/with_variadics)
set(no_variadics ${CMAKE_CURRENT_SOURCE_DIR}/no_variadics)
target_include_directories(foo
  INTERFACE
    "$<$<COMPILE_FEATURES:cxx_variadic_templates>:${with_variadics}>"
    "$<$<NOT:$<COMPILE_FEATURES:cxx_variadic_templates>>:${no_variadics}>"
  )

Consuming code then simply links to the foo target as usual and uses the feature-appropriate include directory

add_executable(consumer_with consumer_with.cpp)
target_link_libraries(consumer_with foo)
set_property(TARGET consumer_with CXX_STANDARD 11)

add_executable(consumer_no consumer_no.cpp)
target_link_libraries(consumer_no foo)

Supported Compilers

CMake is currently aware of the C++ standards and compile features available from the following compiler ids as of the versions specified for each:

  • AppleClang: Apple Clang for Xcode versions 4.4 though 9.2.
  • Clang: Clang compiler versions 2.9 through 6.0.
  • GNU: GNU compiler versions 4.4 through 8.0.
  • MSVC: Microsoft Visual Studio versions 2010 through 2017.
  • SunPro: Oracle SolarisStudio versions 12.4 through 12.6.
  • Intel: Intel compiler versions 12.1 through 17.0.

CMake is currently aware of the C standards and compile features available from the following compiler ids as of the versions specified for each:

  • all compilers and versions listed above for C++.
  • GNU: GNU compiler versions 3.4 through 8.0.

CMake is currently aware of the C++ standards and their associated meta-features (e.g. cxx_std_11) available from the following compiler ids as of the versions specified for each:

  • Cray: Cray Compiler Environment version 8.1 through 8.5.8.
  • PGI: PGI version 12.10 through 17.5.
  • XL: IBM XL version 10.1 through 13.1.5.

CMake is currently aware of the C standards and their associated meta-features (e.g. c_std_99) available from the following compiler ids as of the versions specified for each:

  • all compilers and versions listed above with only meta-features for C++.
  • TI: Texas Instruments compiler.

CMake is currently aware of the CUDA standards from the following compiler ids as of the versions specified for each:

  • NVIDIA: NVIDIA nvcc compiler 7.5 though 9.1.


cmake-developer(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-developer(7)

Contents

  • cmake-developer(7)
    • Introduction
    • Find Modules
      • Standard Variable Names
      • A Sample Find Module

Introduction

This manual is intended for reference by developers working with cmake-language(7) code, whether writing their own modules, authoring their own build systems, or working on CMake itself.

See https://cmake.org/get-involved/ to get involved in development of CMake upstream. It includes links to contribution instructions, which in turn link to developer guides for CMake itself.

Find Modules

A “find module” is a Find<PackageName>.cmake file to be loaded by the find_package() command when invoked for <PackageName>.

The primary task of a find module is to determine whether a package exists on the system, set the <PackageName>_FOUND variable to reflect this and provide any variables, macros and imported targets required to use the package. A find module is useful in cases where an upstream library does not provide a config file package.

The traditional approach is to use variables for everything, including libraries and executables: see the Standard Variable Names section below. This is what most of the existing find modules provided by CMake do.

The more modern approach is to behave as much like config file packages files as possible, by providing imported target. This has the advantage of propagating Transitive Usage Requirements to consumers.

In either case (or even when providing both variables and imported targets), find modules should provide backwards compatibility with old versions that had the same name.

A FindFoo.cmake module will typically be loaded by the command:

find_package(Foo [major[.minor[.patch[.tweak]]]]
             [EXACT] [QUIET] [REQUIRED]
             [[COMPONENTS] [components...]]
             [OPTIONAL_COMPONENTS components...]
             [NO_POLICY_SCOPE])

See the find_package() documentation for details on what variables are set for the find module. Most of these are dealt with by using FindPackageHandleStandardArgs.

Briefly, the module should only locate versions of the package compatible with the requested version, as described by the Foo_FIND_VERSION family of variables. If Foo_FIND_QUIETLY is set to true, it should avoid printing messages, including anything complaining about the package not being found. If Foo_FIND_REQUIRED is set to true, the module should issue a FATAL_ERROR if the package cannot be found. If neither are set to true, it should print a non-fatal message if it cannot find the package.

Packages that find multiple semi-independent parts (like bundles of libraries) should search for the components listed in Foo_FIND_COMPONENTS if it is set , and only set Foo_FOUND to true if for each searched-for component <c> that was not found, Foo_FIND_REQUIRED_<c> is not set to true. The HANDLE_COMPONENTS argument of find_package_handle_standard_args() can be used to implement this.

If Foo_FIND_COMPONENTS is not set, which modules are searched for and required is up to the find module, but should be documented.

For internal implementation, it is a generally accepted convention that variables starting with underscore are for temporary use only.

Standard Variable Names

For a FindXxx.cmake module that takes the approach of setting variables (either instead of or in addition to creating imported targets), the following variable names should be used to keep things consistent between find modules. Note that all variables start with Xxx_ to make sure they do not interfere with other find modules; the same consideration applies to macros, functions and imported targets.

Xxx_INCLUDE_DIRS
The final set of include directories listed in one variable for use by client code. This should not be a cache entry.
Xxx_LIBRARIES
The libraries to link against to use Xxx. These should include full paths. This should not be a cache entry.
Xxx_DEFINITIONS
Definitions to use when compiling code that uses Xxx. This really shouldn’t include options such as -DHAS_JPEG that a client source-code file uses to decide whether to #include <jpeg.h>
Xxx_EXECUTABLE
Where to find the Xxx tool.
Xxx_Yyy_EXECUTABLE
Where to find the Yyy tool that comes with Xxx.
Xxx_LIBRARY_DIRS
Optionally, the final set of library directories listed in one variable for use by client code. This should not be a cache entry.
Xxx_ROOT_DIR
Where to find the base directory of Xxx.
Xxx_VERSION_Yy
Expect Version Yy if true. Make sure at most one of these is ever true.
Xxx_WRAP_Yy
If False, do not try to use the relevant CMake wrapping command.
Xxx_Yy_FOUND
If False, optional Yy part of Xxx system is not available.
Xxx_FOUND
Set to false, or undefined, if we haven’t found, or don’t want to use Xxx.
Xxx_NOT_FOUND_MESSAGE
Should be set by config-files in the case that it has set Xxx_FOUND to FALSE. The contained message will be printed by the find_package() command and by find_package_handle_standard_args() to inform the user about the problem.
Xxx_RUNTIME_LIBRARY_DIRS
Optionally, the runtime library search path for use when running an executable linked to shared libraries. The list should be used by user code to create the PATH on windows or LD_LIBRARY_PATH on UNIX. This should not be a cache entry.
Xxx_VERSION
The full version string of the package found, if any. Note that many existing modules provide Xxx_VERSION_STRING instead.
Xxx_VERSION_MAJOR
The major version of the package found, if any.
Xxx_VERSION_MINOR
The minor version of the package found, if any.
Xxx_VERSION_PATCH
The patch version of the package found, if any.

The following names should not usually be used in CMakeLists.txt files, but are typically cache variables for users to edit and control the behaviour of find modules (like entering the path to a library manually)

Xxx_LIBRARY
The path of the Xxx library (as used with find_library(), for example).
Xxx_Yy_LIBRARY
The path of the Yy library that is part of the Xxx system. It may or may not be required to use Xxx.
Xxx_INCLUDE_DIR
Where to find headers for using the Xxx library.
Xxx_Yy_INCLUDE_DIR
Where to find headers for using the Yy library of the Xxx system.

To prevent users being overwhelmed with settings to configure, try to keep as many options as possible out of the cache, leaving at least one option which can be used to disable use of the module, or locate a not-found library (e.g. Xxx_ROOT_DIR). For the same reason, mark most cache options as advanced. For packages which provide both debug and release binaries, it is common to create cache variables with a _LIBRARY_<CONFIG> suffix, such as Foo_LIBRARY_RELEASE and Foo_LIBRARY_DEBUG.

While these are the standard variable names, you should provide backwards compatibility for any old names that were actually in use. Make sure you comment them as deprecated, so that no-one starts using them.

A Sample Find Module

We will describe how to create a simple find module for a library Foo.

The top of the module should begin with a license notice, followed by a blank line, and then followed by a Bracket Comment. The comment should begin with .rst: to indicate that the rest of its content is reStructuredText-format documentation. For example:

# Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
# file Copyright.txt or https://cmake.org/licensing for details.

#[=======================================================================[.rst:
FindFoo
-------

Finds the Foo library.

Imported Targets
^^^^^^^^^^^^^^^^

This module provides the following imported targets, if found:

``Foo::Foo``
  The Foo library

Result Variables
^^^^^^^^^^^^^^^^

This will define the following variables:

``Foo_FOUND``
  True if the system has the Foo library.
``Foo_VERSION``
  The version of the Foo library which was found.
``Foo_INCLUDE_DIRS``
  Include directories needed to use Foo.
``Foo_LIBRARIES``
  Libraries needed to link to Foo.

Cache Variables
^^^^^^^^^^^^^^^

The following cache variables may also be set:

``Foo_INCLUDE_DIR``
  The directory containing ``foo.h``.
``Foo_LIBRARY``
  The path to the Foo library.

#]=======================================================================]

The module documentation consists of:

  • An underlined heading specifying the module name.
  • A simple description of what the module finds. More description may be required for some packages. If there are caveats or other details users of the module should be aware of, specify them here.
  • A section listing imported targets provided by the module, if any.
  • A section listing result variables provided by the module.
  • Optionally a section listing cache variables used by the module, if any.

If the package provides any macros or functions, they should be listed in an additional section, but can be documented by additional .rst: comment blocks immediately above where those macros or functions are defined.

The find module implementation may begin below the documentation block. Now the actual libraries and so on have to be found. The code here will obviously vary from module to module (dealing with that, after all, is the point of find modules), but there tends to be a common pattern for libraries.

First, we try to use pkg-config to find the library. Note that we cannot rely on this, as it may not be available, but it provides a good starting point.

find_package(PkgConfig)
pkg_check_modules(PC_Foo QUIET Foo)

This should define some variables starting PC_Foo_ that contain the information from the Foo.pc file.

Now we need to find the libraries and include files; we use the information from pkg-config to provide hints to CMake about where to look.

find_path(Foo_INCLUDE_DIR
  NAMES foo.h
  PATHS ${PC_Foo_INCLUDE_DIRS}
  PATH_SUFFIXES Foo
)
find_library(Foo_LIBRARY
  NAMES foo
  PATHS ${PC_Foo_LIBRARY_DIRS}
)

If you have a good way of getting the version (from a header file, for example), you can use that information to set Foo_VERSION (although note that find modules have traditionally used Foo_VERSION_STRING, so you may want to set both). Otherwise, attempt to use the information from pkg-config

set(Foo_VERSION ${PC_Foo_VERSION})

Now we can use FindPackageHandleStandardArgs to do most of the rest of the work for us

include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Foo
  FOUND_VAR Foo_FOUND
  REQUIRED_VARS
    Foo_LIBRARY
    Foo_INCLUDE_DIR
  VERSION_VAR Foo_VERSION
)

This will check that the REQUIRED_VARS contain values (that do not end in -NOTFOUND) and set Foo_FOUND appropriately. It will also cache those values. If Foo_VERSION is set, and a required version was passed to find_package(), it will check the requested version against the one in Foo_VERSION. It will also print messages as appropriate; note that if the package was found, it will print the contents of the first required variable to indicate where it was found.

At this point, we have to provide a way for users of the find module to link to the library or libraries that were found. There are two approaches, as discussed in the Find Modules section above. The traditional variable approach looks like

if(Foo_FOUND)
  set(Foo_LIBRARIES ${Foo_LIBRARY})
  set(Foo_INCLUDE_DIRS ${Foo_INCLUDE_DIR})
  set(Foo_DEFINITIONS ${PC_Foo_CFLAGS_OTHER})
endif()

If more than one library was found, all of them should be included in these variables (see the Standard Variable Names section for more information).

When providing imported targets, these should be namespaced (hence the Foo:: prefix); CMake will recognize that values passed to target_link_libraries() that contain :: in their name are supposed to be imported targets (rather than just library names), and will produce appropriate diagnostic messages if that target does not exist (see policy CMP0028).

if(Foo_FOUND AND NOT TARGET Foo::Foo)
  add_library(Foo::Foo UNKNOWN IMPORTED)
  set_target_properties(Foo::Foo PROPERTIES
    IMPORTED_LOCATION "${Foo_LIBRARY}"
    INTERFACE_COMPILE_OPTIONS "${PC_Foo_CFLAGS_OTHER}"
    INTERFACE_INCLUDE_DIRECTORIES "${Foo_INCLUDE_DIR}"
  )
endif()

One thing to note about this is that the INTERFACE_INCLUDE_DIRECTORIES and similar properties should only contain information about the target itself, and not any of its dependencies. Instead, those dependencies should also be targets, and CMake should be told that they are dependencies of this target. CMake will then combine all the necessary information automatically.

The type of the IMPORTED target created in the add_library() command can always be specified as UNKNOWN type. This simplifies the code in cases where static or shared variants may be found, and CMake will determine the type by inspecting the files.

If the library is available with multiple configurations, the IMPORTED_CONFIGURATIONS target property should also be populated:

if(Foo_FOUND)
  if (NOT TARGET Foo::Foo)
    add_library(Foo::Foo UNKNOWN IMPORTED)
  endif()
  if (Foo_LIBRARY_RELEASE)
    set_property(TARGET Foo::Foo APPEND PROPERTY
      IMPORTED_CONFIGURATIONS RELEASE
    )
    set_target_properties(Foo::Foo PROPERTIES
      IMPORTED_LOCATION_RELEASE "${Foo_LIBRARY_RELEASE}"
    )
  endif()
  if (Foo_LIBRARY_DEBUG)
    set_property(TARGET Foo::Foo APPEND PROPERTY
      IMPORTED_CONFIGURATIONS DEBUG
    )
    set_target_properties(Foo::Foo PROPERTIES
      IMPORTED_LOCATION_DEBUG "${Foo_LIBRARY_DEBUG}"
    )
  endif()
  set_target_properties(Foo::Foo PROPERTIES
    INTERFACE_COMPILE_OPTIONS "${PC_Foo_CFLAGS_OTHER}"
    INTERFACE_INCLUDE_DIRECTORIES "${Foo_INCLUDE_DIR}"
  )
endif()

The RELEASE variant should be listed first in the property so that the variant is chosen if the user uses a configuration which is not an exact match for any listed IMPORTED_CONFIGURATIONS.

Most of the cache variables should be hidden in the ccmake interface unless the user explicitly asks to edit them.

mark_as_advanced(
  Foo_INCLUDE_DIR
  Foo_LIBRARY
)

If this module replaces an older version, you should set compatibility variables to cause the least disruption possible.

# compatibility variables
set(Foo_VERSION_STRING ${Foo_VERSION})


cmake-env-variables(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-env-variables(7)

Contents

  • cmake-env-variables(7)
    • Environment Variables that Control the Build
    • Environment Variables for Languages
    • Environment Variables for CTest

This page lists environment variables that have special meaning to CMake.

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

Environment Variables that Control the Build

  • CMAKE_BUILD_PARALLEL_LEVEL
  • CMAKE_CONFIG_TYPE
  • CMAKE_MSVCIDE_RUN_PATH
  • CMAKE_NO_VERBOSE
  • CMAKE_OSX_ARCHITECTURES
  • DESTDIR
  • LDFLAGS
  • MACOSX_DEPLOYMENT_TARGET
  • <PackageName>_ROOT
  • VERBOSE

Environment Variables for Languages

  • ASM<DIALECT>
  • ASM<DIALECT>FLAGS
  • CC
  • CFLAGS
  • CSFLAGS
  • CUDACXX
  • CUDAFLAGS
  • CUDAHOSTCXX
  • CXX
  • CXXFLAGS
  • FC
  • FFLAGS
  • RC
  • RCFLAGS

Environment Variables for CTest

  • CMAKE_CONFIG_TYPE
  • CTEST_INTERACTIVE_DEBUG_MODE
  • CTEST_OUTPUT_ON_FAILURE
  • CTEST_PARALLEL_LEVEL
  • CTEST_PROGRESS_OUTPUT
  • CTEST_USE_LAUNCHERS_DEFAULT
  • DASHBOARD_TEST_FROM_CTEST


CMAKE_BUILD_PARALLEL_LEVEL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CMAKE_BUILD_PARALLEL_LEVEL

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Specifies the maximum number of concurrent processes to use when building using the cmake --build command line Build Tool Mode.

If this variable is defined empty the native build tool’s default number is used.

  • cmake-env-variables(7) »


CMAKE_CONFIG_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CMAKE_CONFIG_TYPE

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

The default build configuration for Build a Project and ctest build handler when there is no explicit configuration given.

  • cmake-env-variables(7) »


CMAKE_MSVCIDE_RUN_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CMAKE_MSVCIDE_RUN_PATH

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Extra PATH locations for custom commands when using Visual Studio 9 2008 (or above) generators.

The CMAKE_MSVCIDE_RUN_PATH environment variable sets the default value for the CMAKE_MSVCIDE_RUN_PATH variable if not already explicitly set.

  • cmake-env-variables(7) »


CMAKE_NO_VERBOSE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CMAKE_NO_VERBOSE

Disables verbose output from CMake when VERBOSE environment variable is set.

Only your build tool of choice will still print verbose output when you start to actually build your project.

  • cmake-env-variables(7) »


CMAKE_OSX_ARCHITECTURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CMAKE_OSX_ARCHITECTURES

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Target specific architectures for macOS.

The CMAKE_OSX_ARCHITECTURES environment variable sets the default value for the CMAKE_OSX_ARCHITECTURES variable. See OSX_ARCHITECTURES for more information.

  • cmake-env-variables(7) »


DESTDIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

DESTDIR

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

On UNIX one can use the DESTDIR mechanism in order to relocate the whole installation. DESTDIR means DESTination DIRectory. It is commonly used by makefile users in order to install software at non-default location. It is usually invoked like this:

make DESTDIR=/home/john install

which will install the concerned software using the installation prefix, e.g. /usr/local prepended with the DESTDIR value which finally gives /home/john/usr/local.

WARNING: DESTDIR may not be used on Windows because installation prefix usually contains a drive letter like in C:/Program Files which cannot be prepended with some other prefix.

  • cmake-env-variables(7) »


LDFLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

LDFLAGS

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Will only be used by CMake on the first configuration to determine the default linker flags, after which the value for LDFLAGS is stored in the cache as CMAKE_EXE_LINKER_FLAGS_INIT, CMAKE_SHARED_LINKER_FLAGS_INIT, and CMAKE_MODULE_LINKER_FLAGS_INIT. For any configuration run (including the first), the environment variable will be ignored if the equivalent CMAKE_<TYPE>_LINKER_FLAGS_INIT variable is defined.

  • cmake-env-variables(7) »


MACOSX_DEPLOYMENT_TARGET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

MACOSX_DEPLOYMENT_TARGET

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Specify the minimum version of macOS on which the target binaries are to be deployed.

The MACOSX_DEPLOYMENT_TARGET environment variable sets the default value for the CMAKE_OSX_DEPLOYMENT_TARGET variable.

  • cmake-env-variables(7) »


<PackageName>_ROOT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

<PackageName>_ROOT

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

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

This variable may hold a single prefix or a list of prefixes separated by : on UNIX or ; on Windows (the same as the PATH environment variable convention on those platforms).

See also the <PackageName>_ROOT CMake variable.

  • cmake-env-variables(7) »


VERBOSE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

VERBOSE

Activates verbose output from CMake and your build tools of choice when you start to actually build your project.

Note that any given value is ignored. It’s just checked for existence.

See also Build Tool Mode and CMAKE_NO_VERBOSE environment variable

  • cmake-env-variables(7) »


ASM<DIALECT> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

ASM<DIALECT>

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Preferred executable for compiling a specific dialect of assembly language files. ASM<DIALECT> can be ASM, ASM_NASM, ASM_MASM or ASM-ATT. Will only be used by CMake on the first configuration to determine ASM<DIALECT> compiler, after which the value for ASM<DIALECT> is stored in the cache as CMAKE_ASM<DIALECT>_COMPILER. For subsequent configuration runs, the environment variable will be ignored in favor of CMAKE_ASM<DIALECT>_COMPILER.

  • cmake-env-variables(7) »


ASM<DIALECT>FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

ASM<DIALECT>FLAGS

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Default compilation flags to be used when compiling a specific dialect of an assembly language. ASM<DIALECT>FLAGS can be ASMFLAGS, ASM_NASMFLAGS, ASM_MASMFLAGS or ASM-ATTFLAGS. Will only be used by CMake on the first configuration to determine ASM<DIALECT> default compilation flags, after which the value for ASM<DIALECT>FLAGS is stored in the cache as CMAKE_ASM<DIALECT>_FLAGS. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_ASM<DIALECT>_FLAGS variable is defined.

  • cmake-env-variables(7) »


CC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CC

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Preferred executable for compiling C language files. Will only be used by CMake on the first configuration to determine C compiler, after which the value for CC is stored in the cache as CMAKE_C_COMPILER. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_C_COMPILER variable is defined.

  • cmake-env-variables(7) »


CFLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CFLAGS

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Default compilation flags to be used when compiling C files. Will only be used by CMake on the first configuration to determine CC default compilation flags, after which the value for CFLAGS is stored in the cache as CMAKE_C_FLAGS. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_C_FLAGS variable is defined.

  • cmake-env-variables(7) »


CSFLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CSFLAGS

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Preferred executable for compiling CSharp language files. Will only be used by CMake on the first configuration to determine CSharp default compilation flags, after which the value for CSFLAGS is stored in the cache as CMAKE_CSharp_FLAGS. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_CSharp_FLAGS variable is defined.

  • cmake-env-variables(7) »


CUDACXX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CUDACXX

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Preferred executable for compiling CUDA language files. Will only be used by CMake on the first configuration to determine CUDA compiler, after which the value for CUDA is stored in the cache as CMAKE_CUDA_COMPILER. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_CUDA_COMPILER variable is defined.

  • cmake-env-variables(7) »


CUDAFLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CUDAFLAGS

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Default compilation flags to be used when compiling CUDA files. Will only be used by CMake on the first configuration to determine CUDA default compilation flags, after which the value for CUDAFLAGS is stored in the cache as CMAKE_CUDA_FLAGS. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_CUDA_FLAGS variable is defined.

  • cmake-env-variables(7) »


CUDAHOSTCXX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CUDAHOSTCXX

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Preferred executable for compiling host code when compiling CUDA language files. Will only be used by CMake on the first configuration to determine CUDA host compiler, after which the value for CUDAHOSTCXX is stored in the cache as CMAKE_CUDA_HOST_COMPILER. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_CUDA_HOST_COMPILER variable is defined.

This environment variable is primarily meant for use with projects that enable CUDA as a first-class language. The FindCUDA module will also use it to initialize its CUDA_HOST_COMPILER setting.

  • cmake-env-variables(7) »


CXX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CXX

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Preferred executable for compiling CXX language files. Will only be used by CMake on the first configuration to determine CXX compiler, after which the value for CXX is stored in the cache as CMAKE_CXX_COMPILER. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_CXX_COMPILER variable is defined.

  • cmake-env-variables(7) »


CXXFLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CXXFLAGS

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Default compilation flags to be used when compiling CXX (C++) files. Will only be used by CMake on the first configuration to determine CXX default compilation flags, after which the value for CXXFLAGS is stored in the cache as CMAKE_CXX_FLAGS. For any configuration run ( including the first), the environment variable will be ignored if the CMAKE_CXX_FLAGS variable is defined.

  • cmake-env-variables(7) »


FC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

FC

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Preferred executable for compiling Fortran language files. Will only be used by CMake on the first configuration to determine Fortran compiler, after which the value for Fortran is stored in the cache as CMAKE_Fortran_COMPILER. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_Fortran_COMPILER variable is defined.

  • cmake-env-variables(7) »


FFLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

FFLAGS

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Default compilation flags to be used when compiling Fortran files. Will only be used by CMake on the first configuration to determine Fortran default compilation flags, after which the value for FFLAGS is stored in the cache as CMAKE_Fortran_FLAGS. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_Fortran_FLAGS variable is defined.

  • cmake-env-variables(7) »


RC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

RC

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Preferred executable for compiling resource files. Will only be used by CMake on the first configuration to determine resource compiler, after which the value for RC is stored in the cache as CMAKE_RC_COMPILER. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_RC_COMPILER variable is defined.

  • cmake-env-variables(7) »


RCFLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

RCFLAGS

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Default compilation flags to be used when compiling resource files. Will only be used by CMake on the first configuration to determine resource default compilation flags, after which the value for RCFLAGS is stored in the cache as CMAKE_RC_FLAGS. For any configuration run (including the first), the environment variable will be ignored if the CMAKE_RC_FLAGS variable is defined.

  • cmake-env-variables(7) »


CTEST_INTERACTIVE_DEBUG_MODE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CTEST_INTERACTIVE_DEBUG_MODE

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Environment variable that will exist and be set to 1 when a test executed by CTest is run in interactive mode.

  • cmake-env-variables(7) »


CTEST_OUTPUT_ON_FAILURE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CTEST_OUTPUT_ON_FAILURE

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Boolean environment variable that controls if the output should be logged for failed tests. Set the value to 1, True, or ON to enable output on failure. See ctest(1) for more information on controlling output of failed tests.

  • cmake-env-variables(7) »


CTEST_PARALLEL_LEVEL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CTEST_PARALLEL_LEVEL

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Specify the number of tests for CTest to run in parallel. See ctest(1) for more information on parallel test execution.

  • cmake-env-variables(7) »


CTEST_PROGRESS_OUTPUT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CTEST_PROGRESS_OUTPUT

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Boolean environment variable that affects how ctest command output reports overall progress. When set to 1, TRUE, ON or anything else that evaluates to boolean true, progress is reported by repeatedly updating the same line. This greatly reduces the overall verbosity, but is only supported when output is sent directly to a terminal. If the environment variable is not set or has a value that evaluates to false, output is reported normally with each test having its own start and end lines logged to the output.

The --progress option to ctest overrides this environment variable if both are given.

  • cmake-env-variables(7) »


CTEST_USE_LAUNCHERS_DEFAULT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

CTEST_USE_LAUNCHERS_DEFAULT

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Initializes the CTEST_USE_LAUNCHERS variable if not already defined.

  • cmake-env-variables(7) »


DASHBOARD_TEST_FROM_CTEST — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-env-variables(7) »

DASHBOARD_TEST_FROM_CTEST

This is a CMake Environment Variable. Its initial value is taken from the calling process environment.

Environment variable that will exist when a test executed by CTest is run in non-interactive mode. The value will be equal to CMAKE_VERSION.

  • cmake-env-variables(7) »


cmake-file-api(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-file-api(7)

Contents

  • cmake-file-api(7)
    • Introduction
    • API v1
      • v1 Shared Stateless Query Files
      • v1 Client Stateless Query Files
      • v1 Client Stateful Query Files
      • v1 Reply Index File
        • v1 Reply File Reference
      • v1 Reply Files
    • Object Kinds
      • Object Kind “codemodel”
        • “codemodel” version 2
        • “codemodel” version 2 “target” object
      • Object Kind “cache”
        • “cache” version 2
      • Object Kind “cmakeFiles”
        • “cmakeFiles” version 1

Introduction

CMake provides a file-based API that clients may use to get semantic information about the buildsystems CMake generates. Clients may use the API by writing query files to a specific location in a build tree to request zero or more Object Kinds. When CMake generates the buildsystem in that build tree it will read the query files and write reply files for the client to read.

The file-based API uses a <build>/.cmake/api/ directory at the top of a build tree. The API is versioned to support changes to the layout of files within the API directory. API file layout versioning is orthogonal to the versioning of Object Kinds used in replies. This version of CMake supports only one API version, API v1.

API v1

API v1 is housed in the <build>/.cmake/api/v1/ directory. It has the following subdirectories:

query/
Holds query files written by clients. These may be v1 Shared Stateless Query Files, v1 Client Stateless Query Files, or v1 Client Stateful Query Files.
reply/

Holds reply files written by CMake whenever it runs to generate a build system. These are indexed by a v1 Reply Index File file that may reference additional v1 Reply Files. CMake owns all reply files. Clients must never remove them.

Clients may look for and read a reply index file at any time. Clients may optionally create the reply/ directory at any time and monitor it for the appearance of a new reply index file.

v1 Shared Stateless Query Files

Shared stateless query files allow clients to share requests for major versions of the Object Kinds and get all requested versions recognized by the CMake that runs.

Clients may create shared requests by creating empty files in the v1/query/ directory. The form is:

<build>/.cmake/api/v1/query/<kind>-v<major>

where <kind> is one of the Object Kinds, -v is literal, and <major> is the major version number.

Files of this form are stateless shared queries not owned by any specific client. Once created they should not be removed without external client coordination or human intervention.

v1 Client Stateless Query Files

Client stateless query files allow clients to create owned requests for major versions of the Object Kinds and get all requested versions recognized by the CMake that runs.

Clients may create owned requests by creating empty files in client-specific query subdirectories. The form is:

<build>/.cmake/api/v1/query/client-<client>/<kind>-v<major>

where client- is literal, <client> is a string uniquely identifying the client, <kind> is one of the Object Kinds, -v is literal, and <major> is the major version number. Each client must choose a unique <client> identifier via its own means.

Files of this form are stateless queries owned by the client <client>. The owning client may remove them at any time.

v1 Client Stateful Query Files

Stateful query files allow clients to request a list of versions of each of the Object Kinds and get only the most recent version recognized by the CMake that runs.

Clients may create owned stateful queries by creating query.json files in client-specific query subdirectories. The form is:

<build>/.cmake/api/v1/query/client-<client>/query.json

where client- is literal, <client> is a string uniquely identifying the client, and query.json is literal. Each client must choose a unique <client> identifier via its own means.

query.json files are stateful queries owned by the client <client>. The owning client may update or remove them at any time. When a given client installation is updated it may then update the stateful query it writes to build trees to request newer object versions. This can be used to avoid asking CMake to generate multiple object versions unnecessarily.

A query.json file must contain a JSON object:

{
  "requests": [
    { "kind": "<kind>" , "version": 1 },
    { "kind": "<kind>" , "version": { "major": 1, "minor": 2 } },
    { "kind": "<kind>" , "version": [2, 1] },
    { "kind": "<kind>" , "version": [2, { "major": 1, "minor": 2 }] },
    { "kind": "<kind>" , "version": 1, "client": {} },
    { "kind": "..." }
  ],
  "client": {}
}

The members are:

requests

A JSON array containing zero or more requests. Each request is a JSON object with members:

kind
Specifies one of the Object Kinds to be included in the reply.
version

Indicates the version(s) of the object kind that the client understands. Versions have major and minor components following semantic version conventions. The value must be

  • a JSON integer specifying a (non-negative) major version number, or
  • a JSON object containing major and (optionally) minor members specifying non-negative integer version components, or
  • a JSON array whose elements are each one of the above.
client
Optional member reserved for use by the client. This value is preserved in the reply written for the client in the v1 Reply Index File but is otherwise ignored. Clients may use this to pass custom information with a request through to its reply.

For each requested object kind CMake will choose the first version that it recognizes for that kind among those listed in the request. The response will use the selected major version with the highest minor version known to the running CMake for that major version. Therefore clients should list all supported major versions in preferred order along with the minimal minor version required for each major version.

client
Optional member reserved for use by the client. This value is preserved in the reply written for the client in the v1 Reply Index File but is otherwise ignored. Clients may use this to pass custom information with a query through to its reply.

Other query.json top-level members are reserved for future use. If present they are ignored for forward compatibility.

v1 Reply Index File

CMake writes an index-*.json file to the v1/reply/ directory whenever it runs to generate a build system. Clients must read the reply index file first and may read other v1 Reply Files only by following references. The form of the reply index file name is:

<build>/.cmake/api/v1/reply/index-<unspecified>.json

where index- is literal and <unspecified> is an unspecified name selected by CMake. Whenever a new index file is generated it is given a new name and any old one is deleted. During the short time between these steps there may be multiple index files present; the one with the largest name in lexicographic order is the current index file.

The reply index file contains a JSON object:

{
  "cmake": {
    "version": {
      "major": 3, "minor": 14, "patch": 0, "suffix": "",
      "string": "3.14.0", "isDirty": false
    },
    "paths": {
      "cmake": "/prefix/bin/cmake",
      "ctest": "/prefix/bin/ctest",
      "cpack": "/prefix/bin/cpack",
      "root": "/prefix/share/cmake-3.14"
    },
    "generator": {
      "name": "Unix Makefiles"
    }
  },
  "objects": [
    { "kind": "<kind>",
      "version": { "major": 1, "minor": 0 },
      "jsonFile": "<file>" },
    { "...": "..." }
  ],
  "reply": {
    "<kind>-v<major>": { "kind": "<kind>",
                         "version": { "major": 1, "minor": 0 },
                         "jsonFile": "<file>" },
    "<unknown>": { "error": "unknown query file" },
    "...": {},
    "client-<client>": {
      "<kind>-v<major>": { "kind": "<kind>",
                           "version": { "major": 1, "minor": 0 },
                           "jsonFile": "<file>" },
      "<unknown>": { "error": "unknown query file" },
      "...": {},
      "query.json": {
        "requests": [ {}, {}, {} ],
        "responses": [
          { "kind": "<kind>",
            "version": { "major": 1, "minor": 0 },
            "jsonFile": "<file>" },
          { "error": "unknown query file" },
          { "...": {} }
        ],
        "client": {}
      }
    }
  }
}

The members are:

cmake

A JSON object containing information about the instance of CMake that generated the reply. It contains members:

version

A JSON object specifying the version of CMake with members:

major, minor, patch
Integer values specifying the major, minor, and patch version components.
suffix
A string specifying the version suffix, if any, e.g. g0abc3.
string
A string specifying the full version in the format <major>.<minor>.<patch>[-<suffix>].
isDirty
A boolean indicating whether the version was built from a version controlled source tree with local modifications.
paths
A JSON object specifying paths to things that come with CMake. It has members for cmake, ctest, and cpack whose values are JSON strings specifying the absolute path to each tool, represented with forward slashes. It also has a root member for the absolute path to the directory containing CMake resources like the Modules/ directory (see CMAKE_ROOT).
generator

A JSON object describing the CMake generator used for the build. It has members:

name
A string specifying the name of the generator.
platform
If the generator supports CMAKE_GENERATOR_PLATFORM, this is a string specifying the generator platform name.
objects
A JSON array listing all versions of all Object Kinds generated as part of the reply. Each array entry is a v1 Reply File Reference.
reply

A JSON object mirroring the content of the query/ directory that CMake loaded to produce the reply. The members are of the form

<kind>-v<major>
A member of this form appears for each of the v1 Shared Stateless Query Files that CMake recognized as a request for object kind <kind> with major version <major>. The value is a v1 Reply File Reference to the corresponding reply file for that object kind and version.
<unknown>
A member of this form appears for each of the v1 Shared Stateless Query Files that CMake did not recognize. The value is a JSON object with a single error member containing a string with an error message indicating that the query file is unknown.
client-<client>

A member of this form appears for each client-owned directory holding v1 Client Stateless Query Files. The value is a JSON object mirroring the content of the query/client-<client>/ directory. The members are of the form:

<kind>-v<major>
A member of this form appears for each of the v1 Client Stateless Query Files that CMake recognized as a request for object kind <kind> with major version <major>. The value is a v1 Reply File Reference to the corresponding reply file for that object kind and version.
<unknown>
A member of this form appears for each of the v1 Client Stateless Query Files that CMake did not recognize. The value is a JSON object with a single error member containing a string with an error message indicating that the query file is unknown.
query.json

This member appears for clients using v1 Client Stateful Query Files. If the query.json file failed to read or parse as a JSON object, this member is a JSON object with a single error member containing a string with an error message. Otherwise, this member is a JSON object mirroring the content of the query.json file. The members are:

client
A copy of the query.json file client member, if it exists.
requests
A copy of the query.json file requests member, if it exists.
responses

If the query.json file requests member is missing or invalid, this member is a JSON object with a single error member containing a string with an error message. Otherwise, this member contains a JSON array with a response for each entry of the requests array, in the same order. Each response is

  • a JSON object with a single error member containing a string with an error message, or
  • a v1 Reply File Reference to the corresponding reply file for the requested object kind and selected version.

After reading the reply index file, clients may read the other v1 Reply Files it references.

v1 Reply File Reference

The reply index file represents each reference to another reply file using a JSON object with members:

kind
A string specifying one of the Object Kinds.
version
A JSON object with members major and minor specifying integer version components of the object kind.
jsonFile
A JSON string specifying a path relative to the reply index file to another JSON file containing the object.

v1 Reply Files

Reply files containing specific Object Kinds are written by CMake. The names of these files are unspecified and must not be interpreted by clients. Clients must first read the v1 Reply Index File and and follow references to the names of the desired response objects.

Reply files (including the index file) will never be replaced by files of the same name but different content. This allows a client to read the files concurrently with a running CMake that may generate a new reply. However, after generating a new reply CMake will attempt to remove reply files from previous runs that it did not just write. If a client attempts to read a reply file referenced by the index but finds the file missing, that means a concurrent CMake has generated a new reply. The client may simply start again by reading the new reply index file.

Object Kinds

The CMake file-based API reports semantic information about the build system using the following kinds of JSON objects. Each kind of object is versioned independently using semantic versioning with major and minor components. Every kind of object has the form:

{
  "kind": "<kind>",
  "version": { "major": 1, "minor": 0 },
  "...": {}
}

The kind member is a string specifying the object kind name. The version member is a JSON object with major and minor members specifying integer components of the object kind’s version. Additional top-level members are specific to each object kind.

Object Kind “codemodel”

The codemodel object kind describes the build system structure as modeled by CMake.

There is only one codemodel object major version, version 2. Version 1 does not exist to avoid confusion with that from cmake-server(7) mode.

“codemodel” version 2

codemodel object version 2 is a JSON object:

{
  "kind": "codemodel",
  "version": { "major": 2, "minor": 0 },
  "paths": {
    "source": "/path/to/top-level-source-dir",
    "build": "/path/to/top-level-build-dir"
  },
  "configurations": [
    {
      "name": "Debug",
      "directories": [
        {
          "source": ".",
          "build": ".",
          "childIndexes": [ 1 ],
          "projectIndex": 0,
          "targetIndexes": [ 0 ],
          "hasInstallRule": true,
          "minimumCMakeVersion": {
            "string": "3.14"
          }
        },
        {
          "source": "sub",
          "build": "sub",
          "parentIndex": 0,
          "projectIndex": 0,
          "targetIndexes": [ 1 ],
          "minimumCMakeVersion": {
            "string": "3.14"
          }
        }
      ],
      "projects": [
        {
          "name": "MyProject",
          "directoryIndexes": [ 0, 1 ],
          "targetIndexes": [ 0, 1 ]
        }
      ],
      "targets": [
        {
          "name": "MyExecutable",
          "directoryIndex": 0,
          "projectIndex": 0,
          "jsonFile": "<file>"
        },
        {
          "name": "MyLibrary",
          "directoryIndex": 1,
          "projectIndex": 0,
          "jsonFile": "<file>"
        }
      ]
    }
  ]
}

The members specific to codemodel objects are:

paths

A JSON object containing members:

source
A string specifying the absolute path to the top-level source directory, represented with forward slashes.
build
A string specifying the absolute path to the top-level build directory, represented with forward slashes.
configurations

A JSON array of entries corresponding to available build configurations. On single-configuration generators there is one entry for the value of the CMAKE_BUILD_TYPE variable. For multi-configuration generators there is an entry for each configuration listed in the CMAKE_CONFIGURATION_TYPES variable. Each entry is a JSON object containing members:

name
A string specifying the name of the configuration, e.g. Debug.
directories

A JSON array of entries each corresponding to a build system directory whose source directory contains a CMakeLists.txt file. The first entry corresponds to the top-level directory. Each entry is a JSON object containing members:

source
A string specifying the path to the source directory, represented with forward slashes. If the directory is inside the top-level source directory then the path is specified relative to that directory (with . for the top-level source directory itself). Otherwise the path is absolute.
build
A string specifying the path to the build directory, represented with forward slashes. If the directory is inside the top-level build directory then the path is specified relative to that directory (with . for the top-level build directory itself). Otherwise the path is absolute.
parentIndex
Optional member that is present when the directory is not top-level. The value is an unsigned integer 0-based index of another entry in the main directories array that corresponds to the parent directory that added this directory as a subdirectory.
childIndexes
Optional member that is present when the directory has subdirectories. The value is a JSON array of entries corresponding to child directories created by the add_subdirectory() or subdirs() command. Each entry is an unsigned integer 0-based index of another entry in the main directories array.
projectIndex
An unsigned integer 0-based index into the main projects array indicating the build system project to which the this directory belongs.
targetIndexes
Optional member that is present when the directory itself has targets, excluding those belonging to subdirectories. The value is a JSON array of entries corresponding to the targets. Each entry is an unsigned integer 0-based index into the main targets array.
minimumCMakeVersion

Optional member present when a minimum required version of CMake is known for the directory. This is the <min> version given to the most local call to the cmake_minimum_required(VERSION) command in the directory itself or one of its ancestors. The value is a JSON object with one member:

string

A string specifying the minimum required version in the format:

<major>.<minor>[.<patch>[.<tweak>]][<suffix>]

Each component is an unsigned integer and the suffix may be an arbitrary string.

hasInstallRule
Optional member that is present with boolean value true when the directory or one of its subdirectories contains any install() rules, i.e. whether a make install or equivalent rule is available.
projects

A JSON array of entries corresponding to the top-level project and sub-projects defined in the build system. Each (sub-)project corresponds to a source directory whose CMakeLists.txt file calls the project() command with a project name different from its parent directory. The first entry corresponds to the top-level project.

Each entry is a JSON object containing members:

name
A string specifying the name given to the project() command.
parentIndex
Optional member that is present when the project is not top-level. The value is an unsigned integer 0-based index of another entry in the main projects array that corresponds to the parent project that added this project as a sub-project.
childIndexes
Optional member that is present when the project has sub-projects. The value is a JSON array of entries corresponding to the sub-projects. Each entry is an unsigned integer 0-based index of another entry in the main projects array.
directoryIndexes
A JSON array of entries corresponding to build system directories that are part of the project. The first entry corresponds to the top-level directory of the project. Each entry is an unsigned integer 0-based index into the main directories array.
targetIndexes
Optional member that is present when the project itself has targets, excluding those belonging to sub-projects. The value is a JSON array of entries corresponding to the targets. Each entry is an unsigned integer 0-based index into the main targets array.
targets

A JSON array of entries corresponding to the build system targets. Such targets are created by calls to add_executable(), add_library(), and add_custom_target(), excluding imported targets and interface libraries (which do not generate any build rules). Each entry is a JSON object containing members:

name
A string specifying the target name.
id
A string uniquely identifying the target. This matches the id field in the file referenced by jsonFile.
directoryIndex
An unsigned integer 0-based index into the main directories array indicating the build system directory in which the target is defined.
projectIndex
An unsigned integer 0-based index into the main projects array indicating the build system project in which the target is defined.
jsonFile
A JSON string specifying a path relative to the codemodel file to another JSON file containing a “codemodel” version 2 “target” object.

“codemodel” version 2 “target” object

A codemodel “target” object is referenced by a “codemodel” version 2 object’s targets array. Each “target” object is a JSON object with members:

name
A string specifying the logical name of the target.
id
A string uniquely identifying the target. The format is unspecified and should not be interpreted by clients.
type
A string specifying the type of the target. The value is one of EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY, OBJECT_LIBRARY, or UTILITY.
backtrace
Optional member that is present when a CMake language backtrace to the command in the source code that created the target is available. The value is an unsigned integer 0-based index into the backtraceGraph member’s nodes array.
folder

Optional member that is present when the FOLDER target property is set. The value is a JSON object with one member:

name
A string specifying the name of the target folder.
paths

A JSON object containing members:

source
A string specifying the path to the target’s source directory, represented with forward slashes. If the directory is inside the top-level source directory then the path is specified relative to that directory (with . for the top-level source directory itself). Otherwise the path is absolute.
build
A string specifying the path to the target’s build directory, represented with forward slashes. If the directory is inside the top-level build directory then the path is specified relative to that directory (with . for the top-level build directory itself). Otherwise the path is absolute.
nameOnDisk
Optional member that is present for executable and library targets that are linked or archived into a single primary artifact. The value is a string specifying the file name of that artifact on disk.
artifacts

Optional member that is present for executable and library targets that produce artifacts on disk meant for consumption by dependents. The value is a JSON array of entries corresponding to the artifacts. Each entry is a JSON object containing one member:

path
A string specifying the path to the file on disk, represented with forward slashes. If the file is inside the top-level build directory then the path is specified relative to that directory. Otherwise the path is absolute.
isGeneratorProvided
Optional member that is present with boolean value true if the target is provided by CMake’s build system generator rather than by a command in the source code.
install

Optional member that is present when the target has an install() rule. The value is a JSON object with members:

prefix

A JSON object specifying the installation prefix. It has one member:

path
A string specifying the value of CMAKE_INSTALL_PREFIX.
destinations

A JSON array of entries specifying an install destination path. Each entry is a JSON object with members:

path
A string specifying the install destination path. The path may be absolute or relative to the install prefix.
backtrace
Optional member that is present when a CMake language backtrace to the install() command invocation that specified this destination is available. The value is an unsigned integer 0-based index into the backtraceGraph member’s nodes array.
link

Optional member that is present for executables and shared library targets that link into a runtime binary. The value is a JSON object with members describing the link step:

language
A string specifying the language (e.g. C, CXX, Fortran) of the toolchain is used to invoke the linker.
commandFragments

Optional member that is present when fragments of the link command line invocation are available. The value is a JSON array of entries specifying ordered fragments. Each entry is a JSON object with members:

fragment
A string specifying a fragment of the link command line invocation. The value is encoded in the build system’s native shell format.
role

A string specifying the role of the fragment’s content:

  • flags: link flags.
  • libraries: link library file paths or flags.
  • libraryPath: library search path flags.
  • frameworkPath: macOS framework search path flags.
lto
Optional member that is present with boolean value true when link-time optimization (a.k.a. interprocedural optimization or link-time code generation) is enabled.
sysroot

Optional member that is present when the CMAKE_SYSROOT_LINK or CMAKE_SYSROOT variable is defined. The value is a JSON object with one member:

path
A string specifying the absolute path to the sysroot, represented with forward slashes.
archive

Optional member that is present for static library targets. The value is a JSON object with members describing the archive step:

commandFragments

Optional member that is present when fragments of the archiver command line invocation are available. The value is a JSON array of entries specifying the fragments. Each entry is a JSON object with members:

fragment
A string specifying a fragment of the archiver command line invocation. The value is encoded in the build system’s native shell format.
role

A string specifying the role of the fragment’s content:

  • flags: archiver flags.
lto
Optional member that is present with boolean value true when link-time optimization (a.k.a. interprocedural optimization or link-time code generation) is enabled.
dependencies

Optional member that is present when the target depends on other targets. The value is a JSON array of entries corresponding to the dependencies. Each entry is a JSON object with members:

id
A string uniquely identifying the target on which this target depends. This matches the main id member of the other target.
backtrace
Optional member that is present when a CMake language backtrace to the add_dependencies(), target_link_libraries(), or other command invocation that created this dependency is available. The value is an unsigned integer 0-based index into the backtraceGraph member’s nodes array.
sources

A JSON array of entries corresponding to the target’s source files. Each entry is a JSON object with members:

path
A string specifying the path to the source file on disk, represented with forward slashes. If the file is inside the top-level source directory then the path is specified relative to that directory. Otherwise the path is absolute.
compileGroupIndex
Optional member that is present when the source is compiled. The value is an unsigned integer 0-based index into the compileGroups array.
sourceGroupIndex
Optional member that is present when the source is part of a source group either via the source_group() command or by default. The value is an unsigned integer 0-based index into the sourceGroups array.
isGenerated
Optional member that is present with boolean value true if the source is GENERATED.
backtrace
Optional member that is present when a CMake language backtrace to the target_sources(), add_executable(), add_library(), add_custom_target(), or other command invocation that added this source to the target is available. The value is an unsigned integer 0-based index into the backtraceGraph member’s nodes array.
sourceGroups

Optional member that is present when sources are grouped together by the source_group() command or by default. The value is a JSON array of entries corresponding to the groups. Each entry is a JSON object with members:

name
A string specifying the name of the source group.
sourceIndexes
A JSON array listing the sources belonging to the group. Each entry is an unsigned integer 0-based index into the main sources array for the target.
compileGroups

Optional member that is present when the target has sources that compile. The value is a JSON array of entries corresponding to groups of sources that all compile with the same settings. Each entry is a JSON object with members:

sourceIndexes
A JSON array listing the sources belonging to the group. Each entry is an unsigned integer 0-based index into the main sources array for the target.
language
A string specifying the language (e.g. C, CXX, Fortran) of the toolchain is used to compile the source file.
compileCommandFragments

Optional member that is present when fragments of the compiler command line invocation are available. The value is a JSON array of entries specifying ordered fragments. Each entry is a JSON object with one member:

fragment
A string specifying a fragment of the compile command line invocation. The value is encoded in the build system’s native shell format.
includes

Optional member that is present when there are include directories. The value is a JSON array with an entry for each directory. Each entry is a JSON object with members:

path
A string specifying the path to the include directory, represented with forward slashes.
isSystem
Optional member that is present with boolean value true if the include directory is marked as a system include directory.
backtrace
Optional member that is present when a CMake language backtrace to the target_include_directories() or other command invocation that added this include directory is available. The value is an unsigned integer 0-based index into the backtraceGraph member’s nodes array.
defines

Optional member that is present when there are preprocessor definitions. The value is a JSON array with an entry for each definition. Each entry is a JSON object with members:

define
A string specifying the preprocessor definition in the format <name>[=<value>], e.g. DEF or DEF=1.
backtrace
Optional member that is present when a CMake language backtrace to the target_compile_definitions() or other command invocation that added this preprocessor definition is available. The value is an unsigned integer 0-based index into the backtraceGraph member’s nodes array.
sysroot

Optional member that is present when the CMAKE_SYSROOT_COMPILE or CMAKE_SYSROOT variable is defined. The value is a JSON object with one member:

path
A string specifying the absolute path to the sysroot, represented with forward slashes.
backtraceGraph

A JSON object describing the graph of backtraces whose nodes are referenced from backtrace members elsewhere. The members are:

nodes

A JSON array listing nodes in the backtrace graph. Each entry is a JSON object with members:

file
An unsigned integer 0-based index into the backtrace files array.
line
An optional member present when the node represents a line within the file. The value is an unsigned integer 1-based line number.
command
An optional member present when the node represents a command invocation within the file. The value is an unsigned integer 0-based index into the backtrace commands array.
parent
An optional member present when the node is not the bottom of the call stack. The value is an unsigned integer 0-based index of another entry in the backtrace nodes array.
commands
A JSON array listing command names referenced by backtrace nodes. Each entry is a string specifying a command name.
files
A JSON array listing CMake language files referenced by backtrace nodes. Each entry is a string specifying the path to a file, represented with forward slashes. If the file is inside the top-level source directory then the path is specified relative to that directory. Otherwise the path is absolute.

Object Kind “cache”

The cache object kind lists cache entries. These are the Variables stored in the persistent cache (CMakeCache.txt) for the build tree.

There is only one cache object major version, version 2. Version 1 does not exist to avoid confusion with that from cmake-server(7) mode.

“cache” version 2

cache object version 2 is a JSON object:

{
  "kind": "cache",
  "version": { "major": 2, "minor": 0 },
  "entries": [
    {
      "name": "BUILD_SHARED_LIBS",
      "value": "ON",
      "type": "BOOL",
      "properties": [
        {
          "name": "HELPSTRING",
          "value": "Build shared libraries"
        }
      ]
    },
    {
      "name": "CMAKE_GENERATOR",
      "value": "Unix Makefiles",
      "type": "INTERNAL",
      "properties": [
        {
          "name": "HELPSTRING",
          "value": "Name of generator."
        }
      ]
    }
  ]
}

The members specific to cache objects are:

entries

A JSON array whose entries are each a JSON object specifying a cache entry. The members of each entry are:

name
A string specifying the name of the entry.
value
A string specifying the value of the entry.
type
A string specifying the type of the entry used by cmake-gui(1) to choose a widget for editing.
properties

A JSON array of entries specifying associated cache entry properties. Each entry is a JSON object containing members:

name
A string specifying the name of the cache entry property.
value
A string specifying the value of the cache entry property.

Object Kind “cmakeFiles”

The cmakeFiles object kind lists files used by CMake while configuring and generating the build system. These include the CMakeLists.txt files as well as included .cmake files.

There is only one cmakeFiles object major version, version 1.

“cmakeFiles” version 1

cmakeFiles object version 1 is a JSON object:

{
  "kind": "cmakeFiles",
  "version": { "major": 1, "minor": 0 },
  "paths": {
    "build": "/path/to/top-level-build-dir",
    "source": "/path/to/top-level-source-dir"
  },
  "inputs": [
    {
      "path": "CMakeLists.txt"
    },
    {
      "isGenerated": true,
      "path": "/path/to/top-level-build-dir/.../CMakeSystem.cmake"
    },
    {
      "isExternal": true,
      "path": "/path/to/external/third-party/module.cmake"
    },
    {
      "isCMake": true,
      "isExternal": true,
      "path": "/path/to/cmake/Modules/CMakeGenericSystem.cmake"
    }
  ]
}

The members specific to cmakeFiles objects are:

paths

A JSON object containing members:

source
A string specifying the absolute path to the top-level source directory, represented with forward slashes.
build
A string specifying the absolute path to the top-level build directory, represented with forward slashes.
inputs

A JSON array whose entries are each a JSON object specifying an input file used by CMake when configuring and generating the build system. The members of each entry are:

path
A string specifying the path to an input file to CMake, represented with forward slashes. If the file is inside the top-level source directory then the path is specified relative to that directory. Otherwise the path is absolute.
isGenerated
Optional member that is present with boolean value true if the path specifies a file that is under the top-level build directory and the build is out-of-source. This member is not available on in-source builds.
isExternal
Optional member that is present with boolean value true if the path specifies a file that is not under the top-level source or build directories.
isCMake
Optional member that is present with boolean value true if the path specifies a file in the CMake installation.


cmake-generator-expressions(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-generator-expressions(7)

Contents

  • cmake-generator-expressions(7)
    • Introduction
    • Boolean Generator Expressions
      • Logical Operators
      • String Comparisons
      • Variable Queries
    • String-Valued Generator Expressions
      • Escaped Characters
      • Conditional Expressions
      • String Transformations
      • Variable Queries
      • Target-Dependent Queries
      • Output-Related Expressions
    • Debugging

Introduction

Generator expressions are evaluated during build system generation to produce information specific to each build configuration.

Generator expressions are allowed in the context of many target properties, such as LINK_LIBRARIES, INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and others. They may also be used when using commands to populate those properties, such as target_link_libraries(), target_include_directories(), target_compile_definitions() and others.

They enable conditional linking, conditional definitions used when compiling, conditional include directories, and more. The conditions may be based on the build configuration, target properties, platform information or any other queryable information.

Generator expressions have the form $<...>. To avoid confusion, this page deviates from most of the CMake documentation in that it omits angular brackets <...> around placeholders like condition, string, target, among others.

Generator expressions can be nested, as shown in most of the examples below.

Boolean Generator Expressions

Boolean expressions evaluate to either 0 or 1. They are typically used to construct the condition in a conditional generator expression.

Available boolean expressions are:

Logical Operators

$<BOOL:string>

Converts string to 0 or 1 according to the rules of the if() command. Evaluates to 0 if any of the following is true:

  • string is empty,
  • string is a case-insensitive equal of 0, FALSE, OFF, N, NO, IGNORE, or NOTFOUND, or
  • string ends in the suffix -NOTFOUND (case-sensitive).

Otherwise evaluates to 1.

$<AND:conditions>
where conditions is a comma-separated list of boolean expressions. Evaluates to 1 if all conditions are 1. Otherwise evaluates to 0.
$<OR:conditions>
where conditions is a comma-separated list of boolean expressions. Evaluates to 1 if at least one of the conditions is 1. Otherwise evaluates to 0.
$<NOT:condition>
0 if condition is 1, else 1.

String Comparisons

$<STREQUAL:string1,string2>

1 if string1 and string2 are equal, else 0. The comparison is case-sensitive. For a case-insensitive comparison, combine with a string transforming generator expression,

$<STREQUAL:$<UPPER_CASE:${foo}>,"BAR"> # "1" if ${foo} is any of "BAR", "Bar", "bar", ...
$<EQUAL:value1,value2>
1 if value1 and value2 are numerically equal, else 0.
$<IN_LIST:string,list>
1 if string is member of the comma-separated list, else 0. Uses case-sensitive comparisons.
$<VERSION_LESS:v1,v2>
1 if v1 is a version less than v2, else 0.
$<VERSION_GREATER:v1,v2>
1 if v1 is a version greater than v2, else 0.
$<VERSION_EQUAL:v1,v2>
1 if v1 is the same version as v2, else 0.
$<VERSION_LESS_EQUAL:v1,v2>
1 if v1 is a version less than or equal to v2, else 0.
$<VERSION_GREATER_EQUAL:v1,v2>
1 if v1 is a version greater than or equal to v2, else 0.

Variable Queries

$<TARGET_EXISTS:target>
1 if target exists, else 0.
$<CONFIG:cfg>
1 if config is cfg, else 0. This is a case-insensitive comparison. The mapping in MAP_IMPORTED_CONFIG_<CONFIG> is also considered by this expression when it is evaluated on a property on an IMPORTED target.
$<PLATFORM_ID:platform_id>
1 if the CMake-id of the platform matches platform_id otherwise 0. See also the CMAKE_SYSTEM_NAME variable.
$<C_COMPILER_ID:compiler_id>
1 if the CMake-id of the C compiler matches compiler_id, otherwise 0. See also the CMAKE_<LANG>_COMPILER_ID variable.
$<CXX_COMPILER_ID:compiler_id>
1 if the CMake-id of the CXX compiler matches compiler_id, otherwise 0. See also the CMAKE_<LANG>_COMPILER_ID variable.
$<Fortran_COMPILER_ID:compiler_id>
1 if the CMake-id of the Fortran compiler matches compiler_id, otherwise 0. See also the CMAKE_<LANG>_COMPILER_ID variable.
$<C_COMPILER_VERSION:version>
1 if the version of the C compiler matches version, otherwise 0. See also the CMAKE_<LANG>_COMPILER_VERSION variable.
$<CXX_COMPILER_VERSION:version>
1 if the version of the CXX compiler matches version, otherwise 0. See also the CMAKE_<LANG>_COMPILER_VERSION variable.
$<Fortran_COMPILER_VERSION:version>
1 if the version of the Fortran compiler matches version, otherwise 0. See also the CMAKE_<LANG>_COMPILER_VERSION variable.
$<TARGET_POLICY:policy>
1 if the policy was NEW when the ‘head’ target was created, else 0. If the policy was not set, the warning message for the policy will be emitted. This generator expression only works for a subset of policies.
$<COMPILE_FEATURES:features>
where features is a comma-spearated list. Evaluates to 1 if all of the features are available for the ‘head’ target, and 0 otherwise. If this expression is used while evaluating the link implementation of a target and if any dependency transitively increases the required C_STANDARD or CXX_STANDARD for the ‘head’ target, an error is reported. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.
$<COMPILE_LANGUAGE:language>

1 when the language used for compilation unit matches language, otherwise 0. This expression may be used to specify compile options, compile definitions, and include directories for source files of a particular language in a target. For example:

add_executable(myapp main.cpp foo.c bar.cpp zot.cu)
target_compile_options(myapp
  PRIVATE $<$<COMPILE_LANGUAGE:CXX>:-fno-exceptions>
)
target_compile_definitions(myapp
  PRIVATE $<$<COMPILE_LANGUAGE:CXX>:COMPILING_CXX>
          $<$<COMPILE_LANGUAGE:CUDA>:COMPILING_CUDA>
)
target_include_directories(myapp
  PRIVATE $<$<COMPILE_LANGUAGE:CXX>:/opt/foo/cxx_headers>
)

This specifies the use of the -fno-exceptions compile option, COMPILING_CXX compile definition, and cxx_headers include directory for C++ only (compiler id checks elided). It also specifies a COMPILING_CUDA compile definition for CUDA.

Note that with Visual Studio Generators and Xcode there is no way to represent target-wide compile definitions or include directories separately for C and CXX languages. Also, with Visual Studio Generators there is no way to represent target-wide flags separately for C and CXX languages. Under these generators, expressions for both C and C++ sources will be evaluated using CXX if there are any C++ sources and otherwise using C. A workaround is to create separate libraries for each source file language instead:

add_library(myapp_c foo.c)
add_library(myapp_cxx bar.cpp)
target_compile_options(myapp_cxx PUBLIC -fno-exceptions)
add_executable(myapp main.cpp)
target_link_libraries(myapp myapp_c myapp_cxx)

String-Valued Generator Expressions

These expressions expand to some string. For example,

include_directories(/usr/include/$<CXX_COMPILER_ID>/)

expands to /usr/include/GNU/ or /usr/include/Clang/ etc, depending on the compiler identifier.

String-valued expressions may also be combined with other expressions. Here an example for a string-valued expression within a boolean expressions within a conditional expression:

$<$<VERSION_LESS:$<CXX_COMPILER_VERSION>,4.2.0>:OLD_COMPILER>

expands to OLD_COMPILER if the CMAKE_CXX_COMPILER_VERSION is less than 4.2.0.

And here two nested string-valued expressions:

-I$<JOIN:$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>, -I>

generates a string of the entries in the INCLUDE_DIRECTORIES target property with each entry preceded by -I.

Expanding on the previous example, if one first wants to check if the INCLUDE_DIRECTORIES property is non-empty, then it is advisable to introduce a helper variable to keep the code readable:

set(prop "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>") # helper variable
$<$<BOOL:${prop}>:-I$<JOIN:${prop}, -I>>

The following string-valued generator expressions are available:

Escaped Characters

String literals to escape the special meaning a character would otherwise have:

$<ANGLE-R>
A literal >. Used for example to compare strings that contain a >.
$<COMMA>
A literal ,. Used for example to compare strings which contain a ,.
$<SEMICOLON>
A literal ;. Used to prevent list expansion on an argument with ;.

Conditional Expressions

Conditional generator expressions depend on a boolean condition that must be 0 or 1.

$<condition:true_string>
Evaluates to true_string if condition is 1. Otherwise evaluates to the empty string.
$<IF:condition,true_string,false_string>
Evaluates to true_string if condition is 1. Otherwise evaluates to false_string.

Typically, the condition is a boolean generator expression. For instance,

$<$<CONFIG:Debug>:DEBUG_MODE>

expands to DEBUG_MODE when the Debug configuration is used, and otherwise expands to the empty string.

String Transformations

$<JOIN:list,string>
Joins the list with the content of string.
$<LOWER_CASE:string>
Content of string converted to lower case.
$<UPPER_CASE:string>
Content of string converted to upper case.
$<GENEX_EVAL:expr>
Content of expr evaluated as a generator expression in the current context. This enables consumption of generator expressions whose evaluation results itself in generator expressions.
$<TARGET_GENEX_EVAL:tgt,expr>

Content of expr evaluated as a generator expression in the context of tgt target. This enables consumption of custom target properties that themselves contain generator expressions.

Having the capability to evaluate generator expressions is very useful when you want to manage custom properties supporting generator expressions. For example:

add_library(foo ...)

set_property(TARGET foo PROPERTY
  CUSTOM_KEYS $<$<CONFIG:DEBUG>:FOO_EXTRA_THINGS>
)

add_custom_target(printFooKeys
  COMMAND ${CMAKE_COMMAND} -E echo $<TARGET_PROPERTY:foo,CUSTOM_KEYS>
)

This naive implementation of the printFooKeys custom command is wrong because CUSTOM_KEYS target property is not evaluated and the content is passed as is (i.e. $<$<CONFIG:DEBUG>:FOO_EXTRA_THINGS>).

To have the expected result (i.e. FOO_EXTRA_THINGS if config is Debug), it is required to evaluate the output of $<TARGET_PROPERTY:foo,CUSTOM_KEYS>:

add_custom_target(printFooKeys
  COMMAND ${CMAKE_COMMAND} -E
    echo $<TARGET_GENEX_EVAL:foo,$<TARGET_PROPERTY:foo,CUSTOM_KEYS>>
)

Variable Queries

$<CONFIG>
Configuration name.
$<CONFIGURATION>
Configuration name. Deprecated since CMake 3.0. Use CONFIG instead.
$<PLATFORM_ID>
The CMake-id of the platform. See also the CMAKE_SYSTEM_NAME variable.
$<C_COMPILER_ID>
The CMake-id of the C compiler used. See also the CMAKE_<LANG>_COMPILER_ID variable.
$<CXX_COMPILER_ID>
The CMake-id of the CXX compiler used. See also the CMAKE_<LANG>_COMPILER_ID variable.
$<Fortran_COMPILER_ID>
The CMake-id of the Fortran compiler used. See also the CMAKE_<LANG>_COMPILER_ID variable.
$<C_COMPILER_VERSION>
The version of the C compiler used. See also the CMAKE_<LANG>_COMPILER_VERSION variable.
$<CXX_COMPILER_VERSION>
The version of the CXX compiler used. See also the CMAKE_<LANG>_COMPILER_VERSION variable.
$<Fortran_COMPILER_VERSION>
The version of the Fortran compiler used. See also the CMAKE_<LANG>_COMPILER_VERSION variable.
$<COMPILE_LANGUAGE>
The compile language of source files when evaluating compile options. See the related boolean expression $<COMPILE_LANGUAGE:language> for notes about the portability of this generator expression.

Target-Dependent Queries

$<TARGET_NAME_IF_EXISTS:tgt>
Expands to the tgt if the given target exists, an empty string otherwise.
$<TARGET_FILE:tgt>
Full path to main file (.exe, .so.1.2, .a) where tgt is the name of a target.
$<TARGET_FILE_NAME:tgt>
Name of main file (.exe, .so.1.2, .a).
$<TARGET_FILE_DIR:tgt>
Directory of main file (.exe, .so.1.2, .a).
$<TARGET_LINKER_FILE:tgt>
File used to link (.a, .lib, .so) where tgt is the name of a target.
$<TARGET_LINKER_FILE_NAME:tgt>
Name of file used to link (.a, .lib, .so).
$<TARGET_LINKER_FILE_DIR:tgt>
Directory of file used to link (.a, .lib, .so).
$<TARGET_SONAME_FILE:tgt>
File with soname (.so.3) where tgt is the name of a target.
$<TARGET_SONAME_FILE_NAME:tgt>
Name of file with soname (.so.3).
$<TARGET_SONAME_FILE_DIR:tgt>
Directory of with soname (.so.3).
$<TARGET_PDB_FILE:tgt>

Full path to the linker generated program database file (.pdb) where tgt is the name of a target.

See also the PDB_NAME and PDB_OUTPUT_DIRECTORY target properties and their configuration specific variants PDB_NAME_<CONFIG> and PDB_OUTPUT_DIRECTORY_<CONFIG>.

$<TARGET_PDB_FILE_NAME:tgt>
Name of the linker generated program database file (.pdb).
$<TARGET_PDB_FILE_DIR:tgt>
Directory of the linker generated program database file (.pdb).
$<TARGET_BUNDLE_DIR:tgt>
Full path to the bundle directory (my.app, my.framework, or my.bundle) where tgt is the name of a target.
$<TARGET_BUNDLE_CONTENT_DIR:tgt>
Full path to the bundle content directory where tgt is the name of a target. For the macOS SDK it leads to my.app/Contents, my.framework, or my.bundle/Contents. For all other SDKs (e.g. iOS) it leads to my.app, my.framework, or my.bundle due to the flat bundle structure.
$<TARGET_PROPERTY:tgt,prop>

Value of the property prop on the target tgt.

Note that tgt is not added as a dependency of the target this expression is evaluated on.

$<TARGET_PROPERTY:prop>
Value of the property prop on the target on which the generator expression is evaluated. Note that for generator expressions in Transitive Usage Requirements this is the value of the property on the consuming target rather than the target specifying the requirement.
$<INSTALL_PREFIX>
Content of the install prefix when the target is exported via install(EXPORT) and empty otherwise.

Output-Related Expressions

$<TARGET_NAME:...>
Marks ... as being the name of a target. This is required if exporting targets to multiple dependent export sets. The ... must be a literal name of a target- it may not contain generator expressions.
$<LINK_ONLY:...>
Content of ... except when evaluated in a link interface while propagating Transitive Usage Requirements, in which case it is the empty string. Intended for use only in an INTERFACE_LINK_LIBRARIES target property, perhaps via the target_link_libraries() command, to specify private link dependencies without other usage requirements.
$<INSTALL_INTERFACE:...>
Content of ... when the property is exported using install(EXPORT), and empty otherwise.
$<BUILD_INTERFACE:...>
Content of ... when the property is exported using export(), or when the target is used by another target in the same buildsystem. Expands to the empty string otherwise.
$<MAKE_C_IDENTIFIER:...>
Content of ... converted to a C identifier. The conversion follows the same behavior as string(MAKE_C_IDENTIFIER).
$<TARGET_OBJECTS:objLib>
List of objects resulting from build of objLib. objLib must be an object of type OBJECT_LIBRARY.
$<SHELL_PATH:...>
Content of ... converted to shell path style. For example, slashes are converted to backslashes in Windows shells and drive letters are converted to posix paths in MSYS shells. The ... must be an absolute path.

Debugging

Since generator expressions are evaluated during generation of the buildsystem, and not during processing of CMakeLists.txt files, it is not possible to inspect their result with the message() command.

One possible way to generate debug messages is to add a custom target,

add_custom_target(genexdebug COMMAND ${CMAKE_COMMAND} -E echo "$<...>")

The shell command make genexdebug (invoked after execution of cmake) would then print the result of $<...>.

Another way is to write debug messages to a file:

file(GENERATE OUTPUT filename CONTENT "$<...>")


cmake-generators(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-generators(7)

Contents

  • cmake-generators(7)
    • Introduction
    • CMake Generators
      • Command-Line Build Tool Generators
        • Makefile Generators
        • Ninja Generator
      • IDE Build Tool Generators
        • Visual Studio Generators
        • Other Generators
    • Extra Generators

Introduction

A CMake Generator is responsible for writing the input files for a native build system. Exactly one of the CMake Generators must be selected for a build tree to determine what native build system is to be used. Optionally one of the Extra Generators may be selected as a variant of some of the Command-Line Build Tool Generators to produce project files for an auxiliary IDE.

CMake Generators are platform-specific so each may be available only on certain platforms. The cmake(1) command-line tool --help output lists available generators on the current platform. Use its -G option to specify the generator for a new build tree. The cmake-gui(1) offers interactive selection of a generator when creating a new build tree.

CMake Generators

Command-Line Build Tool Generators

These generators support command-line build tools. In order to use them, one must launch CMake from a command-line prompt whose environment is already configured for the chosen compiler and build tool.

Makefile Generators

  • Borland Makefiles
  • MSYS Makefiles
  • MinGW Makefiles
  • NMake Makefiles
  • NMake Makefiles JOM
  • Unix Makefiles
  • Watcom WMake

Ninja Generator

  • Ninja

IDE Build Tool Generators

These generators support Integrated Development Environment (IDE) project files. Since the IDEs configure their own environment one may launch CMake from any environment.

Visual Studio Generators

  • Visual Studio 6
  • Visual Studio 7
  • Visual Studio 7 .NET 2003
  • Visual Studio 8 2005
  • Visual Studio 9 2008
  • Visual Studio 10 2010
  • Visual Studio 11 2012
  • Visual Studio 12 2013
  • Visual Studio 14 2015
  • Visual Studio 15 2017
  • Visual Studio 16 2019

Other Generators

  • Green Hills MULTI
  • Xcode

Extra Generators

Some of the CMake Generators listed in the cmake(1) command-line tool --help output may have variants that specify an extra generator for an auxiliary IDE tool. Such generator names have the form <extra-generator> - <main-generator>. The following extra generators are known to CMake.

  • CodeBlocks
  • CodeLite
  • Eclipse CDT4
  • Kate
  • Sublime Text 2


Borland Makefiles — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Borland Makefiles

Generates Borland makefiles.

  • cmake-generators(7) »


MSYS Makefiles — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

MSYS Makefiles

Generates makefiles for use with MSYS make under the MSYS shell.

Use this generator in a MSYS shell prompt and using make as the build tool. The generated makefiles use /bin/sh as the shell to launch build rules. They are not compatible with a Windows command prompt.

To build under a Windows command prompt, use the MinGW Makefiles generator.

  • cmake-generators(7) »


MinGW Makefiles — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

MinGW Makefiles

Generates makefiles for use with mingw32-make under a Windows command prompt.

Use this generator under a Windows command prompt with MinGW in the PATH and using mingw32-make as the build tool. The generated makefiles use cmd.exe as the shell to launch build rules. They are not compatible with MSYS or a unix shell.

To build under the MSYS shell, use the MSYS Makefiles generator.

  • cmake-generators(7) »


NMake Makefiles — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

NMake Makefiles

Generates NMake makefiles.

  • cmake-generators(7) »


NMake Makefiles JOM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

NMake Makefiles JOM

Generates JOM makefiles.

  • cmake-generators(7) »


Unix Makefiles — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Unix Makefiles

Generates standard UNIX makefiles.

A hierarchy of UNIX makefiles is generated into the build tree. Any standard UNIX-style make program can build the project through the default make target. A “make install” target is also provided.

  • cmake-generators(7) »


Watcom WMake — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Watcom WMake

Generates Watcom WMake makefiles.

  • cmake-generators(7) »


Ninja — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Ninja

Generates build.ninja files.

A build.ninja file is generated into the build tree. Recent versions of the ninja program can build the project through the “all” target. An “install” target is also provided.

For each subdirectory sub/dir of the project, additional targets are generated:

sub/dir/all
Depends on all targets required by the subdirectory.
sub/dir/install
Runs the install step in the subdirectory, if any.
sub/dir/test
Runs the test step in the subdirectory, if any.
sub/dir/package
Runs the package step in the subdirectory, if any.

Fortran Support

The Ninja generator conditionally supports Fortran when the ninja tool has the required features. As of this version of CMake the needed features have not been integrated into upstream Ninja. Kitware maintains a branch of Ninja with the required features on github.com/Kitware/ninja.

  • cmake-generators(7) »


Visual Studio 6 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 6

Removed. This once generated Visual Studio 6 project files, but the generator has been removed since CMake 3.6. It is still possible to build with VS 6 tools using the NMake Makefiles generator.

  • cmake-generators(7) »


Visual Studio 7 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 7

Removed. This once generated Visual Studio .NET 2002 project files, but the generator has been removed since CMake 3.6. It is still possible to build with VS 7.0 tools using the NMake Makefiles generator.

  • cmake-generators(7) »


Visual Studio 7 .NET 2003 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 7 .NET 2003

Removed. This once generated Visual Studio .NET 2003 project files, but the generator has been removed since CMake 3.9. It is still possible to build with VS 7.1 tools using the NMake Makefiles generator.

  • cmake-generators(7) »


Visual Studio 8 2005 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 8 2005

Removed. This once generated Visual Studio 8 2005 project files, but the generator has been removed since CMake 3.12. It is still possible to build with VS 2005 tools using the NMake Makefiles generator.

  • cmake-generators(7) »


Visual Studio 9 2008 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 9 2008

Generates Visual Studio 9 2008 project files.

Platform Selection

The default target platform name (architecture) is Win32.

The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -A option, to specify a target platform name (architecture). For example:

  • cmake -G "Visual Studio 9 2008" -A Win32
  • cmake -G "Visual Studio 9 2008" -A x64
  • cmake -G "Visual Studio 9 2008" -A Itanium
  • cmake -G "Visual Studio 9 2008" -A <WinCE-SDK> (Specify a target platform matching a Windows CE SDK name.)

For compatibility with CMake versions prior to 3.1, one may specify a target platform name optionally at the end of the generator name. This is supported only for:

Visual Studio 9 2008 Win64
Specify target platform x64.
Visual Studio 9 2008 IA64
Specify target platform Itanium.
Visual Studio 9 2008 <WinCE-SDK>
Specify target platform matching a Windows CE SDK name.

  • cmake-generators(7) »


Visual Studio 10 2010 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 10 2010

Generates Visual Studio 10 (VS 2010) project files.

For compatibility with CMake versions prior to 3.0, one may specify this generator using the name Visual Studio 10 without the year component.

Project Types

Only Visual C++ and C# projects may be generated. Other types of projects (Database, Website, etc.) are not supported.

Platform Selection

The default target platform name (architecture) is Win32.

The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -A option, to specify a target platform name (architecture). For example:

  • cmake -G "Visual Studio 10 2010" -A Win32
  • cmake -G "Visual Studio 10 2010" -A x64
  • cmake -G "Visual Studio 10 2010" -A Itanium

For compatibility with CMake versions prior to 3.1, one may specify a target platform name optionally at the end of the generator name. This is supported only for:

Visual Studio 10 2010 Win64
Specify target platform x64.
Visual Studio 10 2010 IA64
Specify target platform Itanium.

Toolset Selection

The v100 toolset that comes with Visual Studio 10 2010 is selected by default. The CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

  • cmake-generators(7) »


Visual Studio 11 2012 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 11 2012

Generates Visual Studio 11 (VS 2012) project files.

For compatibility with CMake versions prior to 3.0, one may specify this generator using the name “Visual Studio 11” without the year component.

Project Types

Only Visual C++ and C# projects may be generated. Other types of projects (JavaScript, Database, Website, etc.) are not supported.

Platform Selection

The default target platform name (architecture) is Win32.

The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -A option, to specify a target platform name (architecture). For example:

  • cmake -G "Visual Studio 11 2012" -A Win32
  • cmake -G "Visual Studio 11 2012" -A x64
  • cmake -G "Visual Studio 11 2012" -A ARM
  • cmake -G "Visual Studio 11 2012" -A <WinCE-SDK> (Specify a target platform matching a Windows CE SDK name.)

For compatibility with CMake versions prior to 3.1, one may specify a target platform name optionally at the end of the generator name. This is supported only for:

Visual Studio 11 2012 Win64
Specify target platform x64.
Visual Studio 11 2012 ARM
Specify target platform ARM.
Visual Studio 11 2012 <WinCE-SDK>
Specify target platform matching a Windows CE SDK name.

Toolset Selection

The v110 toolset that comes with Visual Studio 11 2012 is selected by default. The CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

  • cmake-generators(7) »


Visual Studio 12 2013 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 12 2013

Generates Visual Studio 12 (VS 2013) project files.

For compatibility with CMake versions prior to 3.0, one may specify this generator using the name “Visual Studio 12” without the year component.

Project Types

Only Visual C++ and C# projects may be generated. Other types of projects (JavaScript, Powershell, Python, etc.) are not supported.

Platform Selection

The default target platform name (architecture) is Win32.

The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -A option, to specify a target platform name (architecture). For example:

  • cmake -G "Visual Studio 12 2013" -A Win32
  • cmake -G "Visual Studio 12 2013" -A x64
  • cmake -G "Visual Studio 12 2013" -A ARM

For compatibility with CMake versions prior to 3.1, one may specify a target platform name optionally at the end of the generator name. This is supported only for:

Visual Studio 12 2013 Win64
Specify target platform x64.
Visual Studio 12 2013 ARM
Specify target platform ARM.

Toolset Selection

The v120 toolset that comes with Visual Studio 12 2013 is selected by default. The CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

For each toolset that comes with this version of Visual Studio, there are variants that are themselves compiled for 32-bit (x86) and 64-bit (x64) hosts (independent of the architecture they target). By default this generator uses the 32-bit variant even on a 64-bit host. One may explicitly request use of either the 32-bit or 64-bit host tools by adding either host=x86 or host=x64 to the toolset specification. See the CMAKE_GENERATOR_TOOLSET variable for details.

  • cmake-generators(7) »


Visual Studio 14 2015 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 14 2015

Generates Visual Studio 14 (VS 2015) project files.

Project Types

Only Visual C++ and C# projects may be generated. Other types of projects (JavaScript, Powershell, Python, etc.) are not supported.

Platform Selection

The default target platform name (architecture) is Win32.

The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -A option, to specify a target platform name (architecture). For example:

  • cmake -G "Visual Studio 14 2015" -A Win32
  • cmake -G "Visual Studio 14 2015" -A x64
  • cmake -G "Visual Studio 14 2015" -A ARM

For compatibility with CMake versions prior to 3.1, one may specify a target platform name optionally at the end of the generator name. This is supported only for:

Visual Studio 14 2015 Win64
Specify target platform x64.
Visual Studio 14 2015 ARM
Specify target platform ARM.

Toolset Selection

The v140 toolset that comes with Visual Studio 14 2015 is selected by default. The CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

For each toolset that comes with this version of Visual Studio, there are variants that are themselves compiled for 32-bit (x86) and 64-bit (x64) hosts (independent of the architecture they target). By default this generator uses the 32-bit variant even on a 64-bit host. One may explicitly request use of either the 32-bit or 64-bit host tools by adding either host=x86 or host=x64 to the toolset specification. See the CMAKE_GENERATOR_TOOLSET variable for details.

  • cmake-generators(7) »


Visual Studio 15 2017 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 15 2017

Generates Visual Studio 15 (VS 2017) project files.

Project Types

Only Visual C++ and C# projects may be generated. Other types of projects (JavaScript, Powershell, Python, etc.) are not supported.

Instance Selection

VS 2017 supports multiple installations on the same machine. The CMAKE_GENERATOR_INSTANCE variable may be set as a cache entry containing the absolute path to a Visual Studio instance. If the value 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.

When CMake first chooses an instance, if the VS150COMNTOOLS environment variable is set and points to the Common7/Tools directory within one of the instances, that instance will be used. Otherwise, if more than one instance is installed we do not define which one is chosen by default.

Platform Selection

The default target platform name (architecture) is Win32.

The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -A option, to specify a target platform name (architecture). For example:

  • cmake -G "Visual Studio 15 2017" -A Win32
  • cmake -G "Visual Studio 15 2017" -A x64
  • cmake -G "Visual Studio 15 2017" -A ARM
  • cmake -G "Visual Studio 15 2017" -A ARM64

For compatibility with CMake versions prior to 3.1, one may specify a target platform name optionally at the end of the generator name. This is supported only for:

Visual Studio 15 2017 Win64
Specify target platform x64.
Visual Studio 15 2017 ARM
Specify target platform ARM.

Toolset Selection

The v141 toolset that comes with Visual Studio 15 2017 is selected by default. The CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

For each toolset that comes with this version of Visual Studio, there are variants that are themselves compiled for 32-bit (x86) and 64-bit (x64) hosts (independent of the architecture they target). By default this generator uses the 32-bit variant even on a 64-bit host. One may explicitly request use of either the 32-bit or 64-bit host tools by adding either host=x86 or host=x64 to the toolset specification. See the CMAKE_GENERATOR_TOOLSET variable for details.

  • cmake-generators(7) »


Visual Studio 16 2019 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Visual Studio 16 2019

Generates Visual Studio 16 (VS 2019) project files.

Project Types

Only Visual C++ and C# projects may be generated. Other types of projects (JavaScript, Powershell, Python, etc.) are not supported.

Instance Selection

VS 2019 supports multiple installations on the same machine. The CMAKE_GENERATOR_INSTANCE variable may be set as a cache entry containing the absolute path to a Visual Studio instance. If the value 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.

When CMake first chooses an instance, if the VS160COMNTOOLS environment variable is set and points to the Common7/Tools directory within one of the instances, that instance will be used. Otherwise, if more than one instance is installed we do not define which one is chosen by default.

Platform Selection

The default target platform name (architecture) is that of the host.

The CMAKE_GENERATOR_PLATFORM variable may be set, perhaps via the cmake(1) -A option, to specify a target platform name (architecture). For example:

  • cmake -G "Visual Studio 16 2019" -A Win32
  • cmake -G "Visual Studio 16 2019" -A x64
  • cmake -G "Visual Studio 16 2019" -A ARM
  • cmake -G "Visual Studio 16 2019" -A ARM64

Toolset Selection

The v142 toolset that comes with Visual Studio 16 2019 is selected by default. The CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

For each toolset that comes with this version of Visual Studio, there are variants that are themselves compiled for 32-bit (x86) and 64-bit (x64) hosts (independent of the architecture they target). By default this generator uses the 64-bit variant on x64 hosts and the 32-bit variant otherwise. One may explicitly request use of either the 32-bit or 64-bit host tools by adding either host=x86 or host=x64 to the toolset specification. See the CMAKE_GENERATOR_TOOLSET variable for details.

  • cmake-generators(7) »


Green Hills MULTI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Green Hills MULTI

Generates Green Hills MULTI project files (experimental, work-in-progress).

The buildsystem has predetermined build-configuration settings that can be controlled via the CMAKE_BUILD_TYPE variable.

Customizations that are used to pick toolset and target system:

The -A <arch> can be supplied for setting the target architecture. <arch> usually is one of “arm”, “ppc”, “86”, etcetera. If the target architecture is not specified then the default architecture of “arm” will be used.

The -T <toolset> option can be used to set the directory location of the toolset. Both absolute and relative paths are valid. Relative paths use GHS_TOOLSET_ROOT as the root. If the toolset is not specified then the latest toolset found in GHS_TOOLSET_ROOT will be used.

Cache variables that are used for toolset and target system customization:

  • GHS_TARGET_PLATFORM

    Defaults to integrity.
    Usual values are integrity, threadx, uvelosity, velosity, vxworks, standalone.

  • GHS_PRIMARY_TARGET

    Sets primaryTarget entry in project file.
    Defaults to <arch>_<GHS_TARGET_PLATFORM>.tgt.

  • GHS_TOOLSET_ROOT

    Root path for toolset searches.
    Defaults to C:/ghs.

  • GHS_OS_ROOT

    Root path for RTOS searches.
    Defaults to C:/ghs.

  • GHS_OS_DIR

    Sets -os_dir entry in project file.
    Defaults to latest platform OS installation at GHS_OS_ROOT. Set this value if a specific RTOS is to be used.

  • GHS_BSP_NAME

    Sets -bsp entry in project file.
    Defaults to sim<arch> for integrity platforms.

Customizations are available through the following cache variables:

  • GHS_CUSTOMIZATION
  • GHS_GPJ_MACROS

The following properties are available:

  • GHS_INTEGRITY_APP
  • GHS_NO_SOURCE_GROUP_FILE

Note

This generator is deemed experimental as of CMake 3.14.0-rc4 and is still a work in progress. Future versions of CMake may make breaking changes as the generator matures.

  • cmake-generators(7) »


Xcode — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Xcode

Generate Xcode project files.

This supports Xcode 3.0 and above. Support for Xcode versions prior to Xcode 5 is deprecated and will be dropped in a future version of CMake.

Toolset Selection

By default Xcode is allowed to select its own default toolchain. The CMAKE_GENERATOR_TOOLSET option may be set, perhaps via the cmake(1) -T option, to specify another toolset.

  • cmake-generators(7) »


CodeBlocks — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

CodeBlocks

Generates CodeBlocks project files.

Project files for CodeBlocks will be created in the top directory and in every subdirectory which features a CMakeLists.txt file containing a PROJECT() call. Additionally a hierarchy of makefiles is generated into the build tree. The CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES variable may be set to ON to exclude any files which are located outside of the project root directory. The appropriate make program can build the project through the default make target. A “make install” target is also provided.

This “extra” generator may be specified as:

CodeBlocks - MinGW Makefiles
Generate with MinGW Makefiles.
CodeBlocks - NMake Makefiles
Generate with NMake Makefiles.
CodeBlocks - NMake Makefiles JOM
Generate with NMake Makefiles JOM.
CodeBlocks - Ninja
Generate with Ninja.
CodeBlocks - Unix Makefiles
Generate with Unix Makefiles.

  • cmake-generators(7) »


CodeLite — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

CodeLite

Generates CodeLite project files.

Project files for CodeLite will be created in the top directory and in every subdirectory which features a CMakeLists.txt file containing a project() call. The CMAKE_CODELITE_USE_TARGETS variable may be set to ON to change the default behaviour from projects to targets as the basis for project files. The appropriate make program can build the project through the default make target. A “make install” target is also provided.

This “extra” generator may be specified as:

CodeLite - MinGW Makefiles
Generate with MinGW Makefiles.
CodeLite - NMake Makefiles
Generate with NMake Makefiles.
CodeLite - Ninja
Generate with Ninja.
CodeLite - Unix Makefiles
Generate with Unix Makefiles.

  • cmake-generators(7) »


Eclipse CDT4 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Eclipse CDT4

Generates Eclipse CDT 4.0 project files.

Project files for Eclipse will be created in the top directory. In out of source builds, a linked resource to the top level source directory will be created. Additionally a hierarchy of makefiles is generated into the build tree. The appropriate make program can build the project through the default make target. A “make install” target is also provided.

This “extra” generator may be specified as:

Eclipse CDT4 - MinGW Makefiles
Generate with MinGW Makefiles.
Eclipse CDT4 - NMake Makefiles
Generate with NMake Makefiles.
Eclipse CDT4 - Ninja
Generate with Ninja.
Eclipse CDT4 - Unix Makefiles
Generate with Unix Makefiles.

  • cmake-generators(7) »


Kate — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Kate

Generates Kate project files.

A project file for Kate will be created in the top directory in the top level build directory. To use it in kate, the Project plugin must be enabled. The project file is loaded in kate simply by opening the ProjectName.kateproject file in the editor. If the kate Build-plugin is enabled, all targets generated by CMake are available for building.

This “extra” generator may be specified as:

Kate - MinGW Makefiles
Generate with MinGW Makefiles.
Kate - NMake Makefiles
Generate with NMake Makefiles.
Kate - Ninja
Generate with Ninja.
Kate - Unix Makefiles
Generate with Unix Makefiles.

  • cmake-generators(7) »


Sublime Text 2 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-generators(7) »

Sublime Text 2

Generates Sublime Text 2 project files.

Project files for Sublime Text 2 will be created in the top directory and in every subdirectory which features a CMakeLists.txt file containing a PROJECT() call. Additionally Makefiles (or build.ninja files) are generated into the build tree. The appropriate make program can build the project through the default make target. A “make install” target is also provided.

This “extra” generator may be specified as:

Sublime Text 2 - MinGW Makefiles
Generate with MinGW Makefiles.
Sublime Text 2 - NMake Makefiles
Generate with NMake Makefiles.
Sublime Text 2 - Ninja
Generate with Ninja.
Sublime Text 2 - Unix Makefiles
Generate with Unix Makefiles.

  • cmake-generators(7) »


cmake-language(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-language(7)

Contents

  • cmake-language(7)
    • Organization
      • Directories
      • Scripts
      • Modules
    • Syntax
      • Encoding
      • Source Files
      • Command Invocations
      • Command Arguments
        • Bracket Argument
        • Quoted Argument
        • Unquoted Argument
      • Escape Sequences
      • Variable References
      • Comments
        • Bracket Comment
        • Line Comment
    • Control Structures
      • Conditional Blocks
      • Loops
      • Command Definitions
    • Variables
    • Environment Variables
    • Lists

Organization

CMake input files are written in the “CMake Language” in source files named CMakeLists.txt or ending in a .cmake file name extension.

CMake Language source files in a project are organized into:

  • Directories (CMakeLists.txt),
  • Scripts (<script>.cmake), and
  • Modules (<module>.cmake).

Directories

When CMake processes a project source tree, the entry point is a source file called CMakeLists.txt in the top-level source directory. This file may contain the entire build specification or use the add_subdirectory() command to add subdirectories to the build. Each subdirectory added by the command must also contain a CMakeLists.txt file as the entry point to that directory. For each source directory whose CMakeLists.txt file is processed CMake generates a corresponding directory in the build tree to act as the default working and output directory.

Scripts

An individual <script>.cmake source file may be processed in script mode by using the cmake(1) command-line tool with the -P option. Script mode simply runs the commands in the given CMake Language source file and does not generate a build system. It does not allow CMake commands that define build targets or actions.

Modules

CMake Language code in either Directories or Scripts may use the include() command to load a <module>.cmake source file in the scope of the including context. See the cmake-modules(7) manual page for documentation of modules included with the CMake distribution. Project source trees may also provide their own modules and specify their location(s) in the CMAKE_MODULE_PATH variable.

Syntax

Encoding

A CMake Language source file may be written in 7-bit ASCII text for maximum portability across all supported platforms. Newlines may be encoded as either \n or \r\n but will be converted to \n as input files are read.

Note that the implementation is 8-bit clean so source files may be encoded as UTF-8 on platforms with system APIs supporting this encoding. In addition, CMake 3.2 and above support source files encoded in UTF-8 on Windows (using UTF-16 to call system APIs). Furthermore, CMake 3.0 and above allow a leading UTF-8 Byte-Order Mark in source files.

Source Files

A CMake Language source file consists of zero or more Command Invocations separated by newlines and optionally spaces and Comments:

file         ::=  file_element*
file_element ::=  command_invocation line_ending |
                  (bracket_comment|space)* line_ending
line_ending  ::=  line_comment? newline
space        ::=  <match '[ \t]+'>
newline      ::=  <match '\n'>

Note that any source file line not inside Command Arguments or a Bracket Comment can end in a Line Comment.

Command Invocations

A command invocation is a name followed by paren-enclosed arguments separated by whitespace:

command_invocation  ::=  space* identifier space* '(' arguments ')'
identifier          ::=  <match '[A-Za-z_][A-Za-z0-9_]*'>
arguments           ::=  argument? separated_arguments*
separated_arguments ::=  separation+ argument? |
                         separation* '(' arguments ')'
separation          ::=  space | line_ending

For example:

add_executable(hello world.c)

Command names are case-insensitive. Nested unquoted parentheses in the arguments must balance. Each ( or ) is given to the command invocation as a literal Unquoted Argument. This may be used in calls to the if() command to enclose conditions. For example:

if(FALSE AND (FALSE OR TRUE)) # evaluates to FALSE

Note

CMake versions prior to 3.0 require command name identifiers to be at least 2 characters.

CMake versions prior to 2.8.12 silently accept an Unquoted Argument or a Quoted Argument immediately following a Quoted Argument and not separated by any whitespace. For compatibility, CMake 2.8.12 and higher accept such code but produce a warning.

Command Arguments

There are three types of arguments within Command Invocations:

argument ::=  bracket_argument | quoted_argument | unquoted_argument

Bracket Argument

A bracket argument, inspired by Lua long bracket syntax, encloses content between opening and closing “brackets” of the same length:

bracket_argument ::=  bracket_open bracket_content bracket_close
bracket_open     ::=  '[' '='* '['
bracket_content  ::=  <any text not containing a bracket_close with
                       the same number of '=' as the bracket_open>
bracket_close    ::=  ']' '='* ']'

An opening bracket is written [ followed by zero or more = followed by [. The corresponding closing bracket is written ] followed by the same number of = followed by ]. Brackets do not nest. A unique length may always be chosen for the opening and closing brackets to contain closing brackets of other lengths.

Bracket argument content consists of all text between the opening and closing brackets, except that one newline immediately following the opening bracket, if any, is ignored. No evaluation of the enclosed content, such as Escape Sequences or Variable References, is performed. A bracket argument is always given to the command invocation as exactly one argument.

For example:

message([=[
This is the first line in a bracket argument with bracket length 1.
No \-escape sequences or ${variable} references are evaluated.
This is always one argument even though it contains a ; character.
The text does not end on a closing bracket of length 0 like ]].
It does end in a closing bracket of length 1.
]=])

Note

CMake versions prior to 3.0 do not support bracket arguments. They interpret the opening bracket as the start of an Unquoted Argument.

Quoted Argument

A quoted argument encloses content between opening and closing double-quote characters:

quoted_argument     ::=  '"' quoted_element* '"'
quoted_element      ::=  <any character except '\' or '"'> |
                         escape_sequence |
                         quoted_continuation
quoted_continuation ::=  '\' newline

Quoted argument content consists of all text between opening and closing quotes. Both Escape Sequences and Variable References are evaluated. A quoted argument is always given to the command invocation as exactly one argument.

For example:

message("This is a quoted argument containing multiple lines.
This is always one argument even though it contains a ; character.
Both \\-escape sequences and ${variable} references are evaluated.
The text does not end on an escaped double-quote like \".
It does end in an unescaped double quote.
")

The final \ on any line ending in an odd number of backslashes is treated as a line continuation and ignored along with the immediately following newline character. For example:

message("\
This is the first line of a quoted argument. \
In fact it is the only line but since it is long \
the source code uses line continuation.\
")

Note

CMake versions prior to 3.0 do not support continuation with \. They report errors in quoted arguments containing lines ending in an odd number of \ characters.

Unquoted Argument

An unquoted argument is not enclosed by any quoting syntax. It may not contain any whitespace, (, ), #, ", or \ except when escaped by a backslash:

unquoted_argument ::=  unquoted_element+ | unquoted_legacy
unquoted_element  ::=  <any character except whitespace or one of '()#"\'> |
                       escape_sequence
unquoted_legacy   ::=  <see note in text>

Unquoted argument content consists of all text in a contiguous block of allowed or escaped characters. Both Escape Sequences and Variable References are evaluated. The resulting value is divided in the same way Lists divide into elements. Each non-empty element is given to the command invocation as an argument. Therefore an unquoted argument may be given to a command invocation as zero or more arguments.

For example:

foreach(arg
    NoSpace
    Escaped\ Space
    This;Divides;Into;Five;Arguments
    Escaped\;Semicolon
    )
  message("${arg}")
endforeach()

Note

To support legacy CMake code, unquoted arguments may also contain double-quoted strings ("...", possibly enclosing horizontal whitespace), and make-style variable references ($(MAKEVAR)).

Unescaped double-quotes must balance, may not appear at the beginning of an unquoted argument, and are treated as part of the content. For example, the unquoted arguments -Da="b c", -Da=$(v), and a" "b"c"d are each interpreted literally. They may instead be written as quoted arguments "-Da=\"b c\"", "-Da=$(v)", and "a\" \"b\"c\"d", respectively.

Make-style references are treated literally as part of the content and do not undergo variable expansion. They are treated as part of a single argument (rather than as separate $, (, MAKEVAR, and ) arguments).

The above “unquoted_legacy” production represents such arguments. We do not recommend using legacy unquoted arguments in new code. Instead use a Quoted Argument or a Bracket Argument to represent the content.

Escape Sequences

An escape sequence is a \ followed by one character:

escape_sequence  ::=  escape_identity | escape_encoded | escape_semicolon
escape_identity  ::=  '\' <match '[^A-Za-z0-9;]'>
escape_encoded   ::=  '\t' | '\r' | '\n'
escape_semicolon ::=  '\;'

A \ followed by a non-alphanumeric character simply encodes the literal character without interpreting it as syntax. A \t, \r, or \n encodes a tab, carriage return, or newline character, respectively. A \; outside of any Variable References encodes itself but may be used in an Unquoted Argument to encode the ; without dividing the argument value on it. A \; inside Variable References encodes the literal ; character. (See also policy CMP0053 documentation for historical considerations.)

Variable References

A variable reference has the form ${<variable>} and is evaluated inside a Quoted Argument or an Unquoted Argument. A variable reference is replaced by the value of the variable, or by the empty string if the variable is not set. Variable references can nest and are evaluated from the inside out, e.g. ${outer_${inner_variable}_variable}.

Literal variable references may consist of alphanumeric characters, the characters /_.+-, and Escape Sequences. Nested references may be used to evaluate variables of any name. See also policy CMP0053 documentation for historical considerations and reasons why the $ is also technically permitted but is discouraged.

The Variables section documents the scope of variable names and how their values are set.

An environment variable reference has the form $ENV{<variable>}. See the Environment Variables section for more information.

A cache variable reference has the form $CACHE{<variable>}. See CACHE for more information.

The if() command has a special condition syntax that allows for variable references in the short form <variable> instead of ${<variable>}. However, environment and cache variables always need to be referenced as $ENV{<variable>} or $CACHE{<variable>}.

Comments

A comment starts with a # character that is not inside a Bracket Argument, Quoted Argument, or escaped with \ as part of an Unquoted Argument. There are two types of comments: a Bracket Comment and a Line Comment.

Bracket Comment

A # immediately followed by a Bracket Argument forms a bracket comment consisting of the entire bracket enclosure:

bracket_comment ::=  '#' bracket_argument

For example:

#[[This is a bracket comment.
It runs until the close bracket.]]
message("First Argument\n" #[[Bracket Comment]] "Second Argument")

Note

CMake versions prior to 3.0 do not support bracket comments. They interpret the opening # as the start of a Line Comment.

Line Comment

A # not immediately followed by a Bracket Argument forms a line comment that runs until the end of the line:

line_comment ::=  '#' <any text not starting in a bracket_argument
                       and not containing a newline>

For example:

# This is a line comment.
message("First Argument\n" # This is a line comment :)
        "Second Argument") # This is a line comment.

Control Structures

Conditional Blocks

The if()/ elseif()/ else()/ endif() commands delimit code blocks to be executed conditionally.

Loops

The foreach()/ endforeach() and while()/ endwhile() commands delimit code blocks to be executed in a loop. Inside such blocks the break() command may be used to terminate the loop early whereas the continue() command may be used to start with the next iteration immediately.

Command Definitions

The macro()/ endmacro(), and function()/ endfunction() commands delimit code blocks to be recorded for later invocation as commands.

Variables

Variables are the basic unit of storage in the CMake Language. Their values are always of string type, though some commands may interpret the strings as values of other types. The set() and unset() commands explicitly set or unset a variable, but other commands have semantics that modify variables as well. Variable names are case-sensitive and may consist of almost any text, but we recommend sticking to names consisting only of alphanumeric characters plus _ and -.

Variables have dynamic scope. Each variable “set” or “unset” creates a binding in the current scope:

Function Scope
Command Definitions created by the function() command create commands that, when invoked, process the recorded commands in a new variable binding scope. A variable “set” or “unset” binds in this scope and is visible for the current function and any nested calls within it, but not after the function returns.
Directory Scope

Each of the Directories in a source tree has its own variable bindings. Before processing the CMakeLists.txt file for a directory, CMake copies all variable bindings currently defined in the parent directory, if any, to initialize the new directory scope. CMake Scripts, when processed with cmake -P, bind variables in one “directory” scope.

A variable “set” or “unset” not inside a function call binds to the current directory scope.

Persistent Cache
CMake stores a separate set of “cache” variables, or “cache entries”, whose values persist across multiple runs within a project build tree. Cache entries have an isolated binding scope modified only by explicit request, such as by the CACHE option of the set() and unset() commands.

When evaluating Variable References, CMake first searches the function call stack, if any, for a binding and then falls back to the binding in the current directory scope, if any. If a “set” binding is found, its value is used. If an “unset” binding is found, or no binding is found, CMake then searches for a cache entry. If a cache entry is found, its value is used. Otherwise, the variable reference evaluates to an empty string. The $CACHE{VAR} syntax can be used to do direct cache entry lookups.

The cmake-variables(7) manual documents the many variables that are provided by CMake or have meaning to CMake when set by project code.

Environment Variables

Environment Variables are like ordinary Variables, with the following differences:

Scope
Environment variables have global scope in a CMake process. They are never cached.
References
Variable References have the form $ENV{<variable>}.
Initialization
Initial values of the CMake environment variables are those of the calling process. Values can be changed using the set() and unset() commands. These commands only affect the running CMake process, not the system environment at large. Changed values are not written back to the calling process, and they are not seen by subsequent build or test processes.

The cmake-env-variables(7) manual documents environment variables that have special meaning to CMake.

Lists

Although all values in CMake are stored as strings, a string may be treated as a list in certain contexts, such as during evaluation of an Unquoted Argument. In such contexts, a string is divided into list elements by splitting on ; characters not following an unequal number of [ and ] characters and not immediately preceded by a \. The sequence \; does not divide a value but is replaced by ; in the resulting element.

A list of elements is represented as a string by concatenating the elements separated by ;. For example, the set() command stores multiple values into the destination variable as a list:

set(srcs a.c b.c c.c) # sets "srcs" to "a.c;b.c;c.c"

Lists are meant for simple use cases such as a list of source files and should not be used for complex data processing tasks. Most commands that construct lists do not escape ; characters in list elements, thus flattening nested lists:

set(x a "b;c") # sets "x" to "a;b;c", not "a;b\;c"


cmake-modules(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-modules(7)

The modules listed here are part of the CMake distribution. Projects may provide further modules; their location(s) can be specified in the CMAKE_MODULE_PATH variable.

Utility Modules

These modules are loaded using the include() command.

  • AddFileDependencies
  • AndroidTestUtilities
  • BundleUtilities
  • CheckCCompilerFlag
  • CheckCSourceCompiles
  • CheckCSourceRuns
  • CheckCXXCompilerFlag
  • CheckCXXSourceCompiles
  • CheckCXXSourceRuns
  • CheckCXXSymbolExists
  • CheckFortranCompilerFlag
  • CheckFortranFunctionExists
  • CheckFortranSourceCompiles
  • CheckFortranSourceRuns
  • CheckFunctionExists
  • CheckIPOSupported
  • CheckIncludeFileCXX
  • CheckIncludeFile
  • CheckIncludeFiles
  • CheckLanguage
  • CheckLibraryExists
  • CheckPIESupported
  • CheckPrototypeDefinition
  • CheckStructHasMember
  • CheckSymbolExists
  • CheckTypeSize
  • CheckVariableExists
  • CMakeAddFortranSubdirectory
  • CMakeBackwardCompatibilityCXX
  • CMakeDependentOption
  • CMakeFindDependencyMacro
  • CMakeFindFrameworks
  • CMakeFindPackageMode
  • CMakeGraphVizOptions
  • CMakePackageConfigHelpers
  • CMakePrintHelpers
  • CMakePrintSystemInformation
  • CMakePushCheckState
  • CMakeVerifyManifest
  • CPackComponent
  • CPackIFW
  • CPackIFWConfigureFile
  • CPack
  • CSharpUtilities
  • CTest
  • CTestCoverageCollectGCOV
  • CTestScriptMode
  • CTestUseLaunchers
  • Dart
  • DeployQt4
  • Documentation
  • ExternalData
  • ExternalProject
  • FeatureSummary
  • FetchContent
  • FindPackageHandleStandardArgs
  • FindPackageMessage
  • FortranCInterface
  • GenerateExportHeader
  • GetPrerequisites
  • GNUInstallDirs
  • GoogleTest
  • InstallRequiredSystemLibraries
  • ProcessorCount
  • SelectLibraryConfigurations
  • SquishTestScript
  • TestBigEndian
  • TestForANSIForScope
  • TestForANSIStreamHeaders
  • TestForSSTREAM
  • TestForSTDNamespace
  • UseEcos
  • UseJavaClassFilelist
  • UseJava
  • UseJavaSymlinks
  • UseSWIG
  • UsewxWidgets
  • WriteCompilerDetectionHeader

Find Modules

These modules search for third-party software. They are normally called through the find_package() command.

  • FindALSA
  • FindArmadillo
  • FindASPELL
  • FindAVIFile
  • FindBISON
  • FindBLAS
  • FindBacktrace
  • FindBoost
  • FindBullet
  • FindBZip2
  • FindCABLE
  • FindCoin3D
  • FindCups
  • FindCURL
  • FindCurses
  • FindCVS
  • FindCxxTest
  • FindCygwin
  • FindDart
  • FindDCMTK
  • FindDevIL
  • FindDoxygen
  • FindEXPAT
  • FindFLEX
  • FindFLTK2
  • FindFLTK
  • FindFontconfig
  • FindFreetype
  • FindGCCXML
  • FindGDAL
  • FindGettext
  • FindGIF
  • FindGit
  • FindGLEW
  • FindGLUT
  • FindGnuplot
  • FindGnuTLS
  • FindGSL
  • FindGTest
  • FindGTK2
  • FindGTK
  • FindHDF5
  • FindHg
  • FindHSPELL
  • FindHTMLHelp
  • FindIce
  • FindIcotool
  • FindICU
  • FindImageMagick
  • FindIconv
  • FindIntl
  • FindITK
  • FindJasper
  • FindJava
  • FindJNI
  • FindJPEG
  • FindKDE3
  • FindKDE4
  • FindLAPACK
  • FindLATEX
  • FindLibArchive
  • FindLibinput
  • FindLibLZMA
  • FindLibXml2
  • FindLibXslt
  • FindLTTngUST
  • FindLua50
  • FindLua51
  • FindLua
  • FindMatlab
  • FindMFC
  • FindMotif
  • FindMPEG2
  • FindMPEG
  • FindMPI
  • FindODBC
  • FindOpenACC
  • FindOpenAL
  • FindOpenCL
  • FindOpenGL
  • FindOpenMP
  • FindOpenSceneGraph
  • FindOpenSSL
  • FindOpenThreads
  • FindosgAnimation
  • FindosgDB
  • Findosg_functions
  • FindosgFX
  • FindosgGA
  • FindosgIntrospection
  • FindosgManipulator
  • FindosgParticle
  • FindosgPresentation
  • FindosgProducer
  • FindosgQt
  • Findosg
  • FindosgShadow
  • FindosgSim
  • FindosgTerrain
  • FindosgText
  • FindosgUtil
  • FindosgViewer
  • FindosgVolume
  • FindosgWidget
  • FindPatch
  • FindPerlLibs
  • FindPerl
  • FindPHP4
  • FindPhysFS
  • FindPike
  • FindPkgConfig
  • FindPNG
  • FindPostgreSQL
  • FindProducer
  • FindProtobuf
  • FindPython
  • FindPython2
  • FindPython3
  • FindQt3
  • FindQt4
  • FindQuickTime
  • FindRTI
  • FindRuby
  • FindSDL_image
  • FindSDL_mixer
  • FindSDL_net
  • FindSDL
  • FindSDL_sound
  • FindSDL_ttf
  • FindSelfPackers
  • FindSquish
  • FindSQLite3
  • FindSubversion
  • FindSWIG
  • FindTCL
  • FindTclsh
  • FindTclStub
  • FindThreads
  • FindTIFF
  • FindUnixCommands
  • FindVTK
  • FindVulkan
  • FindWget
  • FindWish
  • FindwxWidgets
  • FindXCTest
  • FindXalanC
  • FindXercesC
  • FindX11
  • FindXMLRPC
  • FindZLIB

Deprecated Modules

Deprecated Utility Modules

  • CMakeDetermineVSServicePack
  • CMakeExpandImportedTargets
  • CMakeForceCompiler
  • CMakeParseArguments
  • MacroAddFileDependencies
  • TestCXXAcceptsFlag
  • UsePkgConfig
  • Use_wxWindows
  • WriteBasicConfigVersionFile

Deprecated Find Modules

  • FindCUDA
  • FindPythonInterp
  • FindPythonLibs
  • FindQt
  • FindwxWindows

Legacy CPack Modules

These modules used to be mistakenly exposed to the user, and have been moved out of user visibility. They are for CPack internal use, and should never be used directly.

  • CPackArchive
  • CPackBundle
  • CPackCygwin
  • CPackDeb
  • CPackDMG
  • CPackFreeBSD
  • CPackNSIS
  • CPackNuGet
  • CPackPackageMaker
  • CPackProductBuild
  • CPackRPM
  • CPackWIX


AddFileDependencies — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

AddFileDependencies

Add dependencies to a source file.

ADD_FILE_DEPENDENCIES(<source> <files>)

Adds the given <files> to the dependencies of file <source>.

  • cmake-modules(7) »


AndroidTestUtilities — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

AndroidTestUtilities

Create a test that automatically loads specified data onto an Android device.

Introduction

Use this module to push data needed for testing an Android device behavior onto a connected Android device. The module will accept files and libraries as well as separate destinations for each. It will create a test that loads the files into a device object store and link to them from the specified destination. The files are only uploaded if they are not already in the object store.

For example:

include(AndroidTestUtilities)
android_add_test_data(
  example_setup_test
  FILES <files>...
  LIBS <libs>...
  DEVICE_TEST_DIR "/data/local/tests/example"
  DEVICE_OBJECT_STORE "/sdcard/.ExternalData/SHA"
  )

At build time a test named “example_setup_test” will be created. Run this test on the command line with ctest(1) to load the data onto the Android device.

Module Functions

android_add_test_data
android_add_test_data(<test-name>
  [FILES <files>...] [FILES_DEST <device-dir>]
  [LIBS <libs>...]   [LIBS_DEST <device-dir>]
  [DEVICE_OBJECT_STORE <device-dir>]
  [DEVICE_TEST_DIR <device-dir>]
  [NO_LINK_REGEX <strings>...]
  )

The android_add_test_data function is used to copy files and libraries needed to run project-specific tests. On the host operating system, this is done at build time. For on-device testing, the files are loaded onto the device by the manufactured test at run time.

This function accepts the following named parameters:

FILES <files>...
zero or more files needed for testing
LIBS <libs>...
zero or more libraries needed for testing
FILES_DEST <device-dir>
absolute path where the data files are expected to be
LIBS_DEST <device-dir>
absolute path where the libraries are expected to be
DEVICE_OBJECT_STORE <device-dir>
absolute path to the location where the data is stored on-device
DEVICE_TEST_DIR <device-dir>
absolute path to the root directory of the on-device test location
NO_LINK_REGEX <strings>...
list of regex strings matching the names of files that should be copied from the object store to the testing directory

  • cmake-modules(7) »


BundleUtilities — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

BundleUtilities

Functions to help assemble a standalone bundle application.

A collection of CMake utility functions useful for dealing with .app bundles on the Mac and bundle-like directories on any OS.

The following functions are provided by this module:

fixup_bundle
copy_and_fixup_bundle
verify_app
get_bundle_main_executable
get_dotapp_dir
get_bundle_and_executable
get_bundle_all_executables
get_item_key
get_item_rpaths
clear_bundle_keys
set_bundle_key_values
get_bundle_keys
copy_resolved_item_into_bundle
copy_resolved_framework_into_bundle
fixup_bundle_item
verify_bundle_prerequisites
verify_bundle_symlinks

Requires CMake 2.6 or greater because it uses function, break and PARENT_SCOPE. Also depends on GetPrerequisites.cmake.

DO NOT USE THESE FUNCTIONS AT CONFIGURE TIME (from CMakeLists.txt)! Instead, invoke them from an install(CODE) or install(SCRIPT) rule.

fixup_bundle(<app> <libs> <dirs>)

Fix up a bundle in-place and make it standalone, such that it can be drag-n-drop copied to another machine and run on that machine as long as all of the system libraries are compatible.

If you pass plugins to fixup_bundle as the libs parameter, you should install them or copy them into the bundle before calling fixup_bundle. The “libs” parameter is a list of libraries that must be fixed up, but that cannot be determined by otool output analysis. (i.e., plugins)

Gather all the keys for all the executables and libraries in a bundle, and then, for each key, copy each prerequisite into the bundle. Then fix each one up according to its own list of prerequisites.

Then clear all the keys and call verify_app on the final bundle to ensure that it is truly standalone.

As an optional parameter (IGNORE_ITEM) a list of file names can be passed, which are then ignored (e.g. IGNORE_ITEM “vcredist_x86.exe;vcredist_x64.exe”)

copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)

Makes a copy of the bundle <src> at location <dst> and then fixes up the new copied bundle in-place at <dst>…

verify_app(<app>)

Verifies that an application <app> appears valid based on running analysis tools on it. Calls “message(FATAL_ERROR” if the application is not verified.

As an optional parameter (IGNORE_ITEM) a list of file names can be passed, which are then ignored (e.g. IGNORE_ITEM “vcredist_x86.exe;vcredist_x64.exe”)

get_bundle_main_executable(<bundle> <result_var>)

The result will be the full path name of the bundle’s main executable file or an “error:” prefixed string if it could not be determined.

get_dotapp_dir(<exe> <dotapp_dir_var>)

Returns the nearest parent dir whose name ends with “.app” given the full path to an executable. If there is no such parent dir, then simply return the dir containing the executable.

The returned directory may or may not exist.

get_bundle_and_executable(<app> <bundle_var> <executable_var> <valid_var>)

Takes either a “.app” directory name or the name of an executable nested inside a “.app” directory and returns the path to the “.app” directory in <bundle_var> and the path to its main executable in <executable_var>

get_bundle_all_executables(<bundle> <exes_var>)

Scans the given bundle recursively for all executable files and accumulates them into a variable.

get_item_key(<item> <key_var>)

Given a file (item) name, generate a key that should be unique considering the set of libraries that need copying or fixing up to make a bundle standalone. This is essentially the file name including extension with “.” replaced by “_”

This key is used as a prefix for CMake variables so that we can associate a set of variables with a given item based on its key.

clear_bundle_keys(<keys_var>)

Loop over the list of keys, clearing all the variables associated with each key. After the loop, clear the list of keys itself.

Caller of get_bundle_keys should call clear_bundle_keys when done with list of keys.

set_bundle_key_values(<keys_var> <context> <item> <exepath> <dirs>
                      <copyflag> [<rpaths>])

Add a key to the list (if necessary) for the given item. If added, also set all the variables associated with that key.

get_bundle_keys(<app> <libs> <dirs> <keys_var>)

Loop over all the executable and library files within the bundle (and given as extra <libs>) and accumulate a list of keys representing them. Set values associated with each key such that we can loop over all of them and copy prerequisite libs into the bundle and then do appropriate install_name_tool fixups.

As an optional parameter (IGNORE_ITEM) a list of file names can be passed, which are then ignored (e.g. IGNORE_ITEM “vcredist_x86.exe;vcredist_x64.exe”)

copy_resolved_item_into_bundle(<resolved_item> <resolved_embedded_item>)

Copy a resolved item into the bundle if necessary. Copy is not necessary if the resolved_item is “the same as” the resolved_embedded_item.

copy_resolved_framework_into_bundle(<resolved_item> <resolved_embedded_item>)

Copy a resolved framework into the bundle if necessary. Copy is not necessary if the resolved_item is “the same as” the resolved_embedded_item.

By default, BU_COPY_FULL_FRAMEWORK_CONTENTS is not set. If you want full frameworks embedded in your bundles, set BU_COPY_FULL_FRAMEWORK_CONTENTS to ON before calling fixup_bundle. By default, COPY_RESOLVED_FRAMEWORK_INTO_BUNDLE copies the framework dylib itself plus the framework Resources directory.

fixup_bundle_item(<resolved_embedded_item> <exepath> <dirs>)

Get the direct/non-system prerequisites of the resolved embedded item. For each prerequisite, change the way it is referenced to the value of the _EMBEDDED_ITEM keyed variable for that prerequisite. (Most likely changing to an “@executable_path” style reference.)

This function requires that the resolved_embedded_item be “inside” the bundle already. In other words, if you pass plugins to fixup_bundle as the libs parameter, you should install them or copy them into the bundle before calling fixup_bundle. The “libs” parameter is a list of libraries that must be fixed up, but that cannot be determined by otool output analysis. (i.e., plugins)

Also, change the id of the item being fixed up to its own _EMBEDDED_ITEM value.

Accumulate changes in a local variable and make one call to install_name_tool at the end of the function with all the changes at once.

If the BU_CHMOD_BUNDLE_ITEMS variable is set then bundle items will be marked writable before install_name_tool tries to change them.

verify_bundle_prerequisites(<bundle> <result_var> <info_var>)

Verifies that the sum of all prerequisites of all files inside the bundle are contained within the bundle or are “system” libraries, presumed to exist everywhere.

As an optional parameter (IGNORE_ITEM) a list of file names can be passed, which are then ignored (e.g. IGNORE_ITEM “vcredist_x86.exe;vcredist_x64.exe”)

verify_bundle_symlinks(<bundle> <result_var> <info_var>)

Verifies that any symlinks found in the bundle point to other files that are already also in the bundle… Anything that points to an external file causes this function to fail the verification.

  • cmake-modules(7) »


CheckCCompilerFlag — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckCCompilerFlag

Check whether the C compiler supports a given flag.

check_c_compiler_flag
check_c_compiler_flag(<flag> <var>)

Check that the <flag> is accepted by the compiler without a diagnostic. Stores the result in an internal cache entry named <var>.

This command temporarily sets the CMAKE_REQUIRED_DEFINITIONS variable and calls the check_c_source_compiles macro from the CheckCSourceCompiles module. See documentation of that module for a listing of variables that can otherwise modify the build.

A positive result from this check indicates only that the compiler did not issue a diagnostic message when given the flag. Whether the flag has any effect or even a specific one is beyond the scope of this module.

Note

Since the try_compile() command forwards flags from variables like CMAKE_C_FLAGS, unknown flags in such variables may cause a false negative for this check.

  • cmake-modules(7) »


CheckCSourceCompiles — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckCSourceCompiles

Check if given C source compiles and links into an executable.

check_c_source_compiles
check_c_source_compiles(<code> <resultVar>
                        [FAIL_REGEX <regex1> [<regex2>...]])

Check that the source supplied in <code> can be compiled as a C source file and linked as an executable (so it must contain at least a main() function). The result will be stored in the internal cache variable specified by <resultVar>, with a boolean true value for success and boolean false for failure. If FAIL_REGEX is provided, then failure is determined by checking if anything in the output matches any of the specified regular expressions.

The underlying check is performed by the try_compile() command. The compile and link commands can be influenced by setting any of the following variables prior to calling check_c_source_compiles():

CMAKE_REQUIRED_FLAGS
Additional flags to pass to the compiler. Note that the contents of CMAKE_C_FLAGS and its associated configuration-specific variable are automatically added to the compiler command before the contents of CMAKE_REQUIRED_FLAGS.
CMAKE_REQUIRED_DEFINITIONS
A ;-list of compiler definitions of the form -DFOO or -DFOO=bar. A definition for the name specified by <resultVar> will also be added automatically.
CMAKE_REQUIRED_INCLUDES
A ;-list of header search paths to pass to the compiler. These will be the only header search paths used by try_compile(), i.e. the contents of the INCLUDE_DIRECTORIES directory property will be ignored.
CMAKE_REQUIRED_LINK_OPTIONS
A ;-list of options to add to the link command (see try_compile() for further details).
CMAKE_REQUIRED_LIBRARIES
A ;-list of libraries to add to the link command. These can be the name of system libraries or they can be Imported Targets (see try_compile() for further details).
CMAKE_REQUIRED_QUIET
If this variable evaluates to a boolean true value, all status messages associated with the check will be suppressed.

The check is only performed once, with the result cached in the variable named by <resultVar>. Every subsequent CMake run will re-use this cached value rather than performing the check again, even if the <code> changes. In order to force the check to be re-evaluated, the variable named by <resultVar> must be manually removed from the cache.

  • cmake-modules(7) »


CheckCSourceRuns — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckCSourceRuns

Check if given C source compiles and links into an executable and can subsequently be run.

check_c_source_runs
check_c_source_runs(<code> <resultVar>)

Check that the source supplied in <code> can be compiled as a C source file, linked as an executable and then run. The <code> must contain at least a main() function. If the <code> could be built and run successfully, the internal cache variable specified by <resultVar> will be set to 1, otherwise it will be set to an value that evaluates to boolean false (e.g. an empty string or an error message).

The underlying check is performed by the try_run() command. The compile and link commands can be influenced by setting any of the following variables prior to calling check_c_source_runs():

CMAKE_REQUIRED_FLAGS
Additional flags to pass to the compiler. Note that the contents of CMAKE_C_FLAGS and its associated configuration-specific variable are automatically added to the compiler command before the contents of CMAKE_REQUIRED_FLAGS.
CMAKE_REQUIRED_DEFINITIONS
A ;-list of compiler definitions of the form -DFOO or -DFOO=bar. A definition for the name specified by <resultVar> will also be added automatically.
CMAKE_REQUIRED_INCLUDES
A ;-list of header search paths to pass to the compiler. These will be the only header search paths used by try_run(), i.e. the contents of the INCLUDE_DIRECTORIES directory property will be ignored.
CMAKE_REQUIRED_LINK_OPTIONS
A ;-list of options to add to the link command (see try_run() for further details).
CMAKE_REQUIRED_LIBRARIES
A ;-list of libraries to add to the link command. These can be the name of system libraries or they can be Imported Targets (see try_run() for further details).
CMAKE_REQUIRED_QUIET
If this variable evaluates to a boolean true value, all status messages associated with the check will be suppressed.

The check is only performed once, with the result cached in the variable named by <resultVar>. Every subsequent CMake run will re-use this cached value rather than performing the check again, even if the <code> changes. In order to force the check to be re-evaluated, the variable named by <resultVar> must be manually removed from the cache.

  • cmake-modules(7) »


CheckCXXCompilerFlag — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckCXXCompilerFlag

Check whether the CXX compiler supports a given flag.

check_cxx_compiler_flag
check_cxx_compiler_flag(<flag> <var>)

Check that the <flag> is accepted by the compiler without a diagnostic. Stores the result in an internal cache entry named <var>.

This command temporarily sets the CMAKE_REQUIRED_DEFINITIONS variable and calls the check_cxx_source_compiles macro from the CheckCXXSourceCompiles module. See documentation of that module for a listing of variables that can otherwise modify the build.

A positive result from this check indicates only that the compiler did not issue a diagnostic message when given the flag. Whether the flag has any effect or even a specific one is beyond the scope of this module.

Note

Since the try_compile() command forwards flags from variables like CMAKE_CXX_FLAGS, unknown flags in such variables may cause a false negative for this check.

  • cmake-modules(7) »


CheckCXXSourceCompiles — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckCXXSourceCompiles

Check if given C++ source compiles and links into an executable.

check_cxx_source_compiles
check_cxx_source_compiles(<code> <resultVar>
                          [FAIL_REGEX <regex1> [<regex2>...]])

Check that the source supplied in <code> can be compiled as a C++ source file and linked as an executable (so it must contain at least a main() function). The result will be stored in the internal cache variable specified by <resultVar>, with a boolean true value for success and boolean false for failure. If FAIL_REGEX is provided, then failure is determined by checking if anything in the output matches any of the specified regular expressions.

The underlying check is performed by the try_compile() command. The compile and link commands can be influenced by setting any of the following variables prior to calling check_cxx_source_compiles():

CMAKE_REQUIRED_FLAGS
Additional flags to pass to the compiler. Note that the contents of CMAKE_CXX_FLAGS and its associated configuration-specific variable are automatically added to the compiler command before the contents of CMAKE_REQUIRED_FLAGS.
CMAKE_REQUIRED_DEFINITIONS
A ;-list of compiler definitions of the form -DFOO or -DFOO=bar. A definition for the name specified by <resultVar> will also be added automatically.
CMAKE_REQUIRED_INCLUDES
A ;-list of header search paths to pass to the compiler. These will be the only header search paths used by try_compile(), i.e. the contents of the INCLUDE_DIRECTORIES directory property will be ignored.
CMAKE_REQUIRED_LINK_OPTIONS
A ;-list of options to add to the link command (see try_compile() for further details).
CMAKE_REQUIRED_LIBRARIES
A ;-list of libraries to add to the link command. These can be the name of system libraries or they can be Imported Targets (see try_compile() for further details).
CMAKE_REQUIRED_QUIET
If this variable evaluates to a boolean true value, all status messages associated with the check will be suppressed.

The check is only performed once, with the result cached in the variable named by <resultVar>. Every subsequent CMake run will re-use this cached value rather than performing the check again, even if the <code> changes. In order to force the check to be re-evaluated, the variable named by <resultVar> must be manually removed from the cache.

  • cmake-modules(7) »


CheckCXXSourceRuns — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckCXXSourceRuns

Check if given C++ source compiles and links into an executable and can subsequently be run.

check_cxx_source_runs
check_cxx_source_runs(<code> <resultVar>)

Check that the source supplied in <code> can be compiled as a C++ source file, linked as an executable and then run. The <code> must contain at least a main() function. If the <code> could be built and run successfully, the internal cache variable specified by <resultVar> will be set to 1, otherwise it will be set to an value that evaluates to boolean false (e.g. an empty string or an error message).

The underlying check is performed by the try_run() command. The compile and link commands can be influenced by setting any of the following variables prior to calling check_cxx_source_runs():

CMAKE_REQUIRED_FLAGS
Additional flags to pass to the compiler. Note that the contents of CMAKE_CXX_FLAGS and its associated configuration-specific variable are automatically added to the compiler command before the contents of CMAKE_REQUIRED_FLAGS.
CMAKE_REQUIRED_DEFINITIONS
A ;-list of compiler definitions of the form -DFOO or -DFOO=bar. A definition for the name specified by <resultVar> will also be added automatically.
CMAKE_REQUIRED_INCLUDES
A ;-list of header search paths to pass to the compiler. These will be the only header search paths used by try_run(), i.e. the contents of the INCLUDE_DIRECTORIES directory property will be ignored.
CMAKE_REQUIRED_LINK_OPTIONS
A ;-list of options to add to the link command (see try_run() for further details).
CMAKE_REQUIRED_LIBRARIES
A ;-list of libraries to add to the link command. These can be the name of system libraries or they can be Imported Targets (see try_run() for further details).
CMAKE_REQUIRED_QUIET
If this variable evaluates to a boolean true value, all status messages associated with the check will be suppressed.

The check is only performed once, with the result cached in the variable named by <resultVar>. Every subsequent CMake run will re-use this cached value rather than performing the check again, even if the <code> changes. In order to force the check to be re-evaluated, the variable named by <resultVar> must be manually removed from the cache.

  • cmake-modules(7) »


CheckCXXSymbolExists — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckCXXSymbolExists

Check if a symbol exists as a function, variable, or macro in C++

CHECK_CXX_SYMBOL_EXISTS
CHECK_CXX_SYMBOL_EXISTS(<symbol> <files> <variable>)

Check that the <symbol> is available after including given header <files> and store the result in a <variable>. Specify the list of files in one argument as a semicolon-separated list. CHECK_CXX_SYMBOL_EXISTS() can be used to check in C++ files, as opposed to CHECK_SYMBOL_EXISTS(), which works only for C.

If the header files define the symbol as a macro it is considered available and assumed to work. If the header files declare the symbol as a function or variable then the symbol must also be available for linking. If the symbol is a type or enum value it will not be recognized (consider using CheckTypeSize or CheckCSourceCompiles).

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS
string of compile command line flags.
CMAKE_REQUIRED_DEFINITIONS
a ;-list of macros to define (-DFOO=bar).
CMAKE_REQUIRED_INCLUDES
a ;-list of header search paths to pass to the compiler.
CMAKE_REQUIRED_LINK_OPTIONS
a ;-list of options to add to the link command.
CMAKE_REQUIRED_LIBRARIES
a ;-list of libraries to add to the link command. See policy CMP0075.
CMAKE_REQUIRED_QUIET
execute quietly without messages.

  • cmake-modules(7) »


CheckFortranCompilerFlag — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckFortranCompilerFlag

Check whether the Fortran compiler supports a given flag.

check_fortran_compiler_flag
check_fortran_compiler_flag(<flag> <var>)

Check that the <flag> is accepted by the compiler without a diagnostic. Stores the result in an internal cache entry named <var>.

This command temporarily sets the CMAKE_REQUIRED_DEFINITIONS variable and calls the check_fortran_source_compiles macro from the CheckFortranSourceCompiles module. See documentation of that module for a listing of variables that can otherwise modify the build.

A positive result from this check indicates only that the compiler did not issue a diagnostic message when given the flag. Whether the flag has any effect or even a specific one is beyond the scope of this module.

Note

Since the try_compile() command forwards flags from variables like CMAKE_Fortran_FLAGS, unknown flags in such variables may cause a false negative for this check.

  • cmake-modules(7) »


CheckFortranFunctionExists — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckFortranFunctionExists

Check if a Fortran function exists.

CHECK_FORTRAN_FUNCTION_EXISTS
CHECK_FORTRAN_FUNCTION_EXISTS(<function> <result>)

where

<function>
the name of the Fortran function
<result>
variable to store the result; will be created as an internal cache variable.

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_LINK_OPTIONS
A ;-list of options to add to the link command (see try_compile() for further details).
CMAKE_REQUIRED_LIBRARIES
A ;-list of libraries to add to the link command. These can be the name of system libraries or they can be Imported Targets (see try_compile() for further details).

  • cmake-modules(7) »


CheckFortranSourceCompiles — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckFortranSourceCompiles

Check if given Fortran source compiles and links into an executable.

check_fortran_source_compiles
check_fortran_source_compiles(<code> <resultVar>
    [FAIL_REGEX <regex>...]
    [SRC_EXT <extension>]
)

Checks that the source supplied in <code> can be compiled as a Fortran source file and linked as an executable. The <code> must be a Fortran program containing at least an end statement–for example:

check_fortran_source_compiles("character :: b; error stop b; end" F2018ESTOPOK SRC_EXT F90)

This command can help avoid costly build processes when a compiler lacks support for a necessary feature, or a particular vendor library is not compatible with the Fortran compiler version being used. This generate-time check may advise the user of such before the main build process. See also the check_fortran_source_runs() command to actually run the compiled code.

The result will be stored in the internal cache variable <resultVar>, with a boolean true value for success and boolean false for failure.

If FAIL_REGEX is provided, then failure is determined by checking if anything in the output matches any of the specified regular expressions.

By default, the test source file will be given a .F file extension. The SRC_EXT option can be used to override this with .<extension> instead– .F90 is a typical choice.

The underlying check is performed by the try_compile() command. The compile and link commands can be influenced by setting any of the following variables prior to calling check_fortran_source_compiles():

CMAKE_REQUIRED_FLAGS
Additional flags to pass to the compiler. Note that the contents of CMAKE_Fortran_FLAGS and its associated configuration-specific variable are automatically added to the compiler command before the contents of CMAKE_REQUIRED_FLAGS.
CMAKE_REQUIRED_DEFINITIONS
A ;-list of compiler definitions of the form -DFOO or -DFOO=bar. A definition for the name specified by <resultVar> will also be added automatically.
CMAKE_REQUIRED_INCLUDES
A ;-list of header search paths to pass to the compiler. These will be the only header search paths used by try_compile(), i.e. the contents of the INCLUDE_DIRECTORIES directory property will be ignored.
CMAKE_REQUIRED_LINK_OPTIONS
A ;-list of options to add to the link command (see try_compile() for further details).
CMAKE_REQUIRED_LIBRARIES
A ;-list of libraries to add to the link command. These can be the name of system libraries or they can be Imported Targets (see try_compile() for further details).
CMAKE_REQUIRED_QUIET
If this variable evaluates to a boolean true value, all status messages associated with the check will be suppressed.

The check is only performed once, with the result cached in the variable named by <resultVar>. Every subsequent CMake run will re-use this cached value rather than performing the check again, even if the <code> changes. In order to force the check to be re-evaluated, the variable named by <resultVar> must be manually removed from the cache.

  • cmake-modules(7) »


CheckFortranSourceRuns — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckFortranSourceRuns

Check if given Fortran source compiles and links into an executable and can subsequently be run.

check_fortran_source_runs
check_fortran_source_runs(<code> <resultVar>
    [SRC_EXT <extension>])

Check that the source supplied in <code> can be compiled as a Fortran source file, linked as an executable and then run. The <code> must be a Fortran program containing at least an end statement–for example:

check_fortran_source_runs("real :: x[*]; call co_sum(x); end" F2018coarrayOK)

This command can help avoid costly build processes when a compiler lacks support for a necessary feature, or a particular vendor library is not compatible with the Fortran compiler version being used. Some of these failures only occur at runtime instead of linktime, and a trivial runtime example can catch the issue before the main build process.

If the <code> could be built and run successfully, the internal cache variable specified by <resultVar> will be set to 1, otherwise it will be set to an value that evaluates to boolean false (e.g. an empty string or an error message).

By default, the test source file will be given a .F90 file extension. The SRC_EXT option can be used to override this with .<extension> instead.

The underlying check is performed by the try_run() command. The compile and link commands can be influenced by setting any of the following variables prior to calling check_fortran_source_runs():

CMAKE_REQUIRED_FLAGS
Additional flags to pass to the compiler. Note that the contents of CMAKE_Fortran_FLAGS and its associated configuration-specific variable are automatically added to the compiler command before the contents of CMAKE_REQUIRED_FLAGS.
CMAKE_REQUIRED_DEFINITIONS
A ;-list of compiler definitions of the form -DFOO or -DFOO=bar. A definition for the name specified by <resultVar> will also be added automatically.
CMAKE_REQUIRED_INCLUDES
A ;-list of header search paths to pass to the compiler. These will be the only header search paths used by try_run(), i.e. the contents of the INCLUDE_DIRECTORIES directory property will be ignored.
CMAKE_REQUIRED_LINK_OPTIONS
A ;-list of options to add to the link command (see try_run() for further details).
CMAKE_REQUIRED_LIBRARIES
A ;-list of libraries to add to the link command. These can be the name of system libraries or they can be Imported Targets (see try_run() for further details).
CMAKE_REQUIRED_QUIET
If this variable evaluates to a boolean true value, all status messages associated with the check will be suppressed.

The check is only performed once, with the result cached in the variable named by <resultVar>. Every subsequent CMake run will re-use this cached value rather than performing the check again, even if the <code> changes. In order to force the check to be re-evaluated, the variable named by <resultVar> must be manually removed from the cache.

  • cmake-modules(7) »


CheckFunctionExists — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckFunctionExists

Check if a C function can be linked

check_function_exists
check_function_exists(<function> <variable>)

Checks that the <function> is provided by libraries on the system and store the result in a <variable>, which will be created as an internal cache variable.

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS
string of compile command line flags.
CMAKE_REQUIRED_DEFINITIONS
a ;-list of macros to define (-DFOO=bar).
CMAKE_REQUIRED_INCLUDES
a ;-list of header search paths to pass to the compiler.
CMAKE_REQUIRED_LINK_OPTIONS
a ;-list of options to add to the link command.
CMAKE_REQUIRED_LIBRARIES
a ;-list of libraries to add to the link command. See policy CMP0075.
CMAKE_REQUIRED_QUIET
execute quietly without messages.

Note

Prefer using CheckSymbolExists instead of this module, for the following reasons:

  • check_function_exists() can’t detect functions that are inlined in headers or specified as a macro.
  • check_function_exists() can’t detect anything in the 32-bit versions of the Win32 API, because of a mismatch in calling conventions.
  • check_function_exists() only verifies linking, it does not verify that the function is declared in system headers.

  • cmake-modules(7) »


CheckIPOSupported — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckIPOSupported

Check whether the compiler supports an interprocedural optimization (IPO/LTO). Use this before enabling the INTERPROCEDURAL_OPTIMIZATION target property.

check_ipo_supported
check_ipo_supported([RESULT <result>] [OUTPUT <output>]
                    [LANGUAGES <lang>...])

Options are:

RESULT <result>
Set <result> variable to YES if IPO is supported by the compiler and NO otherwise. If this option is not given then the command will issue a fatal error if IPO is not supported.
OUTPUT <output>
Set <output> variable with details about any error.
LANGUAGES <lang>...
Specify languages whose compilers to check. Languages C, CXX, and Fortran are supported.

It makes no sense to use this module when CMP0069 is set to OLD so module will return error in this case. See policy CMP0069 for details.

Examples

check_ipo_supported() # fatal error if IPO is not supported
set_property(TARGET foo PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

# Optional IPO. Do not use IPO if it's not supported by compiler.
check_ipo_supported(RESULT result OUTPUT output)
if(result)
  set_property(TARGET foo PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
else()
  message(WARNING "IPO is not supported: ${output}")
endif()

  • cmake-modules(7) »


CheckIncludeFileCXX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckIncludeFileCXX

Provides a macro to check if a header file can be included in CXX.

CHECK_INCLUDE_FILE_CXX
CHECK_INCLUDE_FILE_CXX(<include> <variable> [<flags>])

Check if the given <include> file may be included in a CXX source file and store the result in an internal cache entry named <variable>. The optional third argument may be used to add compilation flags to the check (or use CMAKE_REQUIRED_FLAGS below).

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS
string of compile command line flags.
CMAKE_REQUIRED_DEFINITIONS
a ;-list of macros to define (-DFOO=bar).
CMAKE_REQUIRED_INCLUDES
a ;-list of header search paths to pass to the compiler.
CMAKE_REQUIRED_LINK_OPTIONS
a ;-list of options to add to the link command.
CMAKE_REQUIRED_LIBRARIES
a ;-list of libraries to add to the link command. See policy CMP0075.
CMAKE_REQUIRED_QUIET
execute quietly without messages.

See modules CheckIncludeFile and CheckIncludeFiles to check for one or more C headers.

  • cmake-modules(7) »


CheckIncludeFile — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckIncludeFile

Provides a macro to check if a header file can be included in C.

CHECK_INCLUDE_FILE
CHECK_INCLUDE_FILE(<include> <variable> [<flags>])

Check if the given <include> file may be included in a C source file and store the result in an internal cache entry named <variable>. The optional third argument may be used to add compilation flags to the check (or use CMAKE_REQUIRED_FLAGS below).

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS
string of compile command line flags.
CMAKE_REQUIRED_DEFINITIONS
a ;-list of macros to define (-DFOO=bar).
CMAKE_REQUIRED_INCLUDES
a ;-list of header search paths to pass to the compiler.
CMAKE_REQUIRED_LINK_OPTIONS
a ;-list of options to add to the link command.
CMAKE_REQUIRED_LIBRARIES
a ;-list of libraries to add to the link command. See policy CMP0075.
CMAKE_REQUIRED_QUIET
execute quietly without messages.

See the CheckIncludeFiles module to check for multiple headers at once. See the CheckIncludeFileCXX module to check for headers using the CXX language.

  • cmake-modules(7) »


CheckIncludeFiles — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckIncludeFiles

Provides a macro to check if a list of one or more header files can be included together.

CHECK_INCLUDE_FILES
CHECK_INCLUDE_FILES("<includes>" <variable> [LANGUAGE <language>])

Check if the given <includes> list may be included together in a source file and store the result in an internal cache entry named <variable>. Specify the <includes> argument as a ;-list of header file names.

If LANGUAGE is set, the specified compiler will be used to perform the check. Acceptable values are C and CXX. If not set, the C compiler will be used if enabled. If the C compiler is not enabled, the C++ compiler will be used if enabled.

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS
string of compile command line flags.
CMAKE_REQUIRED_DEFINITIONS
a ;-list of macros to define (-DFOO=bar).
CMAKE_REQUIRED_INCLUDES
a ;-list of header search paths to pass to the compiler.
CMAKE_REQUIRED_LINK_OPTIONS
a ;-list of options to add to the link command.
CMAKE_REQUIRED_LIBRARIES
a ;-list of libraries to add to the link command. See policy CMP0075.
CMAKE_REQUIRED_QUIET
execute quietly without messages.

See modules CheckIncludeFile and CheckIncludeFileCXX to check for a single header file in C or CXX languages.

  • cmake-modules(7) »


CheckLanguage — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckLanguage

Check if a language can be enabled

Usage:

check_language(<lang>)

where <lang> is a language that may be passed to enable_language() such as “Fortran”. If CMAKE_<lang>_COMPILER is already defined the check does nothing. Otherwise it tries enabling the language in a test project. The result is cached in CMAKE_<lang>_COMPILER as the compiler that was found, or NOTFOUND if the language cannot be enabled.

Example:

check_language(Fortran)
if(CMAKE_Fortran_COMPILER)
  enable_language(Fortran)
else()
  message(STATUS "No Fortran support")
endif()

  • cmake-modules(7) »


CheckLibraryExists — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckLibraryExists

Check if the function exists.

CHECK_LIBRARY_EXISTS
CHECK_LIBRARY_EXISTS(LIBRARY FUNCTION LOCATION VARIABLE)

LIBRARY  - the name of the library you are looking for
FUNCTION - the name of the function
LOCATION - location where the library should be found
VARIABLE - variable to store the result
           Will be created as an internal cache variable.

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_LINK_OPTIONS = list of options to pass to link command
CMAKE_REQUIRED_LIBRARIES = list of libraries to link
CMAKE_REQUIRED_QUIET = execute quietly without messages

  • cmake-modules(7) »


CheckPIESupported — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckPIESupported

Check whether the linker supports position independent code (PIE) or no position independent code (NO_PIE) for executables. Use this to ensure that the POSITION_INDEPENDENT_CODE target property for executables will be honored at link time.

check_pie_supported
check_pie_supported([OUTPUT_VARIABLE <output>]
                    [LANGUAGES <lang>...])

Options are:

OUTPUT_VARIABLE <output>
Set <output> variable with details about any error.
LANGUAGES <lang>...
Check the linkers used for each of the specified languages. Supported languages are C, CXX, and Fortran.

It makes no sense to use this module when CMP0083 is set to OLD, so the command will return an error in this case. See policy CMP0083 for details.

Variables

For each language checked, two boolean cache variables are defined.

CMAKE_<lang>_LINK_PIE_SUPPORTED
Set to YES if PIE is supported by the linker and NO otherwise.
CMAKE_<lang>_LINK_NO_PIE_SUPPORTED
Set to YES if NO_PIE is supported by the linker and NO otherwise.

Examples

check_pie_supported()
set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)

# Retrieve any error message.
check_pie_supported(OUTPUT_VARIABLE output LANGUAGES C)
set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)
if(NOT CMAKE_C_LINK_PIE_SUPPORTED)
  message(WARNING "PIE is not supported at link time: ${output}.\n"
                  "PIE link options will not be passed to linker.")
endif()

  • cmake-modules(7) »


CheckPrototypeDefinition — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckPrototypeDefinition

Check if the prototype we expect is correct.

check_prototype_definition
check_prototype_definition(FUNCTION PROTOTYPE RETURN HEADER VARIABLE)

FUNCTION - The name of the function (used to check if prototype exists)
PROTOTYPE- The prototype to check.
RETURN - The return value of the function.
HEADER - The header files required.
VARIABLE - The variable to store the result.
           Will be created as an internal cache variable.

Example:

check_prototype_definition(getpwent_r
 "struct passwd *getpwent_r(struct passwd *src, char *buf, int buflen)"
 "NULL"
 "unistd.h;pwd.h"
 SOLARIS_GETPWENT_R)

The following variables may be set before calling this function to modify the way the check is run:

CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
CMAKE_REQUIRED_LINK_OPTIONS = list of options to pass to link command
CMAKE_REQUIRED_LIBRARIES = list of libraries to link
CMAKE_REQUIRED_QUIET = execute quietly without messages

  • cmake-modules(7) »


CheckStructHasMember — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckStructHasMember

Check if the given struct or class has the specified member variable

CHECK_STRUCT_HAS_MEMBER
CHECK_STRUCT_HAS_MEMBER(<struct> <member> <header> <variable>
                        [LANGUAGE <language>])

<struct> - the name of the struct or class you are interested in
<member> - the member which existence you want to check
<header> - the header(s) where the prototype should be declared
<variable> - variable to store the result
<language> - the compiler to use (C or CXX)

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
CMAKE_REQUIRED_LINK_OPTIONS = list of options to pass to link command
CMAKE_REQUIRED_LIBRARIES = list of libraries to link
CMAKE_REQUIRED_QUIET = execute quietly without messages

Example:

CHECK_STRUCT_HAS_MEMBER("struct timeval" tv_sec sys/select.h
                        HAVE_TIMEVAL_TV_SEC LANGUAGE C)

  • cmake-modules(7) »


CheckSymbolExists — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckSymbolExists

Provides a macro to check if a symbol exists as a function, variable, or macro in C.

check_symbol_exists
check_symbol_exists(<symbol> <files> <variable>)

Check that the <symbol> is available after including given header <files> and store the result in a <variable>. Specify the list of files in one argument as a semicolon-separated list. <variable> will be created as an internal cache variable.

If the header files define the symbol as a macro it is considered available and assumed to work. If the header files declare the symbol as a function or variable then the symbol must also be available for linking (so intrinsics may not be detected). If the symbol is a type, enum value, or intrinsic it will not be recognized (consider using CheckTypeSize or CheckCSourceCompiles). If the check needs to be done in C++, consider using CheckCXXSymbolExists instead.

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS
string of compile command line flags.
CMAKE_REQUIRED_DEFINITIONS
a ;-list of macros to define (-DFOO=bar).
CMAKE_REQUIRED_INCLUDES
a ;-list of header search paths to pass to the compiler.
CMAKE_REQUIRED_LINK_OPTIONS
a ;-list of options to add to the link command.
CMAKE_REQUIRED_LIBRARIES
a ;-list of libraries to add to the link command. See policy CMP0075.
CMAKE_REQUIRED_QUIET
execute quietly without messages.

  • cmake-modules(7) »


CheckTypeSize — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckTypeSize

Check sizeof a type

CHECK_TYPE_SIZE
CHECK_TYPE_SIZE(TYPE VARIABLE [BUILTIN_TYPES_ONLY]
                              [LANGUAGE <language>])

Check if the type exists and determine its size. On return, HAVE_${VARIABLE} holds the existence of the type, and ${VARIABLE} holds one of the following:

<size> = type has non-zero size <size>
"0"    = type has arch-dependent size (see below)
""     = type does not exist

Both HAVE_${VARIABLE} and ${VARIABLE} will be created as internal cache variables.

Furthermore, the variable ${VARIABLE}_CODE holds C preprocessor code to define the macro ${VARIABLE} to the size of the type, or leave the macro undefined if the type does not exist.

The variable ${VARIABLE} may be 0 when CMAKE_OSX_ARCHITECTURES has multiple architectures for building OS X universal binaries. This indicates that the type size varies across architectures. In this case ${VARIABLE}_CODE contains C preprocessor tests mapping from each architecture macro to the corresponding type size. The list of architecture macros is stored in ${VARIABLE}_KEYS, and the value for each key is stored in ${VARIABLE}-${KEY}.

If the BUILTIN_TYPES_ONLY option is not given, the macro checks for headers <sys/types.h>, <stdint.h>, and <stddef.h>, and saves results in HAVE_SYS_TYPES_H, HAVE_STDINT_H, and HAVE_STDDEF_H. The type size check automatically includes the available headers, thus supporting checks of types defined in the headers.

If LANGUAGE is set, the specified compiler will be used to perform the check. Acceptable values are C and CXX.

Despite the name of the macro you may use it to check the size of more complex expressions, too. To check e.g. for the size of a struct member you can do something like this:

check_type_size("((struct something*)0)->member" SIZEOF_MEMBER)

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
CMAKE_REQUIRED_LINK_OPTIONS  = list of options to pass to link command
CMAKE_REQUIRED_LIBRARIES = list of libraries to link
CMAKE_REQUIRED_QUIET = execute quietly without messages
CMAKE_EXTRA_INCLUDE_FILES = list of extra headers to include

  • cmake-modules(7) »


CheckVariableExists — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CheckVariableExists

Check if the variable exists.

CHECK_VARIABLE_EXISTS
CHECK_VARIABLE_EXISTS(VAR VARIABLE)

VAR      - the name of the variable
VARIABLE - variable to store the result
           Will be created as an internal cache variable.

This macro is only for C variables.

The following variables may be set before calling this macro to modify the way the check is run:

CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_LINK_OPTIONS = list of options to pass to link command
CMAKE_REQUIRED_LIBRARIES = list of libraries to link
CMAKE_REQUIRED_QUIET = execute quietly without messages

  • cmake-modules(7) »


CMakeAddFortranSubdirectory — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeAddFortranSubdirectory

Add a fortran-only subdirectory, find a fortran compiler, and build.

The cmake_add_fortran_subdirectory function adds a subdirectory to a project that contains a fortran-only subproject. The module will check the current compiler and see if it can support fortran. If no fortran compiler is found and the compiler is MSVC, then this module will find the MinGW gfortran. It will then use an external project to build with the MinGW tools. It will also create imported targets for the libraries created. This will only work if the fortran code is built into a dll, so BUILD_SHARED_LIBS is turned on in the project. In addition the CMAKE_GNUtoMS option is set to on, so that Microsoft .lib files are created. Usage is as follows:

cmake_add_fortran_subdirectory(
 <subdir>                # name of subdirectory
 PROJECT <project_name>  # project name in subdir top CMakeLists.txt
 ARCHIVE_DIR <dir>       # dir where project places .lib files
 RUNTIME_DIR <dir>       # dir where project places .dll files
 LIBRARIES <lib>...      # names of library targets to import
 LINK_LIBRARIES          # link interface libraries for LIBRARIES
  [LINK_LIBS <lib> <dep>...]...
 CMAKE_COMMAND_LINE ...  # extra command line flags to pass to cmake
 NO_EXTERNAL_INSTALL     # skip installation of external project
 )

Relative paths in ARCHIVE_DIR and RUNTIME_DIR are interpreted with respect to the build directory corresponding to the source directory in which the function is invoked.

Limitations:

NO_EXTERNAL_INSTALL is required for forward compatibility with a future version that supports installation of the external project binaries during “make install”.

  • cmake-modules(7) »


CMakeBackwardCompatibilityCXX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeBackwardCompatibilityCXX

define a bunch of backwards compatibility variables

CMAKE_ANSI_CXXFLAGS - flag for ansi c++
CMAKE_HAS_ANSI_STRING_STREAM - has <strstream>
include(TestForANSIStreamHeaders)
include(CheckIncludeFileCXX)
include(TestForSTDNamespace)
include(TestForANSIForScope)

  • cmake-modules(7) »


CMakeDependentOption — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeDependentOption

Macro to provide an option dependent on other options.

This macro presents an option to the user only if a set of other conditions are true. When the option is not presented a default value is used, but any value set by the user is preserved for when the option is presented again. Example invocation:

CMAKE_DEPENDENT_OPTION(USE_FOO "Use Foo" ON
                       "USE_BAR;NOT USE_ZOT" OFF)

If USE_BAR is true and USE_ZOT is false, this provides an option called USE_FOO that defaults to ON. Otherwise, it sets USE_FOO to OFF. If the status of USE_BAR or USE_ZOT ever changes, any value for the USE_FOO option is saved so that when the option is re-enabled it retains its old value.

  • cmake-modules(7) »


CMakeFindDependencyMacro — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeFindDependencyMacro

find_dependency

The find_dependency() macro wraps a find_package() call for a package dependency:

find_dependency(<dep> [...])

It is designed to be used in a Package Configuration File (<PackageName>Config.cmake). find_dependency forwards the correct parameters for QUIET and REQUIRED which were passed to the original find_package() call. Any additional arguments specified are forwarded to find_package().

If the dependency could not be found it sets an informative diagnostic message and calls return() to end processing of the calling package configuration file and return to the find_package() command that loaded it.

Note

The call to return() makes this macro unsuitable to call from Find Modules.

  • cmake-modules(7) »


CMakeFindFrameworks — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeFindFrameworks

helper module to find OSX frameworks

This module reads hints about search locations from variables:

CMAKE_FIND_FRAMEWORK_EXTRA_LOCATIONS - Extra directories

  • cmake-modules(7) »


CMakeFindPackageMode — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeFindPackageMode

This file is executed by cmake when invoked with –find-package. It expects that the following variables are set using -D:

NAME
name of the package
COMPILER_ID
the CMake compiler ID for which the result is, i.e. GNU/Intel/Clang/MSVC, etc.
LANGUAGE
language for which the result will be used, i.e. C/CXX/Fortran/ASM
MODE
EXIST
only check for existence of the given package
COMPILE
print the flags needed for compiling an object file which uses the given package
LINK
print the flags needed for linking when using the given package
QUIET
if TRUE, don’t print anything

  • cmake-modules(7) »


CMakeGraphVizOptions — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeGraphVizOptions

The builtin graphviz support of CMake.

Variables specific to the graphviz support

CMake can generate graphviz files, showing the dependencies between the targets in a project and also external libraries which are linked against. When CMake is run with the --graphviz=foo.dot option, it will produce:

  • a foo.dot file showing all dependencies in the project
  • a foo.dot.<target> file for each target, file showing on which other targets the respective target depends
  • a foo.dot.<target>.dependers file, showing which other targets depend on the respective target

The different dependency types PUBLIC, PRIVATE and INTERFACE are represented as solid, dashed and dotted edges.

This can result in huge graphs. Using the file CMakeGraphVizOptions.cmake the look and content of the generated graphs can be influenced. This file is searched first in CMAKE_BINARY_DIR and then in CMAKE_SOURCE_DIR. If found, it is read and the variables set in it are used to adjust options for the generated graphviz files.

GRAPHVIZ_GRAPH_TYPE

The graph type.

  • Mandatory : NO
  • Default : “digraph”

Valid graph types are:

  • “graph” : Nodes are joined with lines
  • “digraph” : Nodes are joined with arrows showing direction
  • “strict graph” : Like “graph” but max one line between each node
  • “strict digraph” : Like “graph” but max one line between each node in each direction
GRAPHVIZ_GRAPH_NAME

The graph name.

  • Mandatory : NO
  • Default : “GG”
GRAPHVIZ_GRAPH_HEADER

The header written at the top of the graphviz file.

  • Mandatory : NO
  • Default : “node [n fontsize = “12”];”
GRAPHVIZ_NODE_PREFIX

The prefix for each node in the graphviz file.

  • Mandatory : NO
  • Default : “node”
GRAPHVIZ_EXECUTABLES

Set this to FALSE to exclude executables from the generated graphs.

  • Mandatory : NO
  • Default : TRUE
GRAPHVIZ_STATIC_LIBS

Set this to FALSE to exclude static libraries from the generated graphs.

  • Mandatory : NO
  • Default : TRUE
GRAPHVIZ_SHARED_LIBS

Set this to FALSE to exclude shared libraries from the generated graphs.

  • Mandatory : NO
  • Default : TRUE
GRAPHVIZ_MODULE_LIBS

Set this to FALSE to exclude module libraries from the generated graphs.

  • Mandatory : NO
  • Default : TRUE
GRAPHVIZ_EXTERNAL_LIBS

Set this to FALSE to exclude external libraries from the generated graphs.

  • Mandatory : NO
  • Default : TRUE
GRAPHVIZ_IGNORE_TARGETS

A list of regular expressions for ignoring targets.

  • Mandatory : NO
  • Default : empty
GRAPHVIZ_GENERATE_PER_TARGET

Set this to FALSE to exclude per target graphs foo.dot.<target>.

  • Mandatory : NO
  • Default : TRUE
GRAPHVIZ_GENERATE_DEPENDERS

Set this to FALSE to exclude depender graphs foo.dot.<target>.dependers.

  • Mandatory : NO
  • Default : TRUE

  • cmake-modules(7) »


CMakePackageConfigHelpers — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakePackageConfigHelpers

Helpers functions for creating config files that can be included by other projects to find and use a package.

Adds the configure_package_config_file() and write_basic_package_version_file() commands.

Generating a Package Configuration File

configure_package_config_file

Create a config file for a project:

configure_package_config_file(<input> <output>
  INSTALL_DESTINATION <path>
  [PATH_VARS <var1> <var2> ... <varN>]
  [NO_SET_AND_CHECK_MACRO]
  [NO_CHECK_REQUIRED_COMPONENTS_MACRO]
  [INSTALL_PREFIX <path>]
  )

configure_package_config_file() should be used instead of the plain configure_file() command when creating the <PackageName>Config.cmake or <PackageName>-config.cmake file for installing a project or library. It helps making the resulting package relocatable by avoiding hardcoded paths in the installed Config.cmake file.

In a FooConfig.cmake file there may be code like this to make the install destinations know to the using project:

set(FOO_INCLUDE_DIR   "@CMAKE_INSTALL_FULL_INCLUDEDIR@" )
set(FOO_DATA_DIR   "@CMAKE_INSTALL_PREFIX@/@RELATIVE_DATA_INSTALL_DIR@" )
set(FOO_ICONS_DIR   "@CMAKE_INSTALL_PREFIX@/share/icons" )
#...logic to determine installedPrefix from the own location...
set(FOO_CONFIG_DIR  "${installedPrefix}/@CONFIG_INSTALL_DIR@" )

All 4 options shown above are not sufficient, since the first 3 hardcode the absolute directory locations, and the 4th case works only if the logic to determine the installedPrefix is correct, and if CONFIG_INSTALL_DIR contains a relative path, which in general cannot be guaranteed. This has the effect that the resulting FooConfig.cmake file would work poorly under Windows and OSX, where users are used to choose the install location of a binary package at install time, independent from how CMAKE_INSTALL_PREFIX was set at build/cmake time.

Using configure_package_config_file helps. If used correctly, it makes the resulting FooConfig.cmake file relocatable. Usage:

  1. write a FooConfig.cmake.in file as you are used to
  2. insert a line containing only the string @PACKAGE_INIT@
  3. instead of set(FOO_DIR "@SOME_INSTALL_DIR@"), use set(FOO_DIR "@PACKAGE_SOME_INSTALL_DIR@") (this must be after the @PACKAGE_INIT@ line)
  4. instead of using the normal configure_file(), use configure_package_config_file()

The <input> and <output> arguments are the input and output file, the same way as in configure_file().

The <path> given to INSTALL_DESTINATION must be the destination where the FooConfig.cmake file will be installed to. This path can either be absolute, or relative to the INSTALL_PREFIX path.

The variables <var1> to <varN> given as PATH_VARS are the variables which contain install destinations. For each of them the macro will create a helper variable PACKAGE_<var...>. These helper variables must be used in the FooConfig.cmake.in file for setting the installed location. They are calculated by configure_package_config_file so that they are always relative to the installed location of the package. This works both for relative and also for absolute locations. For absolute locations it works only if the absolute location is a subdirectory of INSTALL_PREFIX.

If the INSTALL_PREFIX argument is passed, this is used as base path to calculate all the relative paths. The <path> argument must be an absolute path. If this argument is not passed, the CMAKE_INSTALL_PREFIX variable will be used instead. The default value is good when generating a FooConfig.cmake file to use your package from the install tree. When generating a FooConfig.cmake file to use your package from the build tree this option should be used.

By default configure_package_config_file also generates two helper macros, set_and_check() and check_required_components() into the FooConfig.cmake file.

set_and_check() should be used instead of the normal set() command for setting directories and file locations. Additionally to setting the variable it also checks that the referenced file or directory actually exists and fails with a FATAL_ERROR otherwise. This makes sure that the created FooConfig.cmake file does not contain wrong references. When using the NO_SET_AND_CHECK_MACRO, this macro is not generated into the FooConfig.cmake file.

check_required_components(<PackageName>) should be called at the end of the FooConfig.cmake file. This macro checks whether all requested, non-optional components have been found, and if this is not the case, sets the Foo_FOUND variable to FALSE, so that the package is considered to be not found. It does that by testing the Foo_<Component>_FOUND variables for all requested required components. This macro should be called even if the package doesn’t provide any components to make sure users are not specifying components erroneously. When using the NO_CHECK_REQUIRED_COMPONENTS_MACRO option, this macro is not generated into the FooConfig.cmake file.

For an example see below the documentation for write_basic_package_version_file().

Generating a Package Version File

write_basic_package_version_file

Create a version file for a project:

write_basic_package_version_file(<filename>
  [VERSION <major.minor.patch>]
  COMPATIBILITY <AnyNewerVersion|SameMajorVersion|SameMinorVersion|ExactVersion>
  [ARCH_INDEPENDENT] )

Writes a file for use as <PackageName>ConfigVersion.cmake file to <filename>. See the documentation of find_package() for details on this.

<filename> is the output filename, it should be in the build tree. <major.minor.patch> is the version number of the project to be installed.

If no VERSION is given, the PROJECT_VERSION variable is used. If this hasn’t been set, it errors out.

The COMPATIBILITY mode AnyNewerVersion means that the installed package version will be considered compatible if it is newer or exactly the same as the requested version. This mode should be used for packages which are fully backward compatible, also across major versions. If SameMajorVersion is used instead, then the behaviour differs from AnyNewerVersion in that the major version number must be the same as requested, e.g. version 2.0 will not be considered compatible if 1.0 is requested. This mode should be used for packages which guarantee backward compatibility within the same major version. If SameMinorVersion is used, the behaviour is the same as SameMajorVersion, but both major and minor version must be the same as requested, e.g version 0.2 will not be compatible if 0.1 is requested. If ExactVersion is used, then the package is only considered compatible if the requested version matches exactly its own version number (not considering the tweak version). For example, version 1.2.3 of a package is only considered compatible to requested version 1.2.3. This mode is for packages without compatibility guarantees. If your project has more elaborated version matching rules, you will need to write your own custom ConfigVersion.cmake file instead of using this macro.

If ARCH_INDEPENDENT is given, the installed package version will be considered compatible even if it was built for a different architecture than the requested architecture. Otherwise, an architecture check will be performed, and the package will be considered compatible only if the architecture matches exactly. For example, if the package is built for a 32-bit architecture, the package is only considered compatible if it is used on a 32-bit architecture, unless ARCH_INDEPENDENT is given, in which case the package is considered compatible on any architecture.

Note

ARCH_INDEPENDENT is intended for header-only libraries or similar packages with no binaries.

Internally, this macro executes configure_file() to create the resulting version file. Depending on the COMPATIBILITY, the corresponding BasicConfigVersion-<COMPATIBILITY>.cmake.in file is used. Please note that these files are internal to CMake and you should not call configure_file() on them yourself, but they can be used as starting point to create more sophisticted custom ConfigVersion.cmake files.

Example Generating Package Files

Example using both configure_package_config_file() and write_basic_package_version_file():

CMakeLists.txt:

set(INCLUDE_INSTALL_DIR include/ ... CACHE )
set(LIB_INSTALL_DIR lib/ ... CACHE )
set(SYSCONFIG_INSTALL_DIR etc/foo/ ... CACHE )
#...
include(CMakePackageConfigHelpers)
configure_package_config_file(FooConfig.cmake.in
  ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
  INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
  PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
write_basic_package_version_file(
  ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
  VERSION 1.2.3
  COMPATIBILITY SameMajorVersion )
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
              ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
        DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )

FooConfig.cmake.in:

set(FOO_VERSION x.y.z)
...
@PACKAGE_INIT@
...
set_and_check(FOO_INCLUDE_DIR "@PACKAGE_INCLUDE_INSTALL_DIR@")
set_and_check(FOO_SYSCONFIG_DIR "@PACKAGE_SYSCONFIG_INSTALL_DIR@")

check_required_components(Foo)

  • cmake-modules(7) »


CMakePrintHelpers — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakePrintHelpers

Convenience functions for printing properties and variables, useful e.g. for debugging.

cmake_print_properties([TARGETS target1 ..  targetN]
                      [SOURCES source1 .. sourceN]
                      [DIRECTORIES dir1 .. dirN]
                      [TESTS test1 .. testN]
                      [CACHE_ENTRIES entry1 .. entryN]
                      PROPERTIES prop1 .. propN )

This function prints the values of the properties of the given targets, source files, directories, tests or cache entries. Exactly one of the scope keywords must be used. Example:

cmake_print_properties(TARGETS foo bar PROPERTIES
                       LOCATION INTERFACE_INCLUDE_DIRS)

This will print the LOCATION and INTERFACE_INCLUDE_DIRS properties for both targets foo and bar.

cmake_print_variables(var1 var2 ..  varN)

This function will print the name of each variable followed by its value. Example:

cmake_print_variables(CMAKE_C_COMPILER CMAKE_MAJOR_VERSION DOES_NOT_EXIST)

Gives:

-- CMAKE_C_COMPILER="/usr/bin/gcc" ; CMAKE_MAJOR_VERSION="2" ; DOES_NOT_EXIST=""

  • cmake-modules(7) »


CMakePrintSystemInformation — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakePrintSystemInformation

print system information

This file can be used for diagnostic purposes just include it in a project to see various internal CMake variables.

  • cmake-modules(7) »


CMakePushCheckState — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakePushCheckState

This module defines three macros: CMAKE_PUSH_CHECK_STATE() CMAKE_POP_CHECK_STATE() and CMAKE_RESET_CHECK_STATE() These macros can be used to save, restore and reset (i.e., clear contents) the state of the variables CMAKE_REQUIRED_FLAGS, CMAKE_REQUIRED_DEFINITIONS, CMAKE_REQUIRED_LINK_OPTIONS, CMAKE_REQUIRED_LIBRARIES, CMAKE_REQUIRED_INCLUDES and CMAKE_EXTRA_INCLUDE_FILES used by the various Check-files coming with CMake, like e.g. check_function_exists() etc. The variable contents are pushed on a stack, pushing multiple times is supported. This is useful e.g. when executing such tests in a Find-module, where they have to be set, but after the Find-module has been executed they should have the same value as they had before.

CMAKE_PUSH_CHECK_STATE() macro receives optional argument RESET. Whether it’s specified, CMAKE_PUSH_CHECK_STATE() will set all CMAKE_REQUIRED_* variables to empty values, same as CMAKE_RESET_CHECK_STATE() call will do.

Usage:

cmake_push_check_state(RESET)
set(CMAKE_REQUIRED_DEFINITIONS -DSOME_MORE_DEF)
check_function_exists(...)
cmake_reset_check_state()
set(CMAKE_REQUIRED_DEFINITIONS -DANOTHER_DEF)
check_function_exists(...)
cmake_pop_check_state()

  • cmake-modules(7) »


CMakeVerifyManifest — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeVerifyManifest

CMakeVerifyManifest.cmake

This script is used to verify that embedded manifests and side by side manifests for a project match. To run this script, cd to a directory and run the script with cmake -P. On the command line you can pass in versions that are OK even if not found in the .manifest files. For example, cmake -Dallow_versions=8.0.50608.0 -PCmakeVerifyManifest.cmake could be used to allow an embedded manifest of 8.0.50608.0 to be used in a project even if that version was not found in the .manifest file.

  • cmake-modules(7) »


CPackComponent — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackComponent

Build binary and source package installers

Variables concerning CPack Components

The CPackComponent module is the module which handles the component part of CPack. See CPack module for general information about CPack.

For certain kinds of binary installers (including the graphical installers on macOS and Windows), CPack generates installers that allow users to select individual application components to install. The contents of each of the components are identified by the COMPONENT argument of CMake’s INSTALL command. These components can be annotated with user-friendly names and descriptions, inter-component dependencies, etc., and grouped in various ways to customize the resulting installer. See the cpack_add_* commands, described below, for more information about component-specific installations.

Component-specific installation allows users to select specific sets of components to install during the install process. Installation components are identified by the COMPONENT argument of CMake’s INSTALL commands, and should be further described by the following CPack commands:

CPACK_COMPONENTS_ALL

The list of component to install.

The default value of this variable is computed by CPack and contains all components defined by the project. The user may set it to only include the specified components.

Instead of specifying all the desired components, it is possible to obtain a list of all defined components and then remove the unwanted ones from the list. The get_cmake_property() command can be used to obtain the COMPONENTS property, then the list(REMOVE_ITEM) command can be used to remove the unwanted ones. For example, to use all defined components except foo and bar:

get_cmake_property(CPACK_COMPONENTS_ALL COMPONENTS)
list(REMOVE_ITEM CPACK_COMPONENTS_ALL "foo" "bar")
CPACK_<GENNAME>_COMPONENT_INSTALL

Enable/Disable component install for CPack generator <GENNAME>.

Each CPack Generator (RPM, DEB, ARCHIVE, NSIS, DMG, etc…) has a legacy default behavior. e.g. RPM builds monolithic whereas NSIS builds component. One can change the default behavior by setting this variable to 0/1 or OFF/ON.

CPACK_COMPONENTS_GROUPING

Specify how components are grouped for multi-package component-aware CPack generators.

Some generators like RPM or ARCHIVE family (TGZ, ZIP, …) generates several packages files when asked for component packaging. They group the component differently depending on the value of this variable:

  • ONE_PER_GROUP (default): creates one package file per component group
  • ALL_COMPONENTS_IN_ONE : creates a single package with all (requested) components
  • IGNORE : creates one package per component, i.e. IGNORE component group

One can specify different grouping for different CPack generator by using a CPACK_PROJECT_CONFIG_FILE.

CPACK_COMPONENT_<compName>_DISPLAY_NAME

The name to be displayed for a component.

CPACK_COMPONENT_<compName>_DESCRIPTION

The description of a component.

CPACK_COMPONENT_<compName>_GROUP

The group of a component.

CPACK_COMPONENT_<compName>_DEPENDS

The dependencies (list of components) on which this component depends.

CPACK_COMPONENT_<compName>_HIDDEN

True if this component is hidden from the user.

CPACK_COMPONENT_<compName>_REQUIRED

True if this component is required.

CPACK_COMPONENT_<compName>_DISABLED

True if this component is not selected to be installed by default.

cpack_add_component

Describes a CPack installation component named by the COMPONENT argument to a CMake INSTALL command.

cpack_add_component(compname
                    [DISPLAY_NAME name]
                    [DESCRIPTION description]
                    [HIDDEN | REQUIRED | DISABLED ]
                    [GROUP group]
                    [DEPENDS comp1 comp2 ... ]
                    [INSTALL_TYPES type1 type2 ... ]
                    [DOWNLOADED]
                    [ARCHIVE_FILE filename]
                    [PLIST filename])

The cmake_add_component command describes an installation component, which the user can opt to install or remove as part of the graphical installation process. compname is the name of the component, as provided to the COMPONENT argument of one or more CMake INSTALL commands.

DISPLAY_NAME is the displayed name of the component, used in graphical installers to display the component name. This value can be any string.

DESCRIPTION is an extended description of the component, used in graphical installers to give the user additional information about the component. Descriptions can span multiple lines using \n as the line separator. Typically, these descriptions should be no more than a few lines long.

HIDDEN indicates that this component will be hidden in the graphical installer, so that the user cannot directly change whether it is installed or not.

REQUIRED indicates that this component is required, and therefore will always be installed. It will be visible in the graphical installer, but it cannot be unselected. (Typically, required components are shown greyed out).

DISABLED indicates that this component should be disabled (unselected) by default. The user is free to select this component for installation, unless it is also HIDDEN.

DEPENDS lists the components on which this component depends. If this component is selected, then each of the components listed must also be selected. The dependency information is encoded within the installer itself, so that users cannot install inconsistent sets of components.

GROUP names the component group of which this component is a part. If not provided, the component will be a standalone component, not part of any component group. Component groups are described with the cpack_add_component_group command, detailed below.

INSTALL_TYPES lists the installation types of which this component is a part. When one of these installations types is selected, this component will automatically be selected. Installation types are described with the cpack_add_install_type command, detailed below.

DOWNLOADED indicates that this component should be downloaded on-the-fly by the installer, rather than packaged in with the installer itself. For more information, see the cpack_configure_downloads command.

ARCHIVE_FILE provides a name for the archive file created by CPack to be used for downloaded components. If not supplied, CPack will create a file with some name based on CPACK_PACKAGE_FILE_NAME and the name of the component. See cpack_configure_downloads for more information.

PLIST gives a filename that is passed to pkgbuild with the --component-plist argument when using the productbuild generator.

cpack_add_component_group

Describes a group of related CPack installation components.

cpack_add_component_group(groupname
                         [DISPLAY_NAME name]
                         [DESCRIPTION description]
                         [PARENT_GROUP parent]
                         [EXPANDED]
                         [BOLD_TITLE])

The cpack_add_component_group describes a group of installation components, which will be placed together within the listing of options. Typically, component groups allow the user to select/deselect all of the components within a single group via a single group-level option. Use component groups to reduce the complexity of installers with many options. groupname is an arbitrary name used to identify the group in the GROUP argument of the cpack_add_component command, which is used to place a component in a group. The name of the group must not conflict with the name of any component.

DISPLAY_NAME is the displayed name of the component group, used in graphical installers to display the component group name. This value can be any string.

DESCRIPTION is an extended description of the component group, used in graphical installers to give the user additional information about the components within that group. Descriptions can span multiple lines using \n as the line separator. Typically, these descriptions should be no more than a few lines long.

PARENT_GROUP, if supplied, names the parent group of this group. Parent groups are used to establish a hierarchy of groups, providing an arbitrary hierarchy of groups.

EXPANDED indicates that, by default, the group should show up as “expanded”, so that the user immediately sees all of the components within the group. Otherwise, the group will initially show up as a single entry.

BOLD_TITLE indicates that the group title should appear in bold, to call the user’s attention to the group.

cpack_add_install_type

Add a new installation type containing a set of predefined component selections to the graphical installer.

cpack_add_install_type(typename
                       [DISPLAY_NAME name])

The cpack_add_install_type command identifies a set of preselected components that represents a common use case for an application. For example, a “Developer” install type might include an application along with its header and library files, while an “End user” install type might just include the application’s executable. Each component identifies itself with one or more install types via the INSTALL_TYPES argument to cpack_add_component.

DISPLAY_NAME is the displayed name of the install type, which will typically show up in a drop-down box within a graphical installer. This value can be any string.

cpack_configure_downloads

Configure CPack to download selected components on-the-fly as part of the installation process.

cpack_configure_downloads(site
                          [UPLOAD_DIRECTORY dirname]
                          [ALL]
                          [ADD_REMOVE|NO_ADD_REMOVE])

The cpack_configure_downloads command configures installation-time downloads of selected components. For each downloadable component, CPack will create an archive containing the contents of that component, which should be uploaded to the given site. When the user selects that component for installation, the installer will download and extract the component in place. This feature is useful for creating small installers that only download the requested components, saving bandwidth. Additionally, the installers are small enough that they will be installed as part of the normal installation process, and the “Change” button in Windows Add/Remove Programs control panel will allow one to add or remove parts of the application after the original installation. On Windows, the downloaded-components functionality requires the ZipDLL plug-in for NSIS, available at:

http://nsis.sourceforge.net/ZipDLL_plug-in

On macOS, installers that download components on-the-fly can only be built and installed on system using macOS 10.5 or later.

The site argument is a URL where the archives for downloadable components will reside, e.g., https://cmake.org/files/2.6.1/installer/ All of the archives produced by CPack should be uploaded to that location.

UPLOAD_DIRECTORY is the local directory where CPack will create the various archives for each of the components. The contents of this directory should be uploaded to a location accessible by the URL given in the site argument. If omitted, CPack will use the directory CPackUploads inside the CMake binary directory to store the generated archives.

The ALL flag indicates that all components be downloaded. Otherwise, only those components explicitly marked as DOWNLOADED or that have a specified ARCHIVE_FILE will be downloaded. Additionally, the ALL option implies ADD_REMOVE (unless NO_ADD_REMOVE is specified).

ADD_REMOVE indicates that CPack should install a copy of the installer that can be called from Windows’ Add/Remove Programs dialog (via the “Modify” button) to change the set of installed components. NO_ADD_REMOVE turns off this behavior. This option is ignored on Mac OS X.

  • cmake-modules(7) »


CPackIFW — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackIFW

The documentation for the CPack IFW generator has moved here: CPack IFW Generator

This module looks for the location of the command line utilities supplied with the Qt Installer Framework (QtIFW).

The module also defines several commands to control the behavior of the CPack IFW generator.

Commands

The module defines the following commands:

cpack_ifw_configure_component

Sets the arguments specific to the CPack IFW generator.

cpack_ifw_configure_component(<compname> [COMMON] [ESSENTIAL] [VIRTUAL]
                    [FORCED_INSTALLATION] [REQUIRES_ADMIN_RIGHTS]
                    [NAME <name>]
                    [DISPLAY_NAME <display_name>] # Note: Internationalization supported
                    [DESCRIPTION <description>] # Note: Internationalization supported
                    [UPDATE_TEXT <update_text>]
                    [VERSION <version>]
                    [RELEASE_DATE <release_date>]
                    [SCRIPT <script>]
                    [PRIORITY|SORTING_PRIORITY <sorting_priority>] # Note: PRIORITY is deprecated
                    [DEPENDS|DEPENDENCIES <com_id> ...]
                    [AUTO_DEPEND_ON <comp_id> ...]
                    [LICENSES <display_name> <file_path> ...]
                    [DEFAULT <value>]
                    [USER_INTERFACES <file_path> <file_path> ...]
                    [TRANSLATIONS <file_path> <file_path> ...]
                    [REPLACES <comp_id> ...]
                    [CHECKABLE <value>])

This command should be called after cpack_add_component() command.

COMMON
if set, then the component will be packaged and installed as part of a group to which it belongs.
ESSENTIAL
if set, then the package manager stays disabled until that component is updated.
VIRTUAL
if set, then the component will be hidden from the installer. It is a equivalent of the HIDDEN option from the cpack_add_component() command.
FORCED_INSTALLATION
if set, then the component must always be installed. It is a equivalent of the REQUARED option from the cpack_add_component() command.
REQUIRES_ADMIN_RIGHTS
set it if the component needs to be installed with elevated permissions.
NAME
is used to create domain-like identification for this component. By default used origin component name.
DISPLAY_NAME
set to rewrite original name configured by cpack_add_component() command.
DESCRIPTION
set to rewrite original description configured by cpack_add_component() command.
UPDATE_TEXT
will be added to the component description if this is an update to the component.
VERSION
is version of component. By default used CPACK_PACKAGE_VERSION.
RELEASE_DATE
keep empty to auto generate.
SCRIPT
is a relative or absolute path to operations script for this component.
PRIORITY | SORTING_PRIORITY
is priority of the component in the tree. The PRIORITY option is deprecated and will be removed in a future version of CMake. Please use SORTING_PRIORITY option instead.
DEPENDS | DEPENDENCIES
list of dependency component or component group identifiers in QtIFW style.
AUTO_DEPEND_ON
list of identifiers of component or component group in QtIFW style that this component has an automatic dependency on.
LICENSES
pair of <display_name> and <file_path> of license text for this component. You can specify more then one license.
DEFAULT
Possible values are: TRUE, FALSE, and SCRIPT. Set to FALSE to disable the component in the installer or to SCRIPT to resolved during runtime (don’t forget add the file of the script as a value of the SCRIPT option).
USER_INTERFACES
is a list of <file_path> (‘.ui’ files) representing pages to load.
TRANSLATIONS
is a list of <file_path> (‘.qm’ files) representing translations to load.
REPLACES
list of identifiers of component or component group to replace.
CHECKABLE
Possible values are: TRUE, FALSE. Set to FALSE if you want to hide the checkbox for an item. This is useful when only a few subcomponents should be selected instead of all.
cpack_ifw_configure_component_group

Sets the arguments specific to the CPack IFW generator.

cpack_ifw_configure_component_group(<groupname> [VIRTUAL]
                    [FORCED_INSTALLATION] [REQUIRES_ADMIN_RIGHTS]
                    [NAME <name>]
                    [DISPLAY_NAME <display_name>] # Note: Internationalization supported
                    [DESCRIPTION <description>] # Note: Internationalization supported
                    [UPDATE_TEXT <update_text>]
                    [VERSION <version>]
                    [RELEASE_DATE <release_date>]
                    [SCRIPT <script>]
                    [PRIORITY|SORTING_PRIORITY <sorting_priority>] # Note: PRIORITY is deprecated
                    [DEPENDS|DEPENDENCIES <com_id> ...]
                    [AUTO_DEPEND_ON <comp_id> ...]
                    [LICENSES <display_name> <file_path> ...]
                    [DEFAULT <value>]
                    [USER_INTERFACES <file_path> <file_path> ...]
                    [TRANSLATIONS <file_path> <file_path> ...]
                    [REPLACES <comp_id> ...]
                    [CHECKABLE <value>])

This command should be called after cpack_add_component_group() command.

VIRTUAL
if set, then the group will be hidden from the installer. Note that setting this on a root component does not work.
FORCED_INSTALLATION
if set, then the group must always be installed.
REQUIRES_ADMIN_RIGHTS
set it if the component group needs to be installed with elevated permissions.
NAME
is used to create domain-like identification for this component group. By default used origin component group name.
DISPLAY_NAME
set to rewrite original name configured by cpack_add_component_group() command.
DESCRIPTION
set to rewrite original description configured by cpack_add_component_group() command.
UPDATE_TEXT
will be added to the component group description if this is an update to the component group.
VERSION
is version of component group. By default used CPACK_PACKAGE_VERSION.
RELEASE_DATE
keep empty to auto generate.
SCRIPT
is a relative or absolute path to operations script for this component group.
PRIORITY | SORTING_PRIORITY
is priority of the component group in the tree. The PRIORITY option is deprecated and will be removed in a future version of CMake. Please use SORTING_PRIORITY option instead.
DEPENDS | DEPENDENCIES
list of dependency component or component group identifiers in QtIFW style.
AUTO_DEPEND_ON
list of identifiers of component or component group in QtIFW style that this component group has an automatic dependency on.
LICENSES
pair of <display_name> and <file_path> of license text for this component group. You can specify more then one license.
DEFAULT
Possible values are: TRUE, FALSE, and SCRIPT. Set to TRUE to preselect the group in the installer (this takes effect only on groups that have no visible child components) or to SCRIPT to resolved during runtime (don’t forget add the file of the script as a value of the SCRIPT option).
USER_INTERFACES
is a list of <file_path> (‘.ui’ files) representing pages to load.
TRANSLATIONS
is a list of <file_path> (‘.qm’ files) representing translations to load.
REPLACES
list of identifiers of component or component group to replace.
CHECKABLE
Possible values are: TRUE, FALSE. Set to FALSE if you want to hide the checkbox for an item. This is useful when only a few subcomponents should be selected instead of all.
cpack_ifw_add_repository

Add QtIFW specific remote repository to binary installer.

cpack_ifw_add_repository(<reponame> [DISABLED]
                    URL <url>
                    [USERNAME <username>]
                    [PASSWORD <password>]
                    [DISPLAY_NAME <display_name>])

This command will also add the <reponame> repository to a variable CPACK_IFW_REPOSITORIES_ALL.

DISABLED
if set, then the repository will be disabled by default.
URL
is points to a list of available components.
USERNAME
is used as user on a protected repository.
PASSWORD
is password to use on a protected repository.
DISPLAY_NAME
is string to display instead of the URL.
cpack_ifw_update_repository

Update QtIFW specific repository from remote repository.

cpack_ifw_update_repository(<reponame>
                    [[ADD|REMOVE] URL <url>]|
                     [REPLACE OLD_URL <old_url> NEW_URL <new_url>]]
                    [USERNAME <username>]
                    [PASSWORD <password>]
                    [DISPLAY_NAME <display_name>])

This command will also add the <reponame> repository to a variable CPACK_IFW_REPOSITORIES_ALL.

URL
is points to a list of available components.
OLD_URL
is points to a list that will replaced.
NEW_URL
is points to a list that will replace to.
USERNAME
is used as user on a protected repository.
PASSWORD
is password to use on a protected repository.
DISPLAY_NAME
is string to display instead of the URL.
cpack_ifw_add_package_resources

Add additional resources in the installer binary.

cpack_ifw_add_package_resources(<file_path> <file_path> ...)

This command will also add the specified files to a variable CPACK_IFW_PACKAGE_RESOURCES.

  • cmake-modules(7) »


CPackIFWConfigureFile — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackIFWConfigureFile

The module defines configure_file() similar command to configure file templates prepared in QtIFW/SDK/Creator style.

Commands

The module defines the following commands:

cpack_ifw_configure_file

Copy a file to another location and modify its contents.

cpack_ifw_configure_file(<input> <output>)

Copies an <input> file to an <output> file and substitutes variable values referenced as %{VAR} or %VAR% in the input file content. Each variable reference will be replaced with the current value of the variable, or the empty string if the variable is not defined.

  • cmake-modules(7) »


CPack — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPack

Build binary and source package installers.

Introduction

The CPack module generates a file CPackConfig.cmake intended for use in a subsequent run of the cpack program where it steers the generation of installers or/and source packages.

Inclusion of the CPack module adds two new build targets, package and package_source, which build the binary and source installers respectively. The generated binary installers contain everything installed via CMake’s install() command (and the deprecated commands install_files(), install_programs(), and install_targets()).

For certain kinds of binary installers (including the graphical installers on macOS and Windows), CPack generates installers that allow users to select individual application components to install. See CPackComponent module for further details.

CPack Generators

The CPACK_GENERATOR variable has different meanings in different contexts. In a CMakeLists.txt file, CPACK_GENERATOR is a list of generators: and when cpack is run with no other arguments, it will iterate over that list and produce one package for each generator. In a CPACK_PROJECT_CONFIG_FILE, CPACK_GENERATOR is a string naming a single generator. If you need per-cpack-generator logic to control other cpack settings, then you need a CPACK_PROJECT_CONFIG_FILE.

The CMake source tree itself contains a CPACK_PROJECT_CONFIG_FILE. See the top level file CMakeCPackOptions.cmake.in for an example.

If set, the CPACK_PROJECT_CONFIG_FILE is included automatically on a per-generator basis. It only need contain overrides.

Here’s how it works:

  • cpack runs
  • it includes CPackConfig.cmake
  • it iterates over the generators given by the -G command line option, or if no such option was specified, over the list of generators given by the CPACK_GENERATOR variable set in the CPackConfig.cmake input file.
  • foreach generator, it then
    • sets CPACK_GENERATOR to the one currently being iterated
    • includes the CPACK_PROJECT_CONFIG_FILE
    • produces the package for that generator

This is the key: For each generator listed in CPACK_GENERATOR in CPackConfig.cmake, cpack will reset CPACK_GENERATOR internally to the one currently being used and then include the CPACK_PROJECT_CONFIG_FILE.

Variables common to all CPack Generators

Before including this CPack module in your CMakeLists.txt file, there are a variety of variables that can be set to customize the resulting installers. The most commonly-used variables are:

CPACK_PACKAGE_NAME

The name of the package (or application). If not specified, it defaults to the project name.

CPACK_PACKAGE_VENDOR

The name of the package vendor. (e.g., “Kitware”). The default is “Humanity”.

CPACK_PACKAGE_DIRECTORY

The directory in which CPack is doing its packaging. If it is not set then this will default (internally) to the build dir. This variable may be defined in a CPack config file or from the cpack command line option -B. If set, the command line option overrides the value found in the config file.

CPACK_PACKAGE_VERSION_MAJOR

Package major version. This variable will always be set, but its default value depends on whether or not version details were given to the project() command in the top level CMakeLists.txt file. If version details were given, the default value will be CMAKE_PROJECT_VERSION_MAJOR. If no version details were given, a default version of 0.1.1 will be assumed, leading to CPACK_PACKAGE_VERSION_MAJOR having a default value of 0.

CPACK_PACKAGE_VERSION_MINOR

Package minor version. The default value is determined based on whether or not version details were given to the project() command in the top level CMakeLists.txt file. If version details were given, the default value will be CMAKE_PROJECT_VERSION_MINOR, but if no minor version component was specified then CPACK_PACKAGE_VERSION_MINOR will be left unset. If no project version was given at all, a default version of 0.1.1 will be assumed, leading to CPACK_PACKAGE_VERSION_MINOR having a default value of 1.

CPACK_PACKAGE_VERSION_PATCH

Package patch version. The default value is determined based on whether or not version details were given to the project() command in the top level CMakeLists.txt file. If version details were given, the default value will be CMAKE_PROJECT_VERSION_PATCH, but if no patch version component was specified then CPACK_PACKAGE_VERSION_PATCH will be left unset. If no project version was given at all, a default version of 0.1.1 will be assumed, leading to CPACK_PACKAGE_VERSION_PATCH having a default value of 1.

CPACK_PACKAGE_DESCRIPTION

A description of the project, used in places such as the introduction screen of CPack-generated Windows installers. If not set, the value of this variable is populated from the file named by CPACK_PACKAGE_DESCRIPTION_FILE.

CPACK_PACKAGE_DESCRIPTION_FILE

A text file used to describe the project when CPACK_PACKAGE_DESCRIPTION is not explicitly set. The default value for CPACK_PACKAGE_DESCRIPTION_FILE points to a built-in template file Templates/CPack.GenericDescription.txt.

CPACK_PACKAGE_DESCRIPTION_SUMMARY

Short description of the project (only a few words). If the CMAKE_PROJECT_DESCRIPTION variable is set, it is used as the default value, otherwise the default will be a string generated by CMake based on CMAKE_PROJECT_NAME.

CPACK_PACKAGE_HOMEPAGE_URL

Project homepage URL. The default value is taken from the CMAKE_PROJECT_HOMEPAGE_URL variable, which is set by the top level project() command, or else the default will be empty if no URL was provided to project().

CPACK_PACKAGE_FILE_NAME

The name of the package file to generate, not including the extension. For example, cmake-2.6.1-Linux-i686. The default value is:

${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}
CPACK_PACKAGE_INSTALL_DIRECTORY

Installation directory on the target system. This may be used by some CPack generators like NSIS to create an installation directory e.g., “CMake 2.5” below the installation prefix. All installed elements will be put inside this directory.

CPACK_PACKAGE_ICON

A branding image that will be displayed inside the installer (used by GUI installers).

CPACK_PACKAGE_CHECKSUM

An algorithm that will be used to generate an additional file with the checksum of the package. The output file name will be:

${CPACK_PACKAGE_FILE_NAME}.${CPACK_PACKAGE_CHECKSUM}

Supported algorithms are those listed by the string(<HASH>) command.

CPACK_PROJECT_CONFIG_FILE

CPack-time project CPack configuration file. This file is included at cpack time, once per generator after CPack has set CPACK_GENERATOR to the actual generator being used. It allows per-generator setting of CPACK_* variables at cpack time.

CPACK_RESOURCE_FILE_LICENSE

License to be embedded in the installer. It will typically be displayed to the user by the produced installer (often with an explicit “Accept” button, for graphical installers) prior to installation. This license file is NOT added to the installed files but is used by some CPack generators like NSIS. If you want to install a license file (may be the same as this one) along with your project, you must add an appropriate CMake install() command in your CMakeLists.txt.

CPACK_RESOURCE_FILE_README

ReadMe file to be embedded in the installer. It typically describes in some detail the purpose of the project during the installation. Not all CPack generators use this file.

CPACK_RESOURCE_FILE_WELCOME

Welcome file to be embedded in the installer. It welcomes users to this installer. Typically used in the graphical installers on Windows and Mac OS X.

CPACK_MONOLITHIC_INSTALL

Disables the component-based installation mechanism. When set, the component specification is ignored and all installed items are put in a single “MONOLITHIC” package. Some CPack generators do monolithic packaging by default and may be asked to do component packaging by setting CPACK_<GENNAME>_COMPONENT_INSTALL to TRUE.

CPACK_GENERATOR

List of CPack generators to use. If not specified, CPack will create a set of options following the naming pattern CPACK_BINARY_<GENNAME> (e.g. CPACK_BINARY_NSIS) allowing the user to enable/disable individual generators. If the -G option is given on the cpack command line, it will override this variable and any CPACK_BINARY_<GENNAME> options.

CPACK_OUTPUT_CONFIG_FILE

The name of the CPack binary configuration file. This file is the CPack configuration generated by the CPack module for binary installers. Defaults to CPackConfig.cmake.

CPACK_PACKAGE_EXECUTABLES

Lists each of the executables and associated text label to be used to create Start Menu shortcuts. For example, setting this to the list ccmake;CMake will create a shortcut named “CMake” that will execute the installed executable ccmake. Not all CPack generators use it (at least NSIS, WIX and OSXX11 do).

CPACK_STRIP_FILES

List of files to be stripped. Starting with CMake 2.6.0, CPACK_STRIP_FILES will be a boolean variable which enables stripping of all files (a list of files evaluates to TRUE in CMake, so this change is compatible).

CPACK_VERBATIM_VARIABLES

If set to TRUE, values of variables prefixed with CPACK_ will be escaped before being written to the configuration files, so that the cpack program receives them exactly as they were specified. If not, characters like quotes and backslashes can cause parsing errors or alter the value received by the cpack program. Defaults to FALSE for backwards compatibility.

Variables for Source Package Generators

The following CPack variables are specific to source packages, and will not affect binary packages:

CPACK_SOURCE_PACKAGE_FILE_NAME

The name of the source package. For example cmake-2.6.1.

CPACK_SOURCE_STRIP_FILES

List of files in the source tree that will be stripped. Starting with CMake 2.6.0, CPACK_SOURCE_STRIP_FILES will be a boolean variable which enables stripping of all files (a list of files evaluates to TRUE in CMake, so this change is compatible).

CPACK_SOURCE_GENERATOR

List of generators used for the source packages. As with CPACK_GENERATOR, if this is not specified then CPack will create a set of options (e.g. CPACK_SOURCE_ZIP) allowing users to select which packages will be generated.

CPACK_SOURCE_OUTPUT_CONFIG_FILE

The name of the CPack source configuration file. This file is the CPack configuration generated by the CPack module for source installers. Defaults to CPackSourceConfig.cmake.

CPACK_SOURCE_IGNORE_FILES

Pattern of files in the source tree that won’t be packaged when building a source package. This is a list of regular expression patterns (that must be properly escaped), e.g., /CVS/;/\\.svn/;\\.swp$;\\.#;/#;.*~;cscope.*

Variables for Advanced Use

The following variables are for advanced uses of CPack:

CPACK_CMAKE_GENERATOR

What CMake generator should be used if the project is a CMake project. Defaults to the value of CMAKE_GENERATOR. Few users will want to change this setting.

CPACK_INSTALL_CMAKE_PROJECTS

List of four values that specify what project to install. The four values are: Build directory, Project Name, Project Component, Directory. If omitted, CPack will build an installer that installs everything.

CPACK_SYSTEM_NAME

System name, defaults to the value of CMAKE_SYSTEM_NAME, except on Windows where it will be win32 or win64.

CPACK_PACKAGE_VERSION

Package full version, used internally. By default, this is built from CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR, and CPACK_PACKAGE_VERSION_PATCH.

CPACK_TOPLEVEL_TAG

Directory for the installed files.

CPACK_INSTALL_COMMANDS

Extra commands to install components.

CPACK_INSTALLED_DIRECTORIES

Extra directories to install.

CPACK_PACKAGE_INSTALL_REGISTRY_KEY

Registry key used when installing this project. This is only used by installers for Windows. The default value is based on the installation directory.

CPACK_CREATE_DESKTOP_LINKS

List of desktop links to create. Each desktop link requires a corresponding start menu shortcut as created by CPACK_PACKAGE_EXECUTABLES.

CPACK_BINARY_<GENNAME>

CPack generated options for binary generators. The CPack.cmake module generates (when CPACK_GENERATOR is not set) a set of CMake options (see CMake option() command) which may then be used to select the CPack generator(s) to be used when building the package target or when running cpack without the -G option.

  • cmake-modules(7) »


CSharpUtilities — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CSharpUtilities

Functions to make configuration of CSharp/.NET targets easier.

A collection of CMake utility functions useful for dealing with CSharp targets for Visual Studio generators from version 2010 and later.

The following functions are provided by this module:

Main functions

  • csharp_set_windows_forms_properties()
  • csharp_set_designer_cs_properties()
  • csharp_set_xaml_cs_properties()

Helper functions

  • csharp_get_filename_keys()
  • csharp_get_filename_key_base()
  • csharp_get_dependentupon_name()

Main functions provided by the module

csharp_set_windows_forms_properties

Sets source file properties for use of Windows Forms. Use this, if your CSharp target uses Windows Forms:

csharp_set_windows_forms_properties([<file1> [<file2> [...]]])
<fileN>
List of all source files which are relevant for setting the VS_CSHARP_<tagname> properties (including .cs, .resx and .Designer.cs extensions).

In the list of all given files for all files ending with .Designer.cs and .resx is searched. For every designer or resource file a file with the same base name but only .cs as extension is searched. If this is found, the VS_CSHARP_<tagname> properties are set as follows:

for the .cs file:
  • VS_CSHARP_SubType “Form”
for the .Designer.cs file (if it exists):
  • VS_CSHARP_DependentUpon <cs-filename>
  • VS_CSHARP_DesignTime “” (delete tag if previously defined)
  • VS_CSHARP_AutoGen “”(delete tag if previously defined)
for the .resx file (if it exists):
  • VS_RESOURCE_GENERATOR “” (delete tag if previously defined)
  • VS_CSHARP_DependentUpon <cs-filename>
  • VS_CSHARP_SubType “Designer”
csharp_set_designer_cs_properties

Sets source file properties of .Designer.cs files depending on sibling filenames. Use this, if your CSharp target does not use Windows Forms (for Windows Forms use csharp_set_designer_cs_properties() instead):

csharp_set_designer_cs_properties([<file1> [<file2> [...]]])
<fileN>
List of all source files which are relevant for setting the VS_CSHARP_<tagname> properties (including .cs, .resx, .settings and .Designer.cs extensions).

In the list of all given files for all files ending with .Designer.cs is searched. For every designer file all files with the same base name but different extensions are searched. If a match is found, the source file properties of the designer file are set depending on the extension of the matched file:

if match is .resx file:
  • VS_CSHARP_AutoGen “True”
  • VS_CSHARP_DesignTime “True”
  • VS_CSHARP_DependentUpon <resx-filename>
if match is .cs file:
  • VS_CSHARP_DependentUpon <cs-filename>
if match is .settings file:
  • VS_CSHARP_AutoGen “True”
  • VS_CSHARP_DesignTimeSharedInput “True”
  • VS_CSHARP_DependentUpon <settings-filename>

Note

Because the source file properties of the .Designer.cs file are set according to the found matches and every match sets the VS_CSHARP_DependentUpon property, there should only be one match for each Designer.cs file.

csharp_set_xaml_cs_properties

Sets source file properties for use of Windows Presentation Foundation (WPF) and XAML. Use this, if your CSharp target uses WPF/XAML:

csharp_set_xaml_cs_properties([<file1> [<file2> [...]]])
<fileN>
List of all source files which are relevant for setting the VS_CSHARP_<tagname> properties (including .cs, .xaml, and .xaml.cs extensions).

In the list of all given files for all files ending with .xaml.cs is searched. For every xaml-cs file, a file with the same base name but extension .xaml is searched. If a match is found, the source file properties of the .xaml.cs file are set:

  • VS_CSHARP_DependentUpon <xaml-filename>

Helper functions which are used by the above ones

csharp_get_filename_keys

Helper function which computes a list of key values to identify source files independently of relative/absolute paths given in cmake and eliminates case sensitivity:

csharp_get_filename_keys(OUT [<file1> [<file2> [...]]])
OUT
Name of the variable in which the list of keys is stored
<fileN>
filename(s) as given to to CSharp target using add_library() or add_executable()

In some way the function applies a canonicalization to the source names. This is necessary to find file matches if the files have been added to the target with different directory prefixes:

add_library(lib
  myfile.cs
  ${CMAKE_CURRENT_SOURCE_DIR}/myfile.Designer.cs)

set_source_files_properties(myfile.Designer.cs PROPERTIES
  VS_CSHARP_DependentUpon myfile.cs)

# this will fail, because in cmake
#  - ${CMAKE_CURRENT_SOURCE_DIR}/myfile.Designer.cs
#  - myfile.Designer.cs
# are not the same source file. The source file property is not set.
csharp_get_filename_key_base

Returns the full filepath and name without extension of a key. KEY is expected to be a key from csharp_get_filename_keys. In BASE the value of KEY without the file extension is returned:

csharp_get_filename_key_base(BASE KEY)
BASE
Name of the variable with the computed “base” of KEY.
KEY
The key of which the base will be computed. Expected to be a upper case full filename.
csharp_get_dependentupon_name

Computes a string which can be used as value for the source file property VS_CSHARP_<tagname> with target being DependentUpon:

csharp_get_dependentupon_name(NAME FILE)
NAME
Name of the variable with the result value
FILE
Filename to convert to <DependentUpon> value

Actually this is only the filename without any path given at the moment.

  • cmake-modules(7) »


CTest — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CTest

Configure a project for testing with CTest/CDash

Include this module in the top CMakeLists.txt file of a project to enable testing with CTest and dashboard submissions to CDash:

project(MyProject)
...
include(CTest)

The module automatically creates a BUILD_TESTING option that selects whether to enable testing support (ON by default). After including the module, use code like:

if(BUILD_TESTING)
  # ... CMake code to create tests ...
endif()

to creating tests when testing is enabled.

To enable submissions to a CDash server, create a CTestConfig.cmake file at the top of the project with content such as:

set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC")
set(CTEST_SUBMIT_URL "http://my.cdash.org/submit.php?project=MyProject")

(the CDash server can provide the file to a project administrator who configures MyProject). Settings in the config file are shared by both this CTest module and the ctest(1) command-line Dashboard Client mode (ctest -S).

While building a project for submission to CDash, CTest scans the build output for errors and warnings and reports them with surrounding context from the build log. This generic approach works for all build tools, but does not give details about the command invocation that produced a given problem. One may get more detailed reports by setting the CTEST_USE_LAUNCHERS variable:

set(CTEST_USE_LAUNCHERS 1)

in the CTestConfig.cmake file.

  • cmake-modules(7) »


CTestCoverageCollectGCOV — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CTestCoverageCollectGCOV

This module provides the ctest_coverage_collect_gcov function.

This function runs gcov on all .gcda files found in the binary tree and packages the resulting .gcov files into a tar file. This tarball also contains the following:

  • data.json defines the source and build directories for use by CDash.
  • Labels.json indicates any LABELS that have been set on the source files.
  • The uncovered directory holds any uncovered files found by CTEST_EXTRA_COVERAGE_GLOB.

After generating this tar file, it can be sent to CDash for display with the ctest_submit(CDASH_UPLOAD) command.

cdash_coverage_collect_gcov
ctest_coverage_collect_gcov(TARBALL <tarfile>
  [SOURCE <source_dir>][BUILD <build_dir>]
  [GCOV_COMMAND <gcov_command>]
  [GCOV_OPTIONS <options>...]
  )

Run gcov and package a tar file for CDash. The options are:

TARBALL <tarfile>
Specify the location of the .tar file to be created for later upload to CDash. Relative paths will be interpreted with respect to the top-level build directory.
SOURCE <source_dir>
Specify the top-level source directory for the build. Default is the value of CTEST_SOURCE_DIRECTORY.
BUILD <build_dir>
Specify the top-level build directory for the build. Default is the value of CTEST_BINARY_DIRECTORY.
GCOV_COMMAND <gcov_command>
Specify the full path to the gcov command on the machine. Default is the value of CTEST_COVERAGE_COMMAND.
GCOV_OPTIONS <options>...
Specify options to be passed to gcov. The gcov command is run as gcov <options>... -o <gcov-dir> <file>.gcda. If not specified, the default option is just -b.
GLOB
Recursively search for .gcda files in build_dir rather than determining search locations by reading TargetDirectories.txt.
DELETE
Delete coverage files after they’ve been packaged into the .tar.
QUIET
Suppress non-error messages that otherwise would have been printed out by this function.

  • cmake-modules(7) »


CTestScriptMode — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CTestScriptMode

This file is read by ctest in script mode (-S)

  • cmake-modules(7) »


CTestUseLaunchers — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CTestUseLaunchers

Set the RULE_LAUNCH_* global properties when CTEST_USE_LAUNCHERS is on.

CTestUseLaunchers is automatically included when you include(CTest). However, it is split out into its own module file so projects can use the CTEST_USE_LAUNCHERS functionality independently.

To use launchers, set CTEST_USE_LAUNCHERS to ON in a ctest -S dashboard script, and then also set it in the cache of the configured project. Both cmake and ctest need to know the value of it for the launchers to work properly. CMake needs to know in order to generate proper build rules, and ctest, in order to produce the proper error and warning analysis.

For convenience, you may set the ENV variable CTEST_USE_LAUNCHERS_DEFAULT in your ctest -S script, too. Then, as long as your CMakeLists uses include(CTest) or include(CTestUseLaunchers), it will use the value of the ENV variable to initialize a CTEST_USE_LAUNCHERS cache variable. This cache variable initialization only occurs if CTEST_USE_LAUNCHERS is not already defined. If CTEST_USE_LAUNCHERS is on in a ctest -S script the ctest_configure command will add -DCTEST_USE_LAUNCHERS:BOOL=TRUE to the cmake command used to configure the project.

  • cmake-modules(7) »


Dart — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

Dart

Configure a project for testing with CTest or old Dart Tcl Client

This file is the backwards-compatibility version of the CTest module. It supports using the old Dart 1 Tcl client for driving dashboard submissions as well as testing with CTest. This module should be included in the CMakeLists.txt file at the top of a project. Typical usage:

include(Dart)
if(BUILD_TESTING)
  # ... testing related CMake code ...
endif()

The BUILD_TESTING option is created by the Dart module to determine whether testing support should be enabled. The default is ON.

  • cmake-modules(7) »


DeployQt4 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

DeployQt4

Functions to help assemble a standalone Qt4 executable.

A collection of CMake utility functions useful for deploying Qt4 executables.

The following functions are provided by this module:

write_qt4_conf
resolve_qt4_paths
fixup_qt4_executable
install_qt4_plugin_path
install_qt4_plugin
install_qt4_executable

Requires CMake 2.6 or greater because it uses function and PARENT_SCOPE. Also depends on BundleUtilities.cmake.

write_qt4_conf(<qt_conf_dir> <qt_conf_contents>)

Writes a qt.conf file with the <qt_conf_contents> into <qt_conf_dir>.

resolve_qt4_paths(<paths_var> [<executable_path>])

Loop through <paths_var> list and if any don’t exist resolve them relative to the <executable_path> (if supplied) or the CMAKE_INSTALL_PREFIX.

fixup_qt4_executable(<executable>
  [<qtplugins> <libs> <dirs> <plugins_dir> <request_qt_conf>])

Copies Qt plugins, writes a Qt configuration file (if needed) and fixes up a Qt4 executable using BundleUtilities so it is standalone and can be drag-and-drop copied to another machine as long as all of the system libraries are compatible.

<executable> should point to the executable to be fixed-up.

<qtplugins> should contain a list of the names or paths of any Qt plugins to be installed.

<libs> will be passed to BundleUtilities and should be a list of any already installed plugins, libraries or executables to also be fixed-up.

<dirs> will be passed to BundleUtilities and should contain and directories to be searched to find library dependencies.

<plugins_dir> allows an custom plugins directory to be used.

<request_qt_conf> will force a qt.conf file to be written even if not needed.

install_qt4_plugin_path(plugin executable copy installed_plugin_path_var
                        <plugins_dir> <component> <configurations>)

Install (or copy) a resolved <plugin> to the default plugins directory (or <plugins_dir>) relative to <executable> and store the result in <installed_plugin_path_var>.

If <copy> is set to TRUE then the plugins will be copied rather than installed. This is to allow this module to be used at CMake time rather than install time.

If <component> is set then anything installed will use this COMPONENT.

install_qt4_plugin(plugin executable copy installed_plugin_path_var
                   <plugins_dir> <component>)

Install (or copy) an unresolved <plugin> to the default plugins directory (or <plugins_dir>) relative to <executable> and store the result in <installed_plugin_path_var>. See documentation of INSTALL_QT4_PLUGIN_PATH.

install_qt4_executable(<executable>
  [<qtplugins> <libs> <dirs> <plugins_dir> <request_qt_conf> <component>])

Installs Qt plugins, writes a Qt configuration file (if needed) and fixes up a Qt4 executable using BundleUtilities so it is standalone and can be drag-and-drop copied to another machine as long as all of the system libraries are compatible. The executable will be fixed-up at install time. <component> is the COMPONENT used for bundle fixup and plugin installation. See documentation of FIXUP_QT4_BUNDLE.

  • cmake-modules(7) »


Documentation — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

Documentation

This module provides support for the VTK documentation framework. It relies on several tools (Doxygen, Perl, etc).

  • cmake-modules(7) »


ExternalData — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

ExternalData

Contents

  • ExternalData
    • Introduction
    • Module Functions
    • Module Variables
    • Referencing Files
      • Referencing Single Files
      • Referencing File Series
      • Referencing Associated Files
      • Referencing Directories
    • Hash Algorithms
    • Custom Fetch Scripts

Manage data files stored outside source tree

Introduction

Use this module to unambiguously reference data files stored outside the source tree and fetch them at build time from arbitrary local and remote content-addressed locations. Functions provided by this module recognize arguments with the syntax DATA{<name>} as references to external data, replace them with full paths to local copies of those data, and create build rules to fetch and update the local copies.

For example:

include(ExternalData)
set(ExternalData_URL_TEMPLATES "file:///local/%(algo)/%(hash)"
                               "file:////host/share/%(algo)/%(hash)"
                               "http://data.org/%(algo)/%(hash)")
ExternalData_Add_Test(MyData
  NAME MyTest
  COMMAND MyExe DATA{MyInput.png}
  )
ExternalData_Add_Target(MyData)

When test MyTest runs the DATA{MyInput.png} argument will be replaced by the full path to a real instance of the data file MyInput.png on disk. If the source tree contains a content link such as MyInput.png.md5 then the MyData target creates a real MyInput.png in the build tree.

Module Functions

ExternalData_Expand_Arguments

The ExternalData_Expand_Arguments function evaluates DATA{} references in its arguments and constructs a new list of arguments:

ExternalData_Expand_Arguments(
  <target>   # Name of data management target
  <outVar>   # Output variable
  [args...]  # Input arguments, DATA{} allowed
  )

It replaces each DATA{} reference in an argument with the full path of a real data file on disk that will exist after the <target> builds.

ExternalData_Add_Test

The ExternalData_Add_Test function wraps around the CMake add_test() command but supports DATA{} references in its arguments:

ExternalData_Add_Test(
  <target>   # Name of data management target
  ...        # Arguments of add_test(), DATA{} allowed
  )

It passes its arguments through ExternalData_Expand_Arguments and then invokes the add_test() command using the results.

ExternalData_Add_Target

The ExternalData_Add_Target function creates a custom target to manage local instances of data files stored externally:

ExternalData_Add_Target(
  <target>   # Name of data management target
  )

It creates custom commands in the target as necessary to make data files available for each DATA{} reference previously evaluated by other functions provided by this module. Data files may be fetched from one of the URL templates specified in the ExternalData_URL_TEMPLATES variable, or may be found locally in one of the paths specified in the ExternalData_OBJECT_STORES variable.

Typically only one target is needed to manage all external data within a project. Call this function once at the end of configuration after all data references have been processed.

Module Variables

The following variables configure behavior. They should be set before calling any of the functions provided by this module.

ExternalData_BINARY_ROOT

The ExternalData_BINARY_ROOT variable may be set to the directory to hold the real data files named by expanded DATA{} references. The default is CMAKE_BINARY_DIR. The directory layout will mirror that of content links under ExternalData_SOURCE_ROOT.

ExternalData_CUSTOM_SCRIPT_<key>

Specify a full path to a .cmake custom fetch script identified by <key> in entries of the ExternalData_URL_TEMPLATES list. See Custom Fetch Scripts.

ExternalData_LINK_CONTENT

The ExternalData_LINK_CONTENT variable may be set to the name of a supported hash algorithm to enable automatic conversion of real data files referenced by the DATA{} syntax into content links. For each such <file> a content link named <file><ext> is created. The original file is renamed to the form .ExternalData_<algo>_<hash> to stage it for future transmission to one of the locations in the list of URL templates (by means outside the scope of this module). The data fetch rule created for the content link will use the staged object if it cannot be found using any URL template.

ExternalData_NO_SYMLINKS

The real data files named by expanded DATA{} references may be made available under ExternalData_BINARY_ROOT using symbolic links on some platforms. The ExternalData_NO_SYMLINKS variable may be set to disable use of symbolic links and enable use of copies instead.

ExternalData_OBJECT_STORES

The ExternalData_OBJECT_STORES variable may be set to a list of local directories that store objects using the layout <dir>/%(algo)/%(hash). These directories will be searched first for a needed object. If the object is not available in any store then it will be fetched remotely using the URL templates and added to the first local store listed. If no stores are specified the default is a location inside the build tree.

ExternalData_SERIES_PARSE
ExternalData_SERIES_PARSE_PREFIX
ExternalData_SERIES_PARSE_NUMBER
ExternalData_SERIES_PARSE_SUFFIX
ExternalData_SERIES_MATCH

See Referencing File Series.

ExternalData_SOURCE_ROOT

The ExternalData_SOURCE_ROOT variable may be set to the highest source directory containing any path named by a DATA{} reference. The default is CMAKE_SOURCE_DIR. ExternalData_SOURCE_ROOT and CMAKE_SOURCE_DIR must refer to directories within a single source distribution (e.g. they come together in one tarball).

ExternalData_TIMEOUT_ABSOLUTE

The ExternalData_TIMEOUT_ABSOLUTE variable sets the download absolute timeout, in seconds, with a default of 300 seconds. Set to 0 to disable enforcement.

ExternalData_TIMEOUT_INACTIVITY

The ExternalData_TIMEOUT_INACTIVITY variable sets the download inactivity timeout, in seconds, with a default of 60 seconds. Set to 0 to disable enforcement.

ExternalData_URL_ALGO_<algo>_<key>

Specify a custom URL component to be substituted for URL template placeholders of the form %(algo:<key>), where <key> is a valid C identifier, when fetching an object referenced via hash algorithm <algo>. If not defined, the default URL component is just <algo> for any <key>.

ExternalData_URL_TEMPLATES

The ExternalData_URL_TEMPLATES may be set to provide a list of of URL templates using the placeholders %(algo) and %(hash) in each template. Data fetch rules try each URL template in order by substituting the hash algorithm name for %(algo) and the hash value for %(hash). Alternatively one may use %(algo:<key>) with ExternalData_URL_ALGO_<algo>_<key> variables to gain more flexibility in remote URLs.

Referencing Files

Referencing Single Files

The DATA{} syntax is literal and the <name> is a full or relative path within the source tree. The source tree must contain either a real data file at <name> or a “content link” at <name><ext> containing a hash of the real file using a hash algorithm corresponding to <ext>. For example, the argument DATA{img.png} may be satisfied by either a real img.png file in the current source directory or a img.png.md5 file containing its MD5 sum.

Multiple content links of the same name with different hash algorithms are supported (e.g. img.png.sha256 and img.png.sha1) so long as they all correspond to the same real file. This allows objects to be fetched from sources indexed by different hash algorithms.

Referencing File Series

The DATA{} syntax can be told to fetch a file series using the form DATA{<name>,:}, where the : is literal. If the source tree contains a group of files or content links named like a series then a reference to one member adds rules to fetch all of them. Although all members of a series are fetched, only the file originally named by the DATA{} argument is substituted for it. The default configuration recognizes file series names ending with #.ext, _#.ext, .#.ext, or -#.ext where # is a sequence of decimal digits and .ext is any single extension. Configure it with a regex that parses <number> and <suffix> parts from the end of <name>:

ExternalData_SERIES_PARSE = regex of the form (<number>)(<suffix>)$

For more complicated cases set:

ExternalData_SERIES_PARSE = regex with at least two () groups
ExternalData_SERIES_PARSE_PREFIX = <prefix> regex group number, if any
ExternalData_SERIES_PARSE_NUMBER = <number> regex group number
ExternalData_SERIES_PARSE_SUFFIX = <suffix> regex group number

Configure series number matching with a regex that matches the <number> part of series members named <prefix><number><suffix>:

ExternalData_SERIES_MATCH = regex matching <number> in all series members

Note that the <suffix> of a series does not include a hash-algorithm extension.

Referencing Associated Files

The DATA{} syntax can alternatively match files associated with the named file and contained in the same directory. Associated files may be specified by options using the syntax DATA{<name>,<opt1>,<opt2>,...}. Each option may specify one file by name or specify a regular expression to match file names using the syntax REGEX:<regex>. For example, the arguments:

DATA{MyData/MyInput.mhd,MyInput.img}                   # File pair
DATA{MyData/MyFrames00.png,REGEX:MyFrames[0-9]+\\.png} # Series

will pass MyInput.mha and MyFrames00.png on the command line but ensure that the associated files are present next to them.

Referencing Directories

The DATA{} syntax may reference a directory using a trailing slash and a list of associated files. The form DATA{<name>/,<opt1>,<opt2>,...} adds rules to fetch any files in the directory that match one of the associated file options. For example, the argument DATA{MyDataDir/,REGEX:.*} will pass the full path to a MyDataDir directory on the command line and ensure that the directory contains files corresponding to every file or content link in the MyDataDir source directory. In order to match associated files in subdirectories, specify a RECURSE: option, e.g. DATA{MyDataDir/,RECURSE:,REGEX:.*}.

Hash Algorithms

The following hash algorithms are supported:

%(algo)     <ext>     Description
-------     -----     -----------
MD5         .md5      Message-Digest Algorithm 5, RFC 1321
SHA1        .sha1     US Secure Hash Algorithm 1, RFC 3174
SHA224      .sha224   US Secure Hash Algorithms, RFC 4634
SHA256      .sha256   US Secure Hash Algorithms, RFC 4634
SHA384      .sha384   US Secure Hash Algorithms, RFC 4634
SHA512      .sha512   US Secure Hash Algorithms, RFC 4634
SHA3_224    .sha3-224 Keccak SHA-3
SHA3_256    .sha3-256 Keccak SHA-3
SHA3_384    .sha3-384 Keccak SHA-3
SHA3_512    .sha3-512 Keccak SHA-3

Note that the hashes are used only for unique data identification and download verification.

Custom Fetch Scripts

When a data file must be fetched from one of the URL templates specified in the ExternalData_URL_TEMPLATES variable, it is normally downloaded using the file(DOWNLOAD) command. One may specify usage of a custom fetch script by using a URL template of the form ExternalDataCustomScript://<key>/<loc>. The <key> must be a C identifier, and the <loc> must contain the %(algo) and %(hash) placeholders. A variable corresponding to the key, ExternalData_CUSTOM_SCRIPT_<key>, must be set to the full path to a .cmake script file. The script will be included to perform the actual fetch, and provided with the following variables:

ExternalData_CUSTOM_LOCATION

When a custom fetch script is loaded, this variable is set to the location part of the URL, which will contain the substituted hash algorithm name and content hash value.

ExternalData_CUSTOM_FILE

When a custom fetch script is loaded, this variable is set to the full path to a file in which the script must store the fetched content. The name of the file is unspecified and should not be interpreted in any way.

The custom fetch script is expected to store fetched content in the file or set a variable:

ExternalData_CUSTOM_ERROR

When a custom fetch script fails to fetch the requested content, it must set this variable to a short one-line message describing the reason for failure.

  • cmake-modules(7) »


ExternalProject — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

ExternalProject

Contents

  • ExternalProject
    • External Project Definition
    • Obtaining Project Properties
    • Explicit Step Management
    • Examples

External Project Definition

ExternalProject_Add

The ExternalProject_Add() function creates a custom target to drive download, update/patch, configure, build, install and test steps of an external project:

ExternalProject_Add(<name> [<option>...])

The individual steps within the process can be driven independently if required (e.g. for CDash submission) and extra custom steps can be defined, along with the ability to control the step dependencies. The directory structure used for the management of the external project can also be customized. The function supports a large number of options which can be used to tailor the external project behavior.

Directory Options:

Most of the time, the default directory layout is sufficient. It is largely an implementation detail that the main project usually doesn’t need to change. In some circumstances, however, control over the directory layout can be useful or necessary. The directory options are potentially more useful from the point of view that the main build can use the ExternalProject_Get_Property() command to retrieve their values, thereby allowing the main project to refer to build artifacts of the external project.

PREFIX <dir>
Root directory for the external project. Unless otherwise noted below, all other directories associated with the external project will be created under here.
TMP_DIR <dir>
Directory in which to store temporary files.
STAMP_DIR <dir>
Directory in which to store the timestamps of each step. Log files from individual steps are also created in here unless overriden by LOG_DIR (see Logging Options below).
LOG_DIR <dir>
Directory in which to store the logs of each step.
DOWNLOAD_DIR <dir>
Directory in which to store downloaded files before unpacking them. This directory is only used by the URL download method, all other download methods use SOURCE_DIR directly instead.
SOURCE_DIR <dir>

Source directory into which downloaded contents will be unpacked, or for non-URL download methods, the directory in which the repository should be checked out, cloned, etc. If no download method is specified, this must point to an existing directory where the external project has already been unpacked or cloned/checked out.

Note

If a download method is specified, any existing contents of the source directory may be deleted. Only the URL download method checks whether this directory is either missing or empty before initiating the download, stopping with an error if it is not empty. All other download methods silently discard any previous contents of the source directory.

BINARY_DIR <dir>
Specify the build directory location. This option is ignored if BUILD_IN_SOURCE is enabled.
INSTALL_DIR <dir>
Installation prefix to be placed in the <INSTALL_DIR> placeholder. This does not actually configure the external project to install to the given prefix. That must be done by passing appropriate arguments to the external project configuration step, e.g. using <INSTALL_DIR>.

If any of the above ..._DIR options are not specified, their defaults are computed as follows. If the PREFIX option is given or the EP_PREFIX directory property is set, then an external project is built and installed under the specified prefix:

TMP_DIR      = <prefix>/tmp
STAMP_DIR    = <prefix>/src/<name>-stamp
DOWNLOAD_DIR = <prefix>/src
SOURCE_DIR   = <prefix>/src/<name>
BINARY_DIR   = <prefix>/src/<name>-build
INSTALL_DIR  = <prefix>
LOG_DIR      = <STAMP_DIR>

Otherwise, if the EP_BASE directory property is set then components of an external project are stored under the specified base:

TMP_DIR      = <base>/tmp/<name>
STAMP_DIR    = <base>/Stamp/<name>
DOWNLOAD_DIR = <base>/Download/<name>
SOURCE_DIR   = <base>/Source/<name>
BINARY_DIR   = <base>/Build/<name>
INSTALL_DIR  = <base>/Install/<name>
LOG_DIR      = <STAMP_DIR>

If no PREFIX, EP_PREFIX, or EP_BASE is specified, then the default is to set PREFIX to <name>-prefix. Relative paths are interpreted with respect to CMAKE_CURRENT_BINARY_DIR at the point where ExternalProject_Add() is called.

Download Step Options:

A download method can be omitted if the SOURCE_DIR option is used to point to an existing non-empty directory. Otherwise, one of the download methods below must be specified (multiple download methods should not be given) or a custom DOWNLOAD_COMMAND provided.

DOWNLOAD_COMMAND <cmd>...
Overrides the command used for the download step ( generator expressions are supported). If this option is specified, all other download options will be ignored. Providing an empty string for <cmd> effectively disables the download step.
URL Download
URL <url1> [<url2>...]
List of paths and/or URL(s) of the external project’s source. When more than one URL is given, they are tried in turn until one succeeds. A URL may be an ordinary path in the local file system (in which case it must be the only URL provided) or any downloadable URL supported by the file(DOWNLOAD) command. A local filesystem path may refer to either an existing directory or to an archive file, whereas a URL is expected to point to a file which can be treated as an archive. When an archive is used, it will be unpacked automatically unless the DOWNLOAD_NO_EXTRACT option is set to prevent it. The archive type is determined by inspecting the actual content rather than using logic based on the file extension.
URL_HASH <algo>=<hashValue>
Hash of the archive file to be downloaded. The argument should be of the form <algo>=<hashValue> where algo can be any of the hashing algorithms supported by the file() command. Specifying this option is strongly recommended for URL downloads, as it ensures the integrity of the downloaded content. It is also used as a check for a previously downloaded file, allowing connection to the remote location to be avoided altogether if the local directory already has a file from an earlier download that matches the specified hash.
URL_MD5 <md5>
Equivalent to URL_HASH MD5=<md5>.
DOWNLOAD_NAME <fname>
File name to use for the downloaded file. If not given, the end of the URL is used to determine the file name. This option is rarely needed, the default name is generally suitable and is not normally used outside of code internal to the ExternalProject module.
DOWNLOAD_NO_EXTRACT <bool>
Allows the extraction part of the download step to be disabled by passing a boolean true value for this option. If this option is not given, the downloaded contents will be unpacked automatically if required. If extraction has been disabled, the full path to the downloaded file is available as <DOWNLOADED_FILE> in subsequent steps or as the property DOWNLOADED_FILE with the ExternalProject_Get_Property() command.
DOWNLOAD_NO_PROGRESS <bool>
Can be used to disable logging the download progress. If this option is not given, download progress messages will be logged.
TIMEOUT <seconds>
Maximum time allowed for file download operations.
HTTP_USERNAME <username>
Username for the download operation if authentication is required.
HTTP_PASSWORD <password>
Password for the download operation if authentication is required.
HTTP_HEADER <header1> [<header2>...]
Provides an arbitrary list of HTTP headers for the download operation. This can be useful for accessing content in systems like AWS, etc.
TLS_VERIFY <bool>
Specifies whether certificate verification should be performed for https URLs. If this option is not provided, the default behavior is determined by the CMAKE_TLS_VERIFY variable (see file(DOWNLOAD)). If that is also not set, certificate verification will not be performed. In situations where URL_HASH cannot be provided, this option can be an alternative verification measure.
TLS_CAINFO <file>
Specify a custom certificate authority file to use if TLS_VERIFY is enabled. If this option is not specified, the value of the CMAKE_TLS_CAINFO variable will be used instead (see file(DOWNLOAD))
NETRC <level>

Specify whether the .netrc file is to be used for operation. If this option is not specified, the value of the CMAKE_NETRC variable will be used instead (see file(DOWNLOAD)) Valid levels are:

IGNORED
The .netrc file is ignored. This is the default.
OPTIONAL
The .netrc file is optional, and information in the URL is preferred. The file will be scanned to find which ever information is not specified in the URL.
REQUIRED
The .netrc file is required, and information in the URL is ignored.
NETRC_FILE <file>
Specify an alternative .netrc file to the one in your home directory if the NETRC level is OPTIONAL or REQUIRED. If this option is not specified, the value of the CMAKE_NETRC_FILE variable will be used instead (see file(DOWNLOAD))
Git

NOTE: A git version of 1.6.5 or later is required if this download method is used.

GIT_REPOSITORY <url>
URL of the git repository. Any URL understood by the git command may be used.
GIT_TAG <tag>

Git branch name, tag or commit hash. Note that branch names and tags should generally be specified as remote names (i.e. origin/myBranch rather than simply myBranch). This ensures that if the remote end has its tag moved or branch rebased or history rewritten, the local clone will still be updated correctly. In general, however, specifying a commit hash should be preferred for a number of reasons:

  • If the local clone already has the commit corresponding to the hash, no git fetch needs to be performed to check for changes each time CMake is re-run. This can result in a significant speed up if many external projects are being used.
  • Using a specific git hash ensures that the main project’s own history is fully traceable to a specific point in the external project’s evolution. If a branch or tag name is used instead, then checking out a specific commit of the main project doesn’t necessarily pin the whole build to a specific point in the life of the external project. The lack of such deterministic behavior makes the main project lose traceability and repeatability.
GIT_REMOTE_NAME <name>
The optional name of the remote. If this option is not specified, it defaults to origin.
GIT_SUBMODULES <module>...
Specific git submodules that should also be updated. If this option is not provided, all git submodules will be updated.
GIT_SHALLOW <bool>
When this option is enabled, the git clone operation will be given the --depth 1 option. This performs a shallow clone, which avoids downloading the whole history and instead retrieves just the commit denoted by the GIT_TAG option.
GIT_PROGRESS <bool>
When enabled, this option instructs the git clone operation to report its progress by passing it the --progress option. Without this option, the clone step for large projects may appear to make the build stall, since nothing will be logged until the clone operation finishes. While this option can be used to provide progress to prevent the appearance of the build having stalled, it may also make the build overly noisy if lots of external projects are used.
GIT_CONFIG <option1> [<option2>...]
Specify a list of config options to pass to git clone. Each option listed will be transformed into its own --config <option> on the git clone command line, with each option required to be in the form key=value.
Subversion
SVN_REPOSITORY <url>
URL of the Subversion repository.
SVN_REVISION -r<rev>
Revision to checkout from the Subversion repository.
SVN_USERNAME <username>
Username for the Subversion checkout and update.
SVN_PASSWORD <password>
Password for the Subversion checkout and update.
SVN_TRUST_CERT <bool>
Specifies whether to trust the Subversion server site certificate. If enabled, the --trust-server-cert option is passed to the svn checkout and update commands.
Mercurial
HG_REPOSITORY <url>
URL of the mercurial repository.
HG_TAG <tag>
Mercurial branch name, tag or commit id.
CVS
CVS_REPOSITORY <cvsroot>
CVSROOT of the CVS repository.
CVS_MODULE <mod>
Module to checkout from the CVS repository.
CVS_TAG <tag>
Tag to checkout from the CVS repository.
Update/Patch Step Options:

Whenever CMake is re-run, by default the external project’s sources will be updated if the download method supports updates (e.g. a git repository would be checked if the GIT_TAG does not refer to a specific commit).

UPDATE_COMMAND <cmd>...
Overrides the download method’s update step with a custom command. The command may use generator expressions.
UPDATE_DISCONNECTED <bool>

When enabled, this option causes the update step to be skipped. It does not, however, prevent the download step. The update step can still be added as a step target (see ExternalProject_Add_StepTargets()) and called manually. This is useful if you want to allow developers to build the project when disconnected from the network (the network may still be needed for the download step though).

When this option is present, it is generally advisable to make the value a cache variable under the developer’s control rather than hard-coding it. If this option is not present, the default value is taken from the EP_UPDATE_DISCONNECTED directory property. If that is also not defined, updates are performed as normal. The EP_UPDATE_DISCONNECTED directory property is intended as a convenience for controlling the UPDATE_DISCONNECTED behavior for an entire section of a project’s directory hierarchy and may be a more convenient method of giving developers control over whether or not to perform updates (assuming the project also provides a cache variable or some other convenient method for setting the directory property).

PATCH_COMMAND <cmd>...
Specifies a custom command to patch the sources after an update. By default, no patch command is defined. Note that it can be quite difficult to define an appropriate patch command that performs robustly, especially for download methods such as git where changing the GIT_TAG will not discard changes from a previous patch, but the patch command will be called again after updating to the new tag.
Configure Step Options:

The configure step is run after the download and update steps. By default, the external project is assumed to be a CMake project, but this can be overridden if required.

CONFIGURE_COMMAND <cmd>...
The default configure command runs CMake with options based on the main project. For non-CMake external projects, the CONFIGURE_COMMAND option must be used to override this behavior ( generator expressions are supported). For projects that require no configure step, specify this option with an empty string as the command to execute.
CMAKE_COMMAND /.../cmake
Specify an alternative cmake executable for the configure step (use an absolute path). This is generally not recommended, since it is usually desirable to use the same CMake version throughout the whole build. This option is ignored if a custom configure command has been specified with CONFIGURE_COMMAND.
CMAKE_GENERATOR <gen>
Override the CMake generator used for the configure step. Without this option, the same generator as the main build will be used. This option is ignored if a custom configure command has been specified with the CONFIGURE_COMMAND option.
CMAKE_GENERATOR_PLATFORM <platform>
Pass a generator-specific platform name to the CMake command (see CMAKE_GENERATOR_PLATFORM). It is an error to provide this option without the CMAKE_GENERATOR option.
CMAKE_GENERATOR_TOOLSET <toolset>
Pass a generator-specific toolset name to the CMake command (see CMAKE_GENERATOR_TOOLSET). It is an error to provide this option without the CMAKE_GENERATOR option.
CMAKE_GENERATOR_INSTANCE <instance>
Pass a generator-specific instance selection to the CMake command (see CMAKE_GENERATOR_INSTANCE). It is an error to provide this option without the CMAKE_GENERATOR option.
CMAKE_ARGS <arg>...
The specified arguments are passed to the cmake command line. They can be any argument the cmake command understands, not just cache values defined by -D... arguments (see also CMake Options). In addition, arguments may use generator expressions.
CMAKE_CACHE_ARGS <arg>...
This is an alternate way of specifying cache variables where command line length issues may become a problem. The arguments are expected to be in the form -Dvar:STRING=value, which are then transformed into CMake set() commands with the FORCE option used. These set() commands are written to a pre-load script which is then applied using the cmake -C command line option. Arguments may use generator expressions.
CMAKE_CACHE_DEFAULT_ARGS <arg>...
This is the same as the CMAKE_CACHE_ARGS option except the set() commands do not include the FORCE keyword. This means the values act as initial defaults only and will not override any variables already set from a previous run. Use this option with care, as it can lead to different behavior depending on whether the build starts from a fresh build directory or re-uses previous build contents.
SOURCE_SUBDIR <dir>
When no CONFIGURE_COMMAND option is specified, the configure step assumes the external project has a CMakeLists.txt file at the top of its source tree (i.e. in SOURCE_DIR). The SOURCE_SUBDIR option can be used to point to an alternative directory within the source tree to use as the top of the CMake source tree instead. This must be a relative path and it will be interpreted as being relative to SOURCE_DIR. When BUILD_IN_SOURCE 1 is specified, the BUILD_COMMAND is used to point to an alternative directory within the source tree.
Build Step Options:

If the configure step assumed the external project uses CMake as its build system, the build step will also. Otherwise, the build step will assume a Makefile-based build and simply run make with no arguments as the default build step. This can be overridden with custom build commands if required.

BUILD_COMMAND <cmd>...
Overrides the default build command ( generator expressions are supported). If this option is not given, the default build command will be chosen to integrate with the main build in the most appropriate way (e.g. using recursive make for Makefile generators or cmake --build if the project uses a CMake build). This option can be specified with an empty string as the command to make the build step do nothing.
BUILD_IN_SOURCE <bool>
When this option is enabled, the build will be done directly within the external project’s source tree. This should generally be avoided, the use of a separate build directory is usually preferred, but it can be useful when the external project assumes an in-source build. The BINARY_DIR option should not be specified if building in-source.
BUILD_ALWAYS <bool>
Enabling this option forces the build step to always be run. This can be the easiest way to robustly ensure that the external project’s own build dependencies are evaluated rather than relying on the default success timestamp-based method. This option is not normally needed unless developers are expected to modify something the external project’s build depends on in a way that is not detectable via the step target dependencies (e.g. SOURCE_DIR is used without a download method and developers might modify the sources in SOURCE_DIR).
BUILD_BYPRODUCTS <file>...
Specifies files that will be generated by the build command but which might or might not have their modification time updated by subsequent builds. These ultimately get passed through as BYPRODUCTS to the build step’s own underlying call to add_custom_command().
Install Step Options:

If the configure step assumed the external project uses CMake as its build system, the install step will also. Otherwise, the install step will assume a Makefile-based build and simply run make install as the default build step. This can be overridden with custom install commands if required.

INSTALL_COMMAND <cmd>...
The external project’s own install step is invoked as part of the main project’s build. It is done after the external project’s build step and may be before or after the external project’s test step (see the TEST_BEFORE_INSTALL option below). The external project’s install rules are not part of the main project’s install rules, so if anything from the external project should be installed as part of the main build, these need to be specified in the main build as additional install() commands. The default install step builds the install target of the external project, but this can be overridden with a custom command using this option ( generator expressions are supported). Passing an empty string as the <cmd> makes the install step do nothing.
Test Step Options:

The test step is only defined if at least one of the following TEST_... options are provided.

TEST_COMMAND <cmd>...
Overrides the default test command ( generator expressions are supported). If this option is not given, the default behavior of the test step is to build the external project’s own test target. This option can be specified with <cmd> as an empty string, which allows the test step to still be defined, but it will do nothing. Do not specify any of the other TEST_... options if providing an empty string as the test command, but prefer to omit all TEST_... options altogether if the test step target is not needed.
TEST_BEFORE_INSTALL <bool>
When this option is enabled, the test step will be executed before the install step. The default behavior is for the test step to run after the install step.
TEST_AFTER_INSTALL <bool>
This option is mainly useful as a way to indicate that the test step is desired but all default behavior is sufficient. Specifying this option with a boolean true value ensures the test step is defined and that it comes after the install step. If both TEST_BEFORE_INSTALL and TEST_AFTER_INSTALL are enabled, the latter is silently ignored.
TEST_EXCLUDE_FROM_MAIN <bool>
If enabled, the main build’s default ALL target will not depend on the test step. This can be a useful way of ensuring the test step is defined but only gets invoked when manually requested.
Output Logging Options:

Each of the following LOG_... options can be used to wrap the relevant step in a script to capture its output to files. The log files will be created in LOG_DIR if supplied or otherwise the STAMP_DIR directory with step-specific file names.

LOG_DOWNLOAD <bool>
When enabled, the output of the download step is logged to files.
LOG_UPDATE <bool>
When enabled, the output of the update step is logged to files.
LOG_PATCH <bool>
When enabled, the output of the patch step is logged to files.
LOG_CONFIGURE <bool>
When enabled, the output of the configure step is logged to files.
LOG_BUILD <bool>
When enabled, the output of the build step is logged to files.
LOG_INSTALL <bool>
When enabled, the output of the install step is logged to files.
LOG_TEST <bool>
When enabled, the output of the test step is logged to files.
LOG_MERGED_STDOUTERR <bool>
When enabled, stdout and stderr will be merged for any step whose output is being logged to files.
LOG_OUTPUT_ON_FAILURE <bool>
This option only has an effect if at least one of the other LOG_<step> options is enabled. If an error occurs for a step which has logging to file enabled, that step’s output will be printed to the console if LOG_OUTPUT_ON_FAILURE is set to true. For cases where a large amount of output is recorded, just the end of that output may be printed to the console.
Terminal Access Options:

Steps can be given direct access to the terminal in some cases. Giving a step access to the terminal may allow it to receive terminal input if required, such as for authentication details not provided by other options. With the Ninja generator, these options place the steps in the console job pool. Each step can be given access to the terminal individually via the following options:

USES_TERMINAL_DOWNLOAD <bool>
Give the download step access to the terminal.
USES_TERMINAL_UPDATE <bool>
Give the update step access to the terminal.
USES_TERMINAL_CONFIGURE <bool>
Give the configure step access to the terminal.
USES_TERMINAL_BUILD <bool>
Give the build step access to the terminal.
USES_TERMINAL_INSTALL <bool>
Give the install step access to the terminal.
USES_TERMINAL_TEST <bool>
Give the test step access to the terminal.
Target Options:
DEPENDS <targets>...
Specify other targets on which the external project depends. The other targets will be brought up to date before any of the external project’s steps are executed. Because the external project uses additional custom targets internally for each step, the DEPENDS option is the most convenient way to ensure all of those steps depend on the other targets. Simply doing add_dependencies(<name> <targets>) will not make any of the steps dependent on <targets>.
EXCLUDE_FROM_ALL <bool>
When enabled, this option excludes the external project from the default ALL target of the main build.
STEP_TARGETS <step-target>...
Generate custom targets for the specified steps. This is required if the steps need to be triggered manually or if they need to be used as dependencies of other targets. If this option is not specified, the default value is taken from the EP_STEP_TARGETS directory property. See ExternalProject_Add_Step() below for further discussion of the effects of this option.
INDEPENDENT_STEP_TARGETS <step-target>...
Generate custom targets for the specified steps and prevent these targets from having the usual dependencies applied to them. If this option is not specified, the default value is taken from the EP_INDEPENDENT_STEP_TARGETS directory property. This option is mostly useful for allowing individual steps to be driven independently, such as for a CDash setup where each step should be initiated and reported individually rather than as one whole build. See ExternalProject_Add_Step() below for further discussion of the effects of this option.
Miscellaneous Options:
LIST_SEPARATOR <sep>
For any of the various ..._COMMAND options, replace ; with <sep> in the specified command lines. This can be useful where list variables may be given in commands where they should end up as space-separated arguments (<sep> would be a single space character string in this case).
COMMAND <cmd>...

Any of the other ..._COMMAND options can have additional commands appended to them by following them with as many COMMAND ... options as needed ( generator expressions are supported). For example:

ExternalProject_Add(example
  ... # Download options, etc.
  BUILD_COMMAND ${CMAKE_COMMAND} -E echo "Starting $<CONFIG> build"
  COMMAND       ${CMAKE_COMMAND} --build <BINARY_DIR> --config $<CONFIG>
  COMMAND       ${CMAKE_COMMAND} -E echo "$<CONFIG> build complete"
)

It should also be noted that each build step is created via a call to ExternalProject_Add_Step(). See that command’s documentation for the automatic substitutions that are supported for some options.

Obtaining Project Properties

ExternalProject_Get_Property

The ExternalProject_Get_Property() function retrieves external project target properties:

ExternalProject_Get_Property(<name> <prop1> [<prop2>...])

The function stores property values in variables of the same name. Property names correspond to the keyword argument names of ExternalProject_Add(). For example, the source directory might be retrieved like so:

ExternalProject_Get_property(myExtProj SOURCE_DIR)
message("Source dir of myExtProj = ${SOURCE_DIR}")

Explicit Step Management

The ExternalProject_Add() function on its own is often sufficient for incorporating an external project into the main build. Certain scenarios require additional work to implement desired behavior, such as adding in a custom step or making steps available as manually triggerable targets. The ExternalProject_Add_Step(), ExternalProject_Add_StepTargets() and ExternalProject_Add_StepDependencies functions provide the lower level control needed to implement such step-level capabilities.

ExternalProject_Add_Step

The ExternalProject_Add_Step() function specifies an additional custom step for an external project defined by an earlier call to ExternalProject_Add():

ExternalProject_Add_Step(<name> <step> [<option>...])

<name> is the same as the name passed to the original call to ExternalProject_Add(). The specified <step> must not be one of the pre-defined steps (mkdir, download, update, skip-update, patch, configure, build, install or test). The supported options are:

COMMAND <cmd>...
The command line to be executed by this custom step ( generator expressions are supported). This option can be repeated multiple times to specify multiple commands to be executed in order.
COMMENT "<text>..."
Text to be printed when the custom step executes.
DEPENDEES <step>...
Other steps (custom or pre-defined) on which this step depends.
DEPENDERS <step>...
Other steps (custom or pre-defined) that depend on this new custom step.
DEPENDS <file>...
Files on which this custom step depends.
BYPRODUCTS <file>...
Files that will be generated by this custom step but which might or might not have their modification time updated by subsequent builds. This list of files will ultimately be passed through as the BYPRODUCTS option to the add_custom_command() used to implement the custom step internally.
ALWAYS <bool>
When enabled, this option specifies that the custom step should always be run (i.e. that it is always considered out of date).
EXCLUDE_FROM_MAIN <bool>
When enabled, this option specifies that the external project’s main target does not depend on the custom step.
WORKING_DIRECTORY <dir>
Specifies the working directory to set before running the custom step’s command. If this option is not specified, the directory will be the value of the CMAKE_CURRENT_BINARY_DIR at the point where ExternalProject_Add_Step() was called.
LOG <bool>
If set, this causes the output from the custom step to be captured to files in the external project’s LOG_DIR if supplied or STAMP_DIR.
USES_TERMINAL <bool>
If enabled, this gives the custom step direct access to the terminal if possible.

The command line, comment, working directory and byproducts of every standard and custom step are processed to replace the tokens <SOURCE_DIR>, <SOURCE_SUBDIR>, <BINARY_DIR>, <INSTALL_DIR> <TMP_DIR>, <DOWNLOAD_DIR> and <DOWNLOADED_FILE> with their corresponding property values defined in the original call to ExternalProject_Add().

ExternalProject_Add_StepTargets

The ExternalProject_Add_StepTargets() function generates targets for the steps listed. The name of each created target will be of the form <name>-<step>:

ExternalProject_Add_StepTargets(<name> [NO_DEPENDS] <step1> [<step2>...])

Creating a target for a step allows it to be used as a dependency of another target or to be triggered manually. Having targets for specific steps also allows them to be driven independently of each other by specifying targets on build command lines. For example, you may be submitting to a sub-project based dashboard where you want to drive the configure portion of the build, then submit to the dashboard, followed by the build portion, followed by tests. If you invoke a custom target that depends on a step halfway through the step dependency chain, then all the previous steps will also run to ensure everything is up to date.

If the NO_DEPENDS option is specified, the step target will not depend on the dependencies of the external project (i.e. on any dependencies of the <name> custom target created by ExternalProject_Add()). This is usually safe for the download, update and patch steps, since they do not typically require that the dependencies are updated and built. Using NO_DEPENDS for any of the other pre-defined steps, however, may break parallel builds. Only use NO_DEPENDS where it is certain that the named steps genuinely do not have dependencies. For custom steps, consider whether or not the custom commands require the dependencies to be configured, built and installed.

Internally, ExternalProject_Add() calls ExternalProject_Add_Step() to create each step. If any STEP_TARGETS or INDEPENDENT_STEP_TARGETS were specified, then ExternalProject_Add_StepTargets() will also be called after ExternalProject_Add_Step(). INDEPENDENT_STEP_TARGETS have the NO_DEPENDS option set, whereas STEP_TARGETS do not. Other than that, the two options result in ExternalProject_Add_StepTargets() being called in the same way. Even if a step is not mentioned in either of those two options, ExternalProject_Add_StepTargets() can still be called later to manually define a target for the step.

The STEP_TARGETS and INDEPENDENT_STEP_TARGETS options for ExternalProject_Add() are generally the easiest way to ensure targets are created for specific steps of interest. For custom steps, ExternalProject_Add_StepTargets() must be called explicitly if a target should also be created for that custom step. An alternative to these two options is to populate the EP_STEP_TARGETS and EP_INDEPENDENT_STEP_TARGETS directory properties. These act as defaults for the step target options and can save having to repeatedly specify the same set of step targets when multiple external projects are being defined.

ExternalProject_Add_StepDependencies

The ExternalProject_Add_StepDependencies() function can be used to add dependencies to a step. The dependencies added must be targets CMake already knows about (these can be ordinary executable or library targets, custom targets or even step targets of another external project):

ExternalProject_Add_StepDependencies(<name> <step> <target1> [<target2>...])

This function takes care to set both target and file level dependencies and will ensure that parallel builds will not break. It should be used instead of add_dependencies() whenever adding a dependency for some of the step targets generated by the ExternalProject module.

Examples

The following example shows how to download and build a hypothetical project called FooBar from github:

include(ExternalProject)
ExternalProject_Add(foobar
  GIT_REPOSITORY    git@github.com:FooCo/FooBar.git
  GIT_TAG           origin/release/1.2.3
)

For the sake of the example, also define a second hypothetical external project called SecretSauce, which is downloaded from a web server. Two URLs are given to take advantage of a faster internal network if available, with a fallback to a slower external server. The project is a typical Makefile project with no configure step, so some of the default commands are overridden. The build is only required to build the sauce target:

find_program(MAKE_EXE NAMES gmake nmake make)
ExternalProject_Add(secretsauce
  URL               http://intranet.somecompany.com/artifacts/sauce-2.7.tgz
                    https://www.somecompany.com/downloads/sauce-2.7.zip
  URL_HASH          MD5=d41d8cd98f00b204e9800998ecf8427e
  CONFIGURE_COMMAND ""
  BUILD_COMMAND     ${MAKE_EXE} sauce
)

Suppose the build step of secretsauce requires that foobar must already be built. This could be enforced like so:

ExternalProject_Add_StepDependencies(secretsauce build foobar)

Another alternative would be to create a custom target for foobar’s build step and make secretsauce depend on that rather than the whole foobar project. This would mean foobar only needs to be built, it doesn’t need to run its install or test steps before secretsauce can be built. The dependency can also be defined along with the secretsauce project:

ExternalProject_Add_StepTargets(foobar build)
ExternalProject_Add(secretsauce
  URL               http://intranet.somecompany.com/artifacts/sauce-2.7.tgz
                    https://www.somecompany.com/downloads/sauce-2.7.zip
  URL_HASH          MD5=d41d8cd98f00b204e9800998ecf8427e
  CONFIGURE_COMMAND ""
  BUILD_COMMAND     ${MAKE_EXE} sauce
  DEPENDS           foobar-build
)

Instead of calling ExternalProject_Add_StepTargets(), the target could be defined along with the foobar project itself:

ExternalProject_Add(foobar
  GIT_REPOSITORY git@github.com:FooCo/FooBar.git
  GIT_TAG        origin/release/1.2.3
  STEP_TARGETS   build
)

If many external projects should have the same set of step targets, setting a directory property may be more convenient. The build step target could be created automatically by setting the EP_STEP_TARGETS directory property before creating the external projects with ExternalProject_Add():

set_property(DIRECTORY PROPERTY EP_STEP_TARGETS build)

Lastly, suppose that secretsauce provides a script called makedoc which can be used to generate its own documentation. Further suppose that the script expects the output directory to be provided as the only parameter and that it should be run from the secretsauce source directory. A custom step and a custom target to trigger the script can be defined like so:

ExternalProject_Add_Step(secretsauce docs
  COMMAND           <SOURCE_DIR>/makedoc <BINARY_DIR>
  WORKING_DIRECTORY <SOURCE_DIR>
  COMMENT           "Building secretsauce docs"
  ALWAYS            TRUE
  EXCLUDE_FROM_MAIN TRUE
)
ExternalProject_Add_StepTargets(secretsauce docs)

The custom step could then be triggered from the main build like so:

cmake --build . --target secretsauce-docs

  • cmake-modules(7) »


FeatureSummary — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FeatureSummary

Functions for generating a summary of enabled/disabled features.

These functions can be used to generate a summary of enabled and disabled packages and/or feature for a build tree such as:

-- The following OPTIONAL packages have been found:
LibXml2 (required version >= 2.4), XML processing lib, <http://xmlsoft.org>
   * Enables HTML-import in MyWordProcessor
   * Enables odt-export in MyWordProcessor
PNG, A PNG image library., <http://www.libpng.org/pub/png/>
   * Enables saving screenshots
-- The following OPTIONAL packages have not been found:
Lua51, The Lua scripting language., <http://www.lua.org>
   * Enables macros in MyWordProcessor
Foo, Foo provides cool stuff.

Global Properties

FeatureSummary_PKG_TYPES

The global property FeatureSummary_PKG_TYPES defines the type of packages used by FeatureSummary.

The order in this list is important, the first package type in the list is the least important, the last is the most important. the of a package can only be changed to higher types.

The default package types are , RUNTIME, OPTIONAL, RECOMMENDED and REQUIRED, and their importance is RUNTIME < OPTIONAL < RECOMMENDED < REQUIRED.

FeatureSummary_REQUIRED_PKG_TYPES

The global property FeatureSummary_REQUIRED_PKG_TYPES defines which package types are required.

If one or more package in this categories has not been found, CMake will abort when calling feature_summary() with the ‘FATAL_ON_MISSING_REQUIRED_PACKAGES’ option enabled.

The default value for this global property is REQUIRED.

FeatureSummary_DEFAULT_PKG_TYPE

The global property FeatureSummary_DEFAULT_PKG_TYPE defines which package type is the default one. When calling feature_summary(), if the user did not set the package type explicitly, the package will be assigned to this category.

This value must be one of the types defined in the FeatureSummary_PKG_TYPES global property unless the package type is set for all the packages.

The default value for this global property is OPTIONAL.

FeatureSummary_<TYPE>_DESCRIPTION

The global property FeatureSummary_<TYPE>_DESCRIPTION can be defined for each type to replace the type name with the specified string whenever the package type is used in an output string.

If not set, the string “<TYPE> packages” is used.

Functions

feature_summary
feature_summary( [FILENAME <file>]
                 [APPEND]
                 [VAR <variable_name>]
                 [INCLUDE_QUIET_PACKAGES]
                 [FATAL_ON_MISSING_REQUIRED_PACKAGES]
                 [DESCRIPTION "<description>" | DEFAULT_DESCRIPTION]
                 [QUIET_ON_EMPTY]
                 WHAT (ALL
                      | PACKAGES_FOUND | PACKAGES_NOT_FOUND
                      | <TYPE>_PACKAGES_FOUND | <TYPE>_PACKAGES_NOT_FOUND
                      | ENABLED_FEATURES | DISABLED_FEATURES)
               )

The feature_summary() macro can be used to print information about enabled or disabled packages or features of a project. By default, only the names of the features/packages will be printed and their required version when one was specified. Use set_package_properties() to add more useful information, like e.g. a download URL for the respective package or their purpose in the project.

The WHAT option is the only mandatory option. Here you specify what information will be printed:

ALL
print everything
ENABLED_FEATURES
the list of all features which are enabled
DISABLED_FEATURES
the list of all features which are disabled
PACKAGES_FOUND
the list of all packages which have been found
PACKAGES_NOT_FOUND
the list of all packages which have not been found

For each package type <TYPE> defined by the FeatureSummary_PKG_TYPES global property, the following information can also be used:

<TYPE>_PACKAGES_FOUND
only those packages which have been found which have the type <TYPE>
<TYPE>_PACKAGES_NOT_FOUND
only those packages which have not been found which have the type <TYPE>

With the exception of the ALL value, these values can be combined in order to customize the output. For example:

feature_summary(WHAT ENABLED_FEATURES DISABLED_FEATURES)

If a FILENAME is given, the information is printed into this file. If APPEND is used, it is appended to this file, otherwise the file is overwritten if it already existed. If the VAR option is used, the information is “printed” into the specified variable. If FILENAME is not used, the information is printed to the terminal. Using the DESCRIPTION option a description or headline can be set which will be printed above the actual content. If only one type of package was requested, no title is printed, unless it is explicitly set using either DESCRIPTION to use a custom string, or DEFAULT_DESCRIPTION to use a default title for the requested type. If INCLUDE_QUIET_PACKAGES is given, packages which have been searched with find_package(... QUIET) will also be listed. By default they are skipped. If FATAL_ON_MISSING_REQUIRED_PACKAGES is given, CMake will abort if a package which is marked as one of the package types listed in the FeatureSummary_REQUIRED_PKG_TYPES global property has not been found. The default value for the FeatureSummary_REQUIRED_PKG_TYPES global property is REQUIRED.

The FeatureSummary_DEFAULT_PKG_TYPE global property can be modified to change the default package type assigned when not explicitly assigned by the user.

If the QUIET_ON_EMPTY option is used, if only one type of package was requested, and no packages belonging to that category were found, then no output (including the DESCRIPTION) is printed or added to the VAR variable.

Example 1, append everything to a file:

include(FeatureSummary)
feature_summary(WHAT ALL
                FILENAME ${CMAKE_BINARY_DIR}/all.log APPEND)

Example 2, print the enabled features into the variable enabledFeaturesText, including QUIET packages:

include(FeatureSummary)
feature_summary(WHAT ENABLED_FEATURES
                INCLUDE_QUIET_PACKAGES
                DESCRIPTION "Enabled Features:"
                VAR enabledFeaturesText)
message(STATUS "${enabledFeaturesText}")

Example 3, change default package types and print only the categories that are not empty:

include(FeatureSummary)
set_property(GLOBAL APPEND PROPERTY FeatureSummary_PKG_TYPES BUILD)
find_package(FOO)
set_package_properties(FOO PROPERTIES TYPE BUILD)
feature_summary(WHAT BUILD_PACKAGES_FOUND
                Description "Build tools found:"
                QUIET_ON_EMPTY)
feature_summary(WHAT BUILD_PACKAGES_NOT_FOUND
                Description "Build tools not found:"
                QUIET_ON_EMPTY)
set_package_properties
set_package_properties(<name> PROPERTIES
                       [ URL <url> ]
                       [ DESCRIPTION <description> ]
                       [ TYPE (RUNTIME|OPTIONAL|RECOMMENDED|REQUIRED) ]
                       [ PURPOSE <purpose> ]
                      )

Use this macro to set up information about the named package, which can then be displayed via FEATURE_SUMMARY(). This can be done either directly in the Find-module or in the project which uses the module after the find_package() call. The features for which information can be set are added automatically by the find_package() command.

URL <url>
This should be the homepage of the package, or something similar. Ideally this is set already directly in the Find-module.
DESCRIPTION <description>
A short description what that package is, at most one sentence. Ideally this is set already directly in the Find-module.
TYPE <type>
What type of dependency has the using project on that package. Default is OPTIONAL. In this case it is a package which can be used by the project when available at buildtime, but it also work without. RECOMMENDED is similar to OPTIONAL, i.e. the project will build if the package is not present, but the functionality of the resulting binaries will be severely limited. If a REQUIRED package is not available at buildtime, the project may not even build. This can be combined with the FATAL_ON_MISSING_REQUIRED_PACKAGES argument for feature_summary(). Last, a RUNTIME package is a package which is actually not used at all during the build, but which is required for actually running the resulting binaries. So if such a package is missing, the project can still be built, but it may not work later on. If set_package_properties() is called multiple times for the same package with different TYPEs, the TYPE is only changed to higher TYPEs (RUNTIME < OPTIONAL < RECOMMENDED < REQUIRED), lower TYPEs are ignored. The TYPE property is project-specific, so it cannot be set by the Find-module, but must be set in the project. Type accepted can be changed by setting the FeatureSummary_PKG_TYPES global property.
PURPOSE <purpose>
This describes which features this package enables in the project, i.e. it tells the user what functionality he gets in the resulting binaries. If set_package_properties() is called multiple times for a package, all PURPOSE properties are appended to a list of purposes of the package in the project. As the TYPE property, also the PURPOSE property is project-specific, so it cannot be set by the Find-module, but must be set in the project.

Example for setting the info for a package:

find_package(LibXml2)
set_package_properties(LibXml2 PROPERTIES
                       DESCRIPTION "A XML processing library."
                       URL "http://xmlsoft.org/")
# or
set_package_properties(LibXml2 PROPERTIES
                       TYPE RECOMMENDED
                       PURPOSE "Enables HTML-import in MyWordProcessor")
# or
set_package_properties(LibXml2 PROPERTIES
                       TYPE OPTIONAL
                       PURPOSE "Enables odt-export in MyWordProcessor")

find_package(DBUS)
set_package_properties(DBUS PROPERTIES
  TYPE RUNTIME
  PURPOSE "Necessary to disable the screensaver during a presentation")
add_feature_info
add_feature_info(<name> <enabled> <description>)

Use this macro to add information about a feature with the given <name>. <enabled> contains whether this feature is enabled or not. It can be a variable or a list of conditions. <description> is a text describing the feature. The information can be displayed using feature_summary() for ENABLED_FEATURES and DISABLED_FEATURES respectively.

Example for setting the info for a feature:

option(WITH_FOO "Help for foo" ON)
add_feature_info(Foo WITH_FOO "The Foo feature provides very cool stuff.")

Legacy Macros

The following macros are provided for compatibility with previous CMake versions:

set_package_info
set_package_info(<name> <description> [ <url> [<purpose>] ])

Use this macro to set up information about the named package, which can then be displayed via feature_summary(). This can be done either directly in the Find-module or in the project which uses the module after the find_package() call. The features for which information can be set are added automatically by the find_package() command.

set_feature_info
set_feature_info(<name> <description> [<url>])

Does the same as:

set_package_info(<name> <description> <url>)
print_enabled_features
print_enabled_features()

Does the same as

feature_summary(WHAT ENABLED_FEATURES DESCRIPTION "Enabled features:")
print_disabled_features
print_disabled_features()

Does the same as

feature_summary(WHAT DISABLED_FEATURES DESCRIPTION "Disabled features:")

  • cmake-modules(7) »


FetchContent — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FetchContent

Contents

  • FetchContent
    • Overview
    • Declaring Content Details
    • Populating The Content
    • Examples

Overview

This module enables populating content at configure time via any method supported by the ExternalProject module. Whereas ExternalProject_Add() downloads at build time, the FetchContent module makes content available immediately, allowing the configure step to use the content in commands like add_subdirectory(), include() or file() operations.

Content population details would normally be defined separately from the command that performs the actual population. This separation ensures that all of the dependency details are defined before anything may try to use those details to populate content. This is particularly important in more complex project hierarchies where dependencies may be shared between multiple projects.

The following shows a typical example of declaring content details:

FetchContent_Declare(
  googletest
  GIT_REPOSITORY https://github.com/google/googletest.git
  GIT_TAG        release-1.8.0
)

For most typical cases, populating the content can then be done with a single command like so:

FetchContent_MakeAvailable(googletest)

The above command not only populates the content, it also adds it to the main build (if possible) so that the main build can use the populated project’s targets, etc. In some cases, the main project may need to have more precise control over the population or may be required to explicitly define the population steps (e.g. if CMake versions earlier than 3.14 need to be supported). The typical pattern of such custom steps looks like this:

FetchContent_GetProperties(googletest)
if(NOT googletest_POPULATED)
  FetchContent_Populate(googletest)
  add_subdirectory(${googletest_SOURCE_DIR} ${googletest_BINARY_DIR})
endif()

Regardless of which population method is used, when using the declare-populate pattern with a hierarchical project arrangement, projects at higher levels in the hierarchy are able to override the population details of content specified anywhere lower in the project hierarchy. The ability to detect whether content has already been populated ensures that even if multiple child projects want certain content to be available, the first one to populate it wins. The other child project can simply make use of the already available content instead of repeating the population for itself. See the Examples section which demonstrates this scenario.

The FetchContent module also supports defining and populating content in a single call, with no check for whether the content has been populated elsewhere in the project already. This is a more low level operation and would not normally be the way the module is used, but it is sometimes useful as part of implementing some higher level feature or to populate some content in CMake’s script mode.

Declaring Content Details

FetchContent_Declare
FetchContent_Declare(<name> <contentOptions>...)

The FetchContent_Declare() function records the options that describe how to populate the specified content, but if such details have already been recorded earlier in this project (regardless of where in the project hierarchy), this and all later calls for the same content <name> are ignored. This “first to record, wins” approach is what allows hierarchical projects to have parent projects override content details of child projects.

The content <name> can be any string without spaces, but good practice would be to use only letters, numbers and underscores. The name will be treated case-insensitively and it should be obvious for the content it represents, often being the name of the child project or the value given to its top level project() command (if it is a CMake project). For well-known public projects, the name should generally be the official name of the project. Choosing an unusual name makes it unlikely that other projects needing that same content will use the same name, leading to the content being populated multiple times.

The <contentOptions> can be any of the download or update/patch options that the ExternalProject_Add() command understands. The configure, build, install and test steps are explicitly disabled and therefore options related to them will be ignored. In most cases, <contentOptions> will just be a couple of options defining the download method and method-specific details like a commit tag or archive hash. For example:

FetchContent_Declare(
  googletest
  GIT_REPOSITORY https://github.com/google/googletest.git
  GIT_TAG        release-1.8.0
)

FetchContent_Declare(
  myCompanyIcons
  URL      https://intranet.mycompany.com/assets/iconset_1.12.tar.gz
  URL_HASH 5588a7b18261c20068beabfb4f530b87
)

FetchContent_Declare(
  myCompanyCertificates
  SVN_REPOSITORY svn+ssh://svn.mycompany.com/srv/svn/trunk/certs
  SVN_REVISION   -r12345
)

Populating The Content

For most common scenarios, population means making content available to the main build according to previously declared details for that dependency. There are two main patterns for populating content, one based on calling FetchContent_GetProperties() and FetchContent_Populate() for more precise control and the other on calling FetchContent_MakeAvailable() for a simpler, more automated approach. The former generally follows this canonical pattern:

# Check if population has already been performed
FetchContent_GetProperties(<name>)
string(TOLOWER "<name>" lcName)
if(NOT ${lcName}_POPULATED)
  # Fetch the content using previously declared details
  FetchContent_Populate(<name>)

  # Set custom variables, policies, etc.
  # ...

  # Bring the populated content into the build
  add_subdirectory(${${lcName}_SOURCE_DIR} ${${lcName}_BINARY_DIR})
endif()

The above is such a common pattern that, where no custom steps are needed between the calls to FetchContent_Populate() and add_subdirectory(), equivalent logic can be obtained by calling FetchContent_MakeAvailable() instead (and should be preferred where it meets the needs of the project).

FetchContent_Populate
FetchContent_Populate( <name> )

In most cases, the only argument given to FetchContent_Populate() is the <name>. When used this way, the command assumes the content details have been recorded by an earlier call to FetchContent_Declare(). The details are stored in a global property, so they are unaffected by things like variable or directory scope. Therefore, it doesn’t matter where in the project the details were previously declared, as long as they have been declared before the call to FetchContent_Populate(). Those saved details are then used to construct a call to ExternalProject_Add() in a private sub-build to perform the content population immediately. The implementation of ExternalProject_Add() ensures that if the content has already been populated in a previous CMake run, that content will be reused rather than repopulating them again. For the common case where population involves downloading content, the cost of the download is only paid once.

An internal global property records when a particular content population request has been processed. If FetchContent_Populate() is called more than once for the same content name within a configure run, the second call will halt with an error. Projects can and should check whether content population has already been processed with the FetchContent_GetProperties() command before calling FetchContent_Populate().

FetchContent_Populate() will set three variables in the scope of the caller; <lcName>_POPULATED, <lcName>_SOURCE_DIR and <lcName>_BINARY_DIR, where <lcName> is the lowercased <name>. <lcName>_POPULATED will always be set to True by the call. <lcName>_SOURCE_DIR is the location where the content can be found upon return (it will have already been populated), while <lcName>_BINARY_DIR is a directory intended for use as a corresponding build directory. The main use case for the two directory variables is to call add_subdirectory() immediately after population, i.e.:

FetchContent_Populate(FooBar ...)
add_subdirectory(${foobar_SOURCE_DIR} ${foobar_BINARY_DIR})

The values of the three variables can also be retrieved from anywhere in the project hierarchy using the FetchContent_GetProperties() command.

A number of cache variables influence the behavior of all content population performed using details saved from a FetchContent_Declare() call:

FETCHCONTENT_BASE_DIR
In most cases, the saved details do not specify any options relating to the directories to use for the internal sub-build, final source and build areas. It is generally best to leave these decisions up to the FetchContent module to handle on the project’s behalf. The FETCHCONTENT_BASE_DIR cache variable controls the point under which all content population directories are collected, but in most cases developers would not need to change this. The default location is ${CMAKE_BINARY_DIR}/_deps, but if developers change this value, they should aim to keep the path short and just below the top level of the build tree to avoid running into path length problems on Windows.
FETCHCONTENT_QUIET
The logging output during population can be quite verbose, making the configure stage quite noisy. This cache option (ON by default) hides all population output unless an error is encountered. If experiencing problems with hung downloads, temporarily switching this option off may help diagnose which content population is causing the issue.
FETCHCONTENT_FULLY_DISCONNECTED
When this option is enabled, no attempt is made to download or update any content. It is assumed that all content has already been populated in a previous run or the source directories have been pointed at existing contents the developer has provided manually (using options described further below). When the developer knows that no changes have been made to any content details, turning this option ON can significantly speed up the configure stage. It is OFF by default.
FETCHCONTENT_UPDATES_DISCONNECTED
This is a less severe download/update control compared to FETCHCONTENT_FULLY_DISCONNECTED. Instead of bypassing all download and update logic, the FETCHCONTENT_UPDATES_DISCONNECTED only disables the update stage. Therefore, if content has not been downloaded previously, it will still be downloaded when this option is enabled. This can speed up the configure stage, but not as much as FETCHCONTENT_FULLY_DISCONNECTED. It is OFF by default.

In addition to the above cache variables, the following cache variables are also defined for each content name (<ucName> is the uppercased value of <name>):

FETCHCONTENT_SOURCE_DIR_<ucName>
If this is set, no download or update steps are performed for the specified content and the <lcName>_SOURCE_DIR variable returned to the caller is pointed at this location. This gives developers a way to have a separate checkout of the content that they can modify freely without interference from the build. The build simply uses that existing source, but it still defines <lcName>_BINARY_DIR to point inside its own build area. Developers are strongly encouraged to use this mechanism rather than editing the sources populated in the default location, as changes to sources in the default location can be lost when content population details are changed by the project.
FETCHCONTENT_UPDATES_DISCONNECTED_<ucName>
This is the per-content equivalent of FETCHCONTENT_UPDATES_DISCONNECTED. If the global option or this option is ON, then updates will be disabled for the named content. Disabling updates for individual content can be useful for content whose details rarely change, while still leaving other frequently changing content with updates enabled.

The FetchContent_Populate() command also supports a syntax allowing the content details to be specified directly rather than using any saved details. This is more low-level and use of this form is generally to be avoided in favour of using saved content details as outlined above. Nevertheless, in certain situations it can be useful to invoke the content population as an isolated operation (typically as part of implementing some other higher level feature or when using CMake in script mode):

FetchContent_Populate( <name>
  [QUIET]
  [SUBBUILD_DIR <subBuildDir>]
  [SOURCE_DIR <srcDir>]
  [BINARY_DIR <binDir>]
  ...
)

This form has a number of key differences to that where only <name> is provided:

  • All required population details are assumed to have been provided directly in the call to FetchContent_Populate(). Any saved details for <name> are ignored.
  • No check is made for whether content for <name> has already been populated.
  • No global property is set to record that the population has occurred.
  • No global properties record the source or binary directories used for the populated content.
  • The FETCHCONTENT_FULLY_DISCONNECTED and FETCHCONTENT_UPDATES_DISCONNECTED cache variables are ignored.

The <lcName>_SOURCE_DIR and <lcName>_BINARY_DIR variables are still returned to the caller, but since these locations are not stored as global properties when this form is used, they are only available to the calling scope and below rather than the entire project hierarchy. No <lcName>_POPULATED variable is set in the caller’s scope with this form.

The supported options for FetchContent_Populate() are the same as those for FetchContent_Declare(). Those few options shown just above are either specific to FetchContent_Populate() or their behavior is slightly modified from how ExternalProject_Add() treats them.

QUIET
The QUIET option can be given to hide the output associated with populating the specified content. If the population fails, the output will be shown regardless of whether this option was given or not so that the cause of the failure can be diagnosed. The global FETCHCONTENT_QUIET cache variable has no effect on FetchContent_Populate() calls where the content details are provided directly.
SUBBUILD_DIR
The SUBBUILD_DIR argument can be provided to change the location of the sub-build created to perform the population. The default value is ${CMAKE_CURRENT_BINARY_DIR}/<lcName>-subbuild and it would be unusual to need to override this default. If a relative path is specified, it will be interpreted as relative to CMAKE_CURRENT_BINARY_DIR.
SOURCE_DIR, BINARY_DIR
The SOURCE_DIR and BINARY_DIR arguments are supported by ExternalProject_Add(), but different default values are used by FetchContent_Populate(). SOURCE_DIR defaults to ${CMAKE_CURRENT_BINARY_DIR}/<lcName>-src and BINARY_DIR defaults to ${CMAKE_CURRENT_BINARY_DIR}/<lcName>-build. If a relative path is specified, it will be interpreted as relative to CMAKE_CURRENT_BINARY_DIR.

In addition to the above explicit options, any other unrecognized options are passed through unmodified to ExternalProject_Add() to perform the download, patch and update steps. The following options are explicitly prohibited (they are disabled by the FetchContent_Populate() command):

  • CONFIGURE_COMMAND
  • BUILD_COMMAND
  • INSTALL_COMMAND
  • TEST_COMMAND

If using FetchContent_Populate() within CMake’s script mode, be aware that the implementation sets up a sub-build which therefore requires a CMake generator and build tool to be available. If these cannot be found by default, then the CMAKE_GENERATOR and/or CMAKE_MAKE_PROGRAM variables will need to be set appropriately on the command line invoking the script.

FetchContent_GetProperties

When using saved content details, a call to FetchContent_Populate() records information in global properties which can be queried at any time. This information includes the source and binary directories associated with the content and also whether or not the content population has been processed during the current configure run.

FetchContent_GetProperties( <name>
  [SOURCE_DIR <srcDirVar>]
  [BINARY_DIR <binDirVar>]
  [POPULATED <doneVar>]
)

The SOURCE_DIR, BINARY_DIR and POPULATED options can be used to specify which properties should be retrieved. Each option accepts a value which is the name of the variable in which to store that property. Most of the time though, only <name> is given, in which case the call will then set the same variables as a call to FetchContent_Populate(name). This allows the following canonical pattern to be used, which ensures that the relevant variables will always be defined regardless of whether or not the population has been performed elsewhere in the project already:

FetchContent_GetProperties(foobar)
if(NOT foobar_POPULATED)
  FetchContent_Populate(foobar)
  ...
endif()

The above pattern allows other parts of the overall project hierarchy to re-use the same content and ensure that it is only populated once.

FetchContent_MakeAvailable
FetchContent_MakeAvailable( <name1> [<name2>...] )

This command implements the common pattern typically needed for most dependencies. It iterates over each of the named dependencies in turn and for each one it loosely follows the same canonical pattern as presented at the beginning of this section. One small difference to that pattern is that it will only call add_subdirectory() on the populated content if there is a CMakeLists.txt file in its top level source directory. This allows the command to be used for dependencies that make downloaded content available at a known location but which do not need or support being added directly to the build.

Examples

This first fairly straightforward example ensures that some popular testing frameworks are available to the main build:

include(FetchContent)
FetchContent_Declare(
  googletest
  GIT_REPOSITORY https://github.com/google/googletest.git
  GIT_TAG        release-1.8.0
)
FetchContent_Declare(
  Catch2
  GIT_REPOSITORY https://github.com/catchorg/Catch2.git
  GIT_TAG        v2.5.0
)

# After the following call, the CMake targets defined by googletest and
# Catch2 will be defined and available to the rest of the build
FetchContent_MakeAvailable(googletest Catch2)

In more complex project hierarchies, the dependency relationships can be more complicated. Consider a hierarchy where projA is the top level project and it depends directly on projects projB and projC. Both projB and projC can be built standalone and they also both depend on another project projD. projB additionally depends on projE. This example assumes that all five projects are available on a company git server. The CMakeLists.txt of each project might have sections like the following:

projA:

include(FetchContent)
FetchContent_Declare(
  projB
  GIT_REPOSITORY git@mycompany.com:git/projB.git
  GIT_TAG        4a89dc7e24ff212a7b5167bef7ab079d
)
FetchContent_Declare(
  projC
  GIT_REPOSITORY git@mycompany.com:git/projC.git
  GIT_TAG        4ad4016bd1d8d5412d135cf8ceea1bb9
)
FetchContent_Declare(
  projD
  GIT_REPOSITORY git@mycompany.com:git/projD.git
  GIT_TAG        origin/integrationBranch
)
FetchContent_Declare(
  projE
  GIT_REPOSITORY git@mycompany.com:git/projE.git
  GIT_TAG        origin/release/2.3-rc1
)

# Order is important, see notes in the discussion further below
FetchContent_MakeAvailable(projD projB projC)

projB:

include(FetchContent)
FetchContent_Declare(
  projD
  GIT_REPOSITORY git@mycompany.com:git/projD.git
  GIT_TAG        20b415f9034bbd2a2e8216e9a5c9e632
)
FetchContent_Declare(
  projE
  GIT_REPOSITORY git@mycompany.com:git/projE.git
  GIT_TAG        68e20f674a48be38d60e129f600faf7d
)

FetchContent_MakeAvailable(projD projE)

projC:

include(FetchContent)
FetchContent_Declare(
  projD
  GIT_REPOSITORY git@mycompany.com:git/projD.git
  GIT_TAG        7d9a17ad2c962aa13e2fbb8043fb6b8a
)

# This particular version of projD requires workarounds
FetchContent_GetProperties(projD)
if(NOT projd_POPULATED)
  FetchContent_Populate(projD)

  # Copy an additional/replacement file into the populated source
  file(COPY someFile.c DESTINATION ${projd_SOURCE_DIR}/src)

  add_subdirectory(${projd_SOURCE_DIR} ${projd_BINARY_DIR})
endif()

A few key points should be noted in the above:

  • projB and projC define different content details for projD, but projA also defines a set of content details for projD. Because projA will define them first, the details from projB and projC will not be used. The override details defined by projA are not required to match either of those from projB or projC, but it is up to the higher level project to ensure that the details it does define still make sense for the child projects.
  • In the projA call to FetchContent_MakeAvailable(), projD is listed ahead of projB and projC to ensure that projA is in control of how projD is populated.
  • While projA defines content details for projE, it does not need to explicitly call FetchContent_MakeAvailable(projE) or FetchContent_Populate(projD) itself. Instead, it leaves that to the child projB. For higher level projects, it is often enough to just define the override content details and leave the actual population to the child projects. This saves repeating the same thing at each level of the project hierarchy unnecessarily.

Projects don’t always need to add the populated content to the build. Sometimes the project just wants to make the downloaded content available at a predictable location. The next example ensures that a set of standard company toolchain files (and potentially even the toolchain binaries themselves) is available early enough to be used for that same build.

cmake_minimum_required(VERSION 3.14)

include(FetchContent)
FetchContent_Declare(
  mycom_toolchains
  URL  https://intranet.mycompany.com//toolchains_1.3.2.tar.gz
)
FetchContent_MakeAvailable(mycom_toolchains)

project(CrossCompileExample)

The project could be configured to use one of the downloaded toolchains like so:

cmake -DCMAKE_TOOLCHAIN_FILE=_deps/mycom_toolchains-src/toolchain_arm.cmake /path/to/src

When CMake processes the CMakeLists.txt file, it will download and unpack the tarball into _deps/mycompany_toolchains-src relative to the build directory. The CMAKE_TOOLCHAIN_FILE variable is not used until the project() command is reached, at which point CMake looks for the named toolchain file relative to the build directory. Because the tarball has already been downloaded and unpacked by then, the toolchain file will be in place, even the very first time that cmake is run in the build directory.

Lastly, the following example demonstrates how one might download and unpack a firmware tarball using CMake’s script mode. The call to FetchContent_Populate() specifies all the content details and the unpacked firmware will be placed in a firmware directory below the current working directory.

getFirmware.cmake:

# NOTE: Intended to be run in script mode with cmake -P
include(FetchContent)
FetchContent_Populate(
  firmware
  URL        https://mycompany.com/assets/firmware-1.23-arm.tar.gz
  URL_HASH   MD5=68247684da89b608d466253762b0ff11
  SOURCE_DIR firmware
)

  • cmake-modules(7) »


FindPackageHandleStandardArgs — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPackageHandleStandardArgs

This module provides a function intended to be used in Find Modules implementing find_package(<PackageName>) calls. It handles the REQUIRED, QUIET and version-related arguments of find_package. It also sets the <PackageName>_FOUND variable. The package is considered found if all variables listed contain valid results, e.g. valid filepaths.

find_package_handle_standard_args

There are two signatures:

find_package_handle_standard_args(<PackageName>
  (DEFAULT_MSG|<custom-failure-message>)
  <required-var>...
  )

find_package_handle_standard_args(<PackageName>
  [FOUND_VAR <result-var>]
  [REQUIRED_VARS <required-var>...]
  [VERSION_VAR <version-var>]
  [HANDLE_COMPONENTS]
  [CONFIG_MODE]
  [FAIL_MESSAGE <custom-failure-message>]
  )

The <PackageName>_FOUND variable will be set to TRUE if all the variables <required-var>... are valid and any optional constraints are satisfied, and FALSE otherwise. A success or failure message may be displayed based on the results and on whether the REQUIRED and/or QUIET option was given to the find_package() call.

The options are:

(DEFAULT_MSG|<custom-failure-message>)
In the simple signature this specifies the failure message. Use DEFAULT_MSG to ask for a default message to be computed (recommended). Not valid in the full signature.
FOUND_VAR <result-var>
Obsolete. Specifies either <PackageName>_FOUND or <PACKAGENAME>_FOUND as the result variable. This exists only for compatibility with older versions of CMake and is now ignored. Result variables of both names are always set for compatibility.
REQUIRED_VARS <required-var>...
Specify the variables which are required for this package. These may be named in the generated failure message asking the user to set the missing variable values. Therefore these should typically be cache entries such as FOO_LIBRARY and not output variables like FOO_LIBRARIES.
VERSION_VAR <version-var>
Specify the name of a variable that holds the version of the package that has been found. This version will be checked against the (potentially) specified required version given to the find_package() call, including its EXACT option. The default messages include information about the required version and the version which has been actually found, both if the version is ok or not.
HANDLE_COMPONENTS
Enable handling of package components. In this case, the command will report which components have been found and which are missing, and the <PackageName>_FOUND variable will be set to FALSE if any of the required components (i.e. not the ones listed after the OPTIONAL_COMPONENTS option of find_package()) are missing.
CONFIG_MODE
Specify that the calling find module is a wrapper around a call to find_package(<PackageName> NO_MODULE). This implies a VERSION_VAR value of <PackageName>_VERSION. The command will automatically check whether the package configuration file was found.
FAIL_MESSAGE <custom-failure-message>
Specify a custom failure message instead of using the default generated message. Not recommended.

Example for the simple signature:

find_package_handle_standard_args(LibXml2 DEFAULT_MSG
  LIBXML2_LIBRARY LIBXML2_INCLUDE_DIR)

The LibXml2 package is considered to be found if both LIBXML2_LIBRARY and LIBXML2_INCLUDE_DIR are valid. Then also LibXml2_FOUND is set to TRUE. If it is not found and REQUIRED was used, it fails with a message(FATAL_ERROR), independent whether QUIET was used or not. If it is found, success will be reported, including the content of the first <required-var>. On repeated CMake runs, the same message will not be printed again.

Example for the full signature:

find_package_handle_standard_args(LibArchive
  REQUIRED_VARS LibArchive_LIBRARY LibArchive_INCLUDE_DIR
  VERSION_VAR LibArchive_VERSION)

In this case, the LibArchive package is considered to be found if both LibArchive_LIBRARY and LibArchive_INCLUDE_DIR are valid. Also the version of LibArchive will be checked by using the version contained in LibArchive_VERSION. Since no FAIL_MESSAGE is given, the default messages will be printed.

Another example for the full signature:

find_package(Automoc4 QUIET NO_MODULE HINTS /opt/automoc4)
find_package_handle_standard_args(Automoc4  CONFIG_MODE)

In this case, a FindAutmoc4.cmake module wraps a call to find_package(Automoc4 NO_MODULE) and adds an additional search directory for automoc4. Then the call to find_package_handle_standard_args produces a proper success/failure message.

  • cmake-modules(7) »


FindPackageMessage — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPackageMessage

find_package_message(<name> "message for user" "find result details")

This function is intended to be used in FindXXX.cmake modules files. It will print a message once for each unique find result. This is useful for telling the user where a package was found. The first argument specifies the name (XXX) of the package. The second argument specifies the message to display. The third argument lists details about the find result so that if they change the message will be displayed again. The macro also obeys the QUIET argument to the find_package command.

Example:

if(X11_FOUND)
  find_package_message(X11 "Found X11: ${X11_X11_LIB}"
    "[${X11_X11_LIB}][${X11_INCLUDE_DIR}]")
else()
 ...
endif()

  • cmake-modules(7) »


FortranCInterface — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FortranCInterface

Fortran/C Interface Detection

This module automatically detects the API by which C and Fortran languages interact.

Module Variables

Variables that indicate if the mangling is found:

FortranCInterface_GLOBAL_FOUND
Global subroutines and functions.
FortranCInterface_MODULE_FOUND
Module subroutines and functions (declared by “MODULE PROCEDURE”).

This module also provides the following variables to specify the detected mangling, though a typical use case does not need to reference them and can use the Module Functions below.

FortranCInterface_GLOBAL_PREFIX
Prefix for a global symbol without an underscore.
FortranCInterface_GLOBAL_SUFFIX
Suffix for a global symbol without an underscore.
FortranCInterface_GLOBAL_CASE
The case for a global symbol without an underscore, either UPPER or LOWER.
FortranCInterface_GLOBAL__PREFIX
Prefix for a global symbol with an underscore.
FortranCInterface_GLOBAL__SUFFIX
Suffix for a global symbol with an underscore.
FortranCInterface_GLOBAL__CASE
The case for a global symbol with an underscore, either UPPER or LOWER.
FortranCInterface_MODULE_PREFIX
Prefix for a module symbol without an underscore.
FortranCInterface_MODULE_MIDDLE
Middle of a module symbol without an underscore that appears between the name of the module and the name of the symbol.
FortranCInterface_MODULE_SUFFIX
Suffix for a module symbol without an underscore.
FortranCInterface_MODULE_CASE
The case for a module symbol without an underscore, either UPPER or LOWER.
FortranCInterface_MODULE__PREFIX
Prefix for a module symbol with an underscore.
FortranCInterface_MODULE__MIDDLE
Middle of a module symbol with an underscore that appears between the name of the module and the name of the symbol.
FortranCInterface_MODULE__SUFFIX
Suffix for a module symbol with an underscore.
FortranCInterface_MODULE__CASE
The case for a module symbol with an underscore, either UPPER or LOWER.

Module Functions

FortranCInterface_HEADER

The FortranCInterface_HEADER function is provided to generate a C header file containing macros to mangle symbol names:

FortranCInterface_HEADER(<file>
                         [MACRO_NAMESPACE <macro-ns>]
                         [SYMBOL_NAMESPACE <ns>]
                         [SYMBOLS [<module>:]<function> ...])

It generates in <file> definitions of the following macros:

#define FortranCInterface_GLOBAL (name,NAME) ...
#define FortranCInterface_GLOBAL_(name,NAME) ...
#define FortranCInterface_MODULE (mod,name, MOD,NAME) ...
#define FortranCInterface_MODULE_(mod,name, MOD,NAME) ...

These macros mangle four categories of Fortran symbols, respectively:

  • Global symbols without ‘_’: call mysub()
  • Global symbols with ‘_’ : call my_sub()
  • Module symbols without ‘_’: use mymod; call mysub()
  • Module symbols with ‘_’ : use mymod; call my_sub()

If mangling for a category is not known, its macro is left undefined. All macros require raw names in both lower case and upper case.

The options are:

MACRO_NAMESPACE
Replace the default FortranCInterface_ prefix with a given namespace <macro-ns>.
SYMBOLS

List symbols to mangle automatically with C preprocessor definitions:

<function>          ==> #define <ns><function> ...
<module>:<function> ==> #define <ns><module>_<function> ...

If the mangling for some symbol is not known then no preprocessor definition is created, and a warning is displayed.

SYMBOL_NAMESPACE
Prefix all preprocessor definitions generated by the SYMBOLS option with a given namespace <ns>.
FortranCInterface_VERIFY

The FortranCInterface_VERIFY function is provided to verify that the Fortran and C/C++ compilers work together:

FortranCInterface_VERIFY([CXX] [QUIET])

It tests whether a simple test executable using Fortran and C (and C++ when the CXX option is given) compiles and links successfully. The result is stored in the cache entry FortranCInterface_VERIFIED_C (or FortranCInterface_VERIFIED_CXX if CXX is given) as a boolean. If the check fails and QUIET is not given the function terminates with a fatal error message describing the problem. The purpose of this check is to stop a build early for incompatible compiler combinations. The test is built in the Release configuration.

Example Usage

include(FortranCInterface)
FortranCInterface_HEADER(FC.h MACRO_NAMESPACE "FC_")

This creates a “FC.h” header that defines mangling macros FC_GLOBAL(), FC_GLOBAL_(), FC_MODULE(), and FC_MODULE_().

include(FortranCInterface)
FortranCInterface_HEADER(FCMangle.h
                         MACRO_NAMESPACE "FC_"
                         SYMBOL_NAMESPACE "FC_"
                         SYMBOLS mysub mymod:my_sub)

This creates a “FCMangle.h” header that defines the same FC_*() mangling macros as the previous example plus preprocessor symbols FC_mysub and FC_mymod_my_sub.

Additional Manglings

FortranCInterface is aware of possible GLOBAL and MODULE manglings for many Fortran compilers, but it also provides an interface to specify new possible manglings. Set the variables:

FortranCInterface_GLOBAL_SYMBOLS
FortranCInterface_MODULE_SYMBOLS

before including FortranCInterface to specify manglings of the symbols MySub, My_Sub, MyModule:MySub, and My_Module:My_Sub. For example, the code:

set(FortranCInterface_GLOBAL_SYMBOLS mysub_ my_sub__ MYSUB_)
  #                                  ^^^^^  ^^^^^^   ^^^^^
set(FortranCInterface_MODULE_SYMBOLS
    __mymodule_MOD_mysub __my_module_MOD_my_sub)
  #   ^^^^^^^^     ^^^^^   ^^^^^^^^^     ^^^^^^
include(FortranCInterface)

tells FortranCInterface to try given GLOBAL and MODULE manglings. (The carets point at raw symbol names for clarity in this example but are not needed.)

  • cmake-modules(7) »


GenerateExportHeader — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

GenerateExportHeader

Function for generation of export macros for libraries

This module provides the function GENERATE_EXPORT_HEADER().

The GENERATE_EXPORT_HEADER function can be used to generate a file suitable for preprocessor inclusion which contains EXPORT macros to be used in library classes:

GENERATE_EXPORT_HEADER( LIBRARY_TARGET
          [BASE_NAME <base_name>]
          [EXPORT_MACRO_NAME <export_macro_name>]
          [EXPORT_FILE_NAME <export_file_name>]
          [DEPRECATED_MACRO_NAME <deprecated_macro_name>]
          [NO_EXPORT_MACRO_NAME <no_export_macro_name>]
          [INCLUDE_GUARD_NAME <include_guard_name>]
          [STATIC_DEFINE <static_define>]
          [NO_DEPRECATED_MACRO_NAME <no_deprecated_macro_name>]
          [DEFINE_NO_DEPRECATED]
          [PREFIX_NAME <prefix_name>]
          [CUSTOM_CONTENT_FROM_VARIABLE <variable>]
)

The target properties CXX_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN can be used to add the appropriate compile flags for targets. See the documentation of those target properties, and the convenience variables CMAKE_CXX_VISIBILITY_PRESET and CMAKE_VISIBILITY_INLINES_HIDDEN.

By default GENERATE_EXPORT_HEADER() generates macro names in a file name determined by the name of the library. This means that in the simplest case, users of GenerateExportHeader will be equivalent to:

set(CMAKE_CXX_VISIBILITY_PRESET hidden)
set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)
add_library(somelib someclass.cpp)
generate_export_header(somelib)
install(TARGETS somelib DESTINATION ${LIBRARY_INSTALL_DIR})
install(FILES
 someclass.h
 ${PROJECT_BINARY_DIR}/somelib_export.h DESTINATION ${INCLUDE_INSTALL_DIR}
)

And in the ABI header files:

#include "somelib_export.h"
class SOMELIB_EXPORT SomeClass {
  ...
};

The CMake fragment will generate a file in the ${CMAKE_CURRENT_BINARY_DIR} called somelib_export.h containing the macros SOMELIB_EXPORT, SOMELIB_NO_EXPORT, SOMELIB_DEPRECATED, SOMELIB_DEPRECATED_EXPORT and SOMELIB_DEPRECATED_NO_EXPORT. They will be followed by content taken from the variable specified by the CUSTOM_CONTENT_FROM_VARIABLE option, if any. The resulting file should be installed with other headers in the library.

The BASE_NAME argument can be used to override the file name and the names used for the macros:

add_library(somelib someclass.cpp)
generate_export_header(somelib
  BASE_NAME other_name
)

Generates a file called other_name_export.h containing the macros OTHER_NAME_EXPORT, OTHER_NAME_NO_EXPORT and OTHER_NAME_DEPRECATED etc.

The BASE_NAME may be overridden by specifying other options in the function. For example:

add_library(somelib someclass.cpp)
generate_export_header(somelib
  EXPORT_MACRO_NAME OTHER_NAME_EXPORT
)

creates the macro OTHER_NAME_EXPORT instead of SOMELIB_EXPORT, but other macros and the generated file name is as default:

add_library(somelib someclass.cpp)
generate_export_header(somelib
  DEPRECATED_MACRO_NAME KDE_DEPRECATED
)

creates the macro KDE_DEPRECATED instead of SOMELIB_DEPRECATED.

If LIBRARY_TARGET is a static library, macros are defined without values.

If the same sources are used to create both a shared and a static library, the uppercased symbol ${BASE_NAME}_STATIC_DEFINE should be used when building the static library:

add_library(shared_variant SHARED ${lib_SRCS})
add_library(static_variant ${lib_SRCS})
generate_export_header(shared_variant BASE_NAME libshared_and_static)
set_target_properties(static_variant PROPERTIES
  COMPILE_FLAGS -DLIBSHARED_AND_STATIC_STATIC_DEFINE)

This will cause the export macros to expand to nothing when building the static library.

If DEFINE_NO_DEPRECATED is specified, then a macro ${BASE_NAME}_NO_DEPRECATED will be defined This macro can be used to remove deprecated code from preprocessor output:

option(EXCLUDE_DEPRECATED "Exclude deprecated parts of the library" FALSE)
if (EXCLUDE_DEPRECATED)
  set(NO_BUILD_DEPRECATED DEFINE_NO_DEPRECATED)
endif()
generate_export_header(somelib ${NO_BUILD_DEPRECATED})

And then in somelib:

class SOMELIB_EXPORT SomeClass
{
public:
#ifndef SOMELIB_NO_DEPRECATED
  SOMELIB_DEPRECATED void oldMethod();
#endif
};

#ifndef SOMELIB_NO_DEPRECATED
void SomeClass::oldMethod() {  }
#endif

If PREFIX_NAME is specified, the argument will be used as a prefix to all generated macros.

For example:

generate_export_header(somelib PREFIX_NAME VTK_)

Generates the macros VTK_SOMELIB_EXPORT etc.

ADD_COMPILER_EXPORT_FLAGS( [<output_variable>] )

The ADD_COMPILER_EXPORT_FLAGS function adds -fvisibility=hidden to CMAKE_CXX_FLAGS if supported, and is a no-op on Windows which does not need extra compiler flags for exporting support. You may optionally pass a single argument to ADD_COMPILER_EXPORT_FLAGS that will be populated with the CXX_FLAGS required to enable visibility support for the compiler/architecture in use.

This function is deprecated. Set the target properties CXX_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN instead.

  • cmake-modules(7) »


GetPrerequisites — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

GetPrerequisites

Functions to analyze and list executable file prerequisites.

This module provides functions to list the .dll, .dylib or .so files that an executable or shared library file depends on. (Its prerequisites.)

It uses various tools to obtain the list of required shared library files:

dumpbin (Windows)
objdump (MinGW on Windows)
ldd (Linux/Unix)
otool (Mac OSX)

The following functions are provided by this module:

get_prerequisites
list_prerequisites
list_prerequisites_by_glob
gp_append_unique
is_file_executable
gp_item_default_embedded_path
  (projects can override with gp_item_default_embedded_path_override)
gp_resolve_item
  (projects can override with gp_resolve_item_override)
gp_resolved_file_type
  (projects can override with gp_resolved_file_type_override)
gp_file_type

Requires CMake 2.6 or greater because it uses function, break, return and PARENT_SCOPE.

GET_PREREQUISITES(<target> <prerequisites_var> <exclude_system> <recurse>
                  <exepath> <dirs> [<rpaths>])

Get the list of shared library files required by <target>. The list in the variable named <prerequisites_var> should be empty on first entry to this function. On exit, <prerequisites_var> will contain the list of required shared library files.

<target> is the full path to an executable file. <prerequisites_var> is the name of a CMake variable to contain the results. <exclude_system> must be 0 or 1 indicating whether to include or exclude “system” prerequisites. If <recurse> is set to 1 all prerequisites will be found recursively, if set to 0 only direct prerequisites are listed. <exepath> is the path to the top level executable used for @executable_path replacment on the Mac. <dirs> is a list of paths where libraries might be found: these paths are searched first when a target without any path info is given. Then standard system locations are also searched: PATH, Framework locations, /usr/lib…

The variable GET_PREREQUISITES_VERBOSE can be set to true to enable verbose output.

LIST_PREREQUISITES(<target> [<recurse> [<exclude_system> [<verbose>]]])

Print a message listing the prerequisites of <target>.

<target> is the name of a shared library or executable target or the full path to a shared library or executable file. If <recurse> is set to 1 all prerequisites will be found recursively, if set to 0 only direct prerequisites are listed. <exclude_system> must be 0 or 1 indicating whether to include or exclude “system” prerequisites. With <verbose> set to 0 only the full path names of the prerequisites are printed, set to 1 extra informatin will be displayed.

LIST_PREREQUISITES_BY_GLOB(<glob_arg> <glob_exp>)

Print the prerequisites of shared library and executable files matching a globbing pattern. <glob_arg> is GLOB or GLOB_RECURSE and <glob_exp> is a globbing expression used with “file(GLOB” or “file(GLOB_RECURSE” to retrieve a list of matching files. If a matching file is executable, its prerequisites are listed.

Any additional (optional) arguments provided are passed along as the optional arguments to the list_prerequisites calls.

GP_APPEND_UNIQUE(<list_var> <value>)

Append <value> to the list variable <list_var> only if the value is not already in the list.

IS_FILE_EXECUTABLE(<file> <result_var>)

Return 1 in <result_var> if <file> is a binary executable, 0 otherwise.

GP_ITEM_DEFAULT_EMBEDDED_PATH(<item> <default_embedded_path_var>)

Return the path that others should refer to the item by when the item is embedded inside a bundle.

Override on a per-project basis by providing a project-specific gp_item_default_embedded_path_override function.

GP_RESOLVE_ITEM(<context> <item> <exepath> <dirs> <resolved_item_var>
                [<rpaths>])

Resolve an item into an existing full path file.

Override on a per-project basis by providing a project-specific gp_resolve_item_override function.

GP_RESOLVED_FILE_TYPE(<original_file> <file> <exepath> <dirs> <type_var>
                      [<rpaths>])

Return the type of <file> with respect to <original_file>. String describing type of prerequisite is returned in variable named <type_var>.

Use <exepath> and <dirs> if necessary to resolve non-absolute <file> values – but only for non-embedded items.

Possible types are:

system
local
embedded
other

Override on a per-project basis by providing a project-specific gp_resolved_file_type_override function.

GP_FILE_TYPE(<original_file> <file> <type_var>)

Return the type of <file> with respect to <original_file>. String describing type of prerequisite is returned in variable named <type_var>.

Possible types are:

system
local
embedded
other

  • cmake-modules(7) »


GNUInstallDirs — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

GNUInstallDirs

Define GNU standard installation directories

Provides install directory variables as defined by the GNU Coding Standards.

Result Variables

Inclusion of this module defines the following variables:

CMAKE_INSTALL_<dir>

Destination for files of a given type. This value may be passed to the DESTINATION options of install() commands for the corresponding file type.

CMAKE_INSTALL_FULL_<dir>

The absolute path generated from the corresponding CMAKE_INSTALL_<dir> value. If the value is not already an absolute path, an absolute path is constructed typically by prepending the value of the CMAKE_INSTALL_PREFIX variable. However, there are some special cases as documented below.

where <dir> is one of:

BINDIR
user executables (bin)
SBINDIR
system admin executables (sbin)
LIBEXECDIR
program executables (libexec)
SYSCONFDIR
read-only single-machine data (etc)
SHAREDSTATEDIR
modifiable architecture-independent data (com)
LOCALSTATEDIR
modifiable single-machine data (var)
RUNSTATEDIR
run-time variable data (LOCALSTATEDIR/run)
LIBDIR
object code libraries (lib or lib64 or lib/<multiarch-tuple> on Debian)
INCLUDEDIR
C header files (include)
OLDINCLUDEDIR
C header files for non-gcc (/usr/include)
DATAROOTDIR
read-only architecture-independent data root (share)
DATADIR
read-only architecture-independent data (DATAROOTDIR)
INFODIR
info documentation (DATAROOTDIR/info)
LOCALEDIR
locale-dependent data (DATAROOTDIR/locale)
MANDIR
man documentation (DATAROOTDIR/man)
DOCDIR
documentation root (DATAROOTDIR/doc/PROJECT_NAME)

If the includer does not define a value the above-shown default will be used and the value will appear in the cache for editing by the user.

Special Cases

The following values of CMAKE_INSTALL_PREFIX are special:

/

For <dir> other than the SYSCONFDIR, LOCALSTATEDIR and RUNSTATEDIR, the value of CMAKE_INSTALL_<dir> is prefixed with usr/ if it is not user-specified as an absolute path. For example, the INCLUDEDIR value include becomes usr/include. This is required by the GNU Coding Standards, which state:

When building the complete GNU system, the prefix will be empty and /usr will be a symbolic link to /.

/usr

For <dir> equal to SYSCONFDIR, LOCALSTATEDIR or RUNSTATEDIR, the CMAKE_INSTALL_FULL_<dir> is computed by prepending just / to the value of CMAKE_INSTALL_<dir> if it is not user-specified as an absolute path. For example, the SYSCONFDIR value etc becomes /etc. This is required by the GNU Coding Standards.

/opt/...

For <dir> equal to SYSCONFDIR, LOCALSTATEDIR or RUNSTATEDIR, the CMAKE_INSTALL_FULL_<dir> is computed by appending the prefix to the value of CMAKE_INSTALL_<dir> if it is not user-specified as an absolute path. For example, the SYSCONFDIR value etc becomes /etc/opt/.... This is defined by the Filesystem Hierarchy Standard.

Macros

GNUInstallDirs_get_absolute_install_dir
GNUInstallDirs_get_absolute_install_dir(absvar var)

Set the given variable absvar to the absolute path contained within the variable var. This is to allow the computation of an absolute path, accounting for all the special cases documented above. While this macro is used to compute the various CMAKE_INSTALL_FULL_<dir> variables, it is exposed publicly to allow users who create additional path variables to also compute absolute paths where necessary, using the same logic.

  • cmake-modules(7) »


GoogleTest — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

GoogleTest

This module defines functions to help use the Google Test infrastructure. Two mechanisms for adding tests are provided. gtest_add_tests() has been around for some time, originally via find_package(GTest). gtest_discover_tests() was introduced in CMake 3.10.

The (older) gtest_add_tests() scans source files to identify tests. This is usually effective, with some caveats, including in cross-compiling environments, and makes setting additional properties on tests more convenient. However, its handling of parameterized tests is less comprehensive, and it requires re-running CMake to detect changes to the list of tests.

The (newer) gtest_discover_tests() discovers tests by asking the compiled test executable to enumerate its tests. This is more robust and provides better handling of parameterized tests, and does not require CMake to be re-run when tests change. However, it may not work in a cross-compiling environment, and setting test properties is less convenient.

More details can be found in the documentation of the respective functions.

Both commands are intended to replace use of add_test() to register tests, and will create a separate CTest test for each Google Test test case. Note that this is in some cases less efficient, as common set-up and tear-down logic cannot be shared by multiple test cases executing in the same instance. However, it provides more fine-grained pass/fail information to CTest, which is usually considered as more beneficial. By default, the CTest test name is the same as the Google Test name (i.e. suite.testcase); see also TEST_PREFIX and TEST_SUFFIX.

gtest_add_tests

Automatically add tests with CTest by scanning source code for Google Test macros:

gtest_add_tests(TARGET target
                [SOURCES src1...]
                [EXTRA_ARGS arg1...]
                [WORKING_DIRECTORY dir]
                [TEST_PREFIX prefix]
                [TEST_SUFFIX suffix]
                [SKIP_DEPENDENCY]
                [TEST_LIST outVar]
)

gtest_add_tests attempts to identify tests by scanning source files. Although this is generally effective, it uses only a basic regular expression match, which can be defeated by atypical test declarations, and is unable to fully “split” parameterized tests. Additionally, it requires that CMake be re-run to discover any newly added, removed or renamed tests (by default, this means that CMake is re-run when any test source file is changed, but see SKIP_DEPENDENCY). However, it has the advantage of declaring tests at CMake time, which somewhat simplifies setting additional properties on tests, and always works in a cross-compiling environment.

The options are:

TARGET target
Specifies the Google Test executable, which must be a known CMake executable target. CMake will substitute the location of the built executable when running the test.
SOURCES src1...
When provided, only the listed files will be scanned for test cases. If this option is not given, the SOURCES property of the specified target will be used to obtain the list of sources.
EXTRA_ARGS arg1...
Any extra arguments to pass on the command line to each test case.
WORKING_DIRECTORY dir
Specifies the directory in which to run the discovered test cases. If this option is not provided, the current binary directory is used.
TEST_PREFIX prefix
Specifies a prefix to be prepended to the name of each discovered test case. This can be useful when the same source files are being used in multiple calls to gtest_add_test() but with different EXTRA_ARGS.
TEST_SUFFIX suffix
Similar to TEST_PREFIX except the suffix is appended to the name of every discovered test case. Both TEST_PREFIX and TEST_SUFFIX may be specified.
SKIP_DEPENDENCY
Normally, the function creates a dependency which will cause CMake to be re-run if any of the sources being scanned are changed. This is to ensure that the list of discovered tests is updated. If this behavior is not desired (as may be the case while actually writing the test cases), this option can be used to prevent the dependency from being added.
TEST_LIST outVar
The variable named by outVar will be populated in the calling scope with the list of discovered test cases. This allows the caller to do things like manipulate test properties of the discovered tests.
include(GoogleTest)
add_executable(FooTest FooUnitTest.cxx)
gtest_add_tests(TARGET      FooTest
                TEST_SUFFIX .noArgs
                TEST_LIST   noArgsTests
)
gtest_add_tests(TARGET      FooTest
                EXTRA_ARGS  --someArg someValue
                TEST_SUFFIX .withArgs
                TEST_LIST   withArgsTests
)
set_tests_properties(${noArgsTests}   PROPERTIES TIMEOUT 10)
set_tests_properties(${withArgsTests} PROPERTIES TIMEOUT 20)

For backward compatibility, the following form is also supported:

gtest_add_tests(exe args files...)
exe
The path to the test executable or the name of a CMake target.
args
A ;-list of extra arguments to be passed to executable. The entire list must be passed as a single argument. Enclose it in quotes, or pass "" for no arguments.
files...
A list of source files to search for tests and test fixtures. Alternatively, use AUTO to specify that exe is the name of a CMake executable target whose sources should be scanned.
include(GoogleTest)
set(FooTestArgs --foo 1 --bar 2)
add_executable(FooTest FooUnitTest.cxx)
gtest_add_tests(FooTest "${FooTestArgs}" AUTO)
gtest_discover_tests

Automatically add tests with CTest by querying the compiled test executable for available tests:

gtest_discover_tests(target
                     [EXTRA_ARGS arg1...]
                     [WORKING_DIRECTORY dir]
                     [TEST_PREFIX prefix]
                     [TEST_SUFFIX suffix]
                     [NO_PRETTY_TYPES] [NO_PRETTY_VALUES]
                     [PROPERTIES name1 value1...]
                     [TEST_LIST var]
                     [DISCOVERY_TIMEOUT seconds]
)

gtest_discover_tests sets up a post-build command on the test executable that generates the list of tests by parsing the output from running the test with the --gtest_list_tests argument. Compared to the source parsing approach of gtest_add_tests(), this ensures that the full list of tests, including instantiations of parameterized tests, is obtained. Since test discovery occurs at build time, it is not necessary to re-run CMake when the list of tests changes. However, it requires that CROSSCOMPILING_EMULATOR is properly set in order to function in a cross-compiling environment.

Additionally, setting properties on tests is somewhat less convenient, since the tests are not available at CMake time. Additional test properties may be assigned to the set of tests as a whole using the PROPERTIES option. If more fine-grained test control is needed, custom content may be provided through an external CTest script using the TEST_INCLUDE_FILES directory property. The set of discovered tests is made accessible to such a script via the <target>_TESTS variable.

The options are:

target
Specifies the Google Test executable, which must be a known CMake executable target. CMake will substitute the location of the built executable when running the test.
EXTRA_ARGS arg1...
Any extra arguments to pass on the command line to each test case.
WORKING_DIRECTORY dir
Specifies the directory in which to run the discovered test cases. If this option is not provided, the current binary directory is used.
TEST_PREFIX prefix
Specifies a prefix to be prepended to the name of each discovered test case. This can be useful when the same test executable is being used in multiple calls to gtest_discover_tests() but with different EXTRA_ARGS.
TEST_SUFFIX suffix
Similar to TEST_PREFIX except the suffix is appended to the name of every discovered test case. Both TEST_PREFIX and TEST_SUFFIX may be specified.
NO_PRETTY_TYPES
By default, the type index of type-parameterized tests is replaced by the actual type name in the CTest test name. If this behavior is undesirable (e.g. because the type names are unwieldy), this option will suppress this behavior.
NO_PRETTY_VALUES
By default, the value index of value-parameterized tests is replaced by the actual value in the CTest test name. If this behavior is undesirable (e.g. because the value strings are unwieldy), this option will suppress this behavior.
PROPERTIES name1 value1...
Specifies additional properties to be set on all tests discovered by this invocation of gtest_discover_tests.
TEST_LIST var
Make the list of tests available in the variable var, rather than the default <target>_TESTS. This can be useful when the same test executable is being used in multiple calls to gtest_discover_tests(). Note that this variable is only available in CTest.
DISCOVERY_TIMEOUT num

Specifies how long (in seconds) CMake will wait for the test to enumerate available tests. If the test takes longer than this, discovery (and your build) will fail. Most test executables will enumerate their tests very quickly, but under some exceptional circumstances, a test may require a longer timeout. The default is 5. See also the TIMEOUT option of execute_process().

Note

In CMake versions 3.10.1 and 3.10.2, this option was called TIMEOUT. This clashed with the TIMEOUT test property, which is one of the common properties that would be set with the PROPERTIES keyword, usually leading to legal but unintended behavior. The keyword was changed to DISCOVERY_TIMEOUT in CMake 3.10.3 to address this problem. The ambiguous behavior of the TIMEOUT keyword in 3.10.1 and 3.10.2 has not been preserved.

  • cmake-modules(7) »


InstallRequiredSystemLibraries — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

InstallRequiredSystemLibraries

Include this module to search for compiler-provided system runtime libraries and add install rules for them. Some optional variables may be set prior to including the module to adjust behavior:

CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS
Specify additional runtime libraries that may not be detected. After inclusion any detected libraries will be appended to this.
CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP
Set to TRUE to skip calling the install(PROGRAMS) command to allow the includer to specify its own install rule, using the value of CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS to get the list of libraries.
CMAKE_INSTALL_DEBUG_LIBRARIES
Set to TRUE to install the debug runtime libraries when available with MSVC tools.
CMAKE_INSTALL_DEBUG_LIBRARIES_ONLY
Set to TRUE to install only the debug runtime libraries with MSVC tools even if the release runtime libraries are also available.
CMAKE_INSTALL_UCRT_LIBRARIES

Set to TRUE to install the Windows Universal CRT libraries for app-local deployment (e.g. to Windows XP). This is meaningful only with MSVC from Visual Studio 2015 or higher.

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 Redist/ucrt/DLLs/* directories.

CMAKE_INSTALL_MFC_LIBRARIES
Set to TRUE to install the MSVC MFC runtime libraries.
CMAKE_INSTALL_OPENMP_LIBRARIES
Set to TRUE to install the MSVC OpenMP runtime libraries
CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION
Specify the install(PROGRAMS) command DESTINATION option. If not specified, the default is bin on Windows and lib elsewhere.
CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_NO_WARNINGS
Set to TRUE to disable warnings about required library files that do not exist. (For example, Visual Studio Express editions may not provide the redistributable files.)
CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT
Specify the install(PROGRAMS) command COMPONENT option. If not specified, no such option will be used.

  • cmake-modules(7) »


ProcessorCount — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

ProcessorCount

ProcessorCount(var)

Determine the number of processors/cores and save value in ${var}

Sets the variable named ${var} to the number of physical cores available on the machine if the information can be determined. Otherwise it is set to 0. Currently this functionality is implemented for AIX, cygwin, FreeBSD, HPUX, Linux, macOS, QNX, Sun and Windows.

This function is guaranteed to return a positive integer (>=1) if it succeeds. It returns 0 if there’s a problem determining the processor count.

Example use, in a ctest -S dashboard script:

include(ProcessorCount)
ProcessorCount(N)
if(NOT N EQUAL 0)
  set(CTEST_BUILD_FLAGS -j${N})
  set(ctest_test_args ${ctest_test_args} PARALLEL_LEVEL ${N})
endif()

This function is intended to offer an approximation of the value of the number of compute cores available on the current machine, such that you may use that value for parallel building and parallel testing. It is meant to help utilize as much of the machine as seems reasonable. Of course, knowledge of what else might be running on the machine simultaneously should be used when deciding whether to request a machine’s full capacity all for yourself.

  • cmake-modules(7) »


SelectLibraryConfigurations — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

SelectLibraryConfigurations

select_library_configurations(basename)

This macro takes a library base name as an argument, and will choose good values for the variables

basename_LIBRARY
basename_LIBRARIES
basename_LIBRARY_DEBUG
basename_LIBRARY_RELEASE

depending on what has been found and set.

If only basename_LIBRARY_RELEASE is defined, basename_LIBRARY will be set to the release value, and basename_LIBRARY_DEBUG will be set to basename_LIBRARY_DEBUG-NOTFOUND. If only basename_LIBRARY_DEBUG is defined, then basename_LIBRARY will take the debug value, and basename_LIBRARY_RELEASE will be set to basename_LIBRARY_RELEASE-NOTFOUND.

If the generator supports configuration types, then basename_LIBRARY and basename_LIBRARIES will be set with debug and optimized flags specifying the library to be used for the given configuration. If no build type has been set or the generator in use does not support configuration types, then basename_LIBRARY and basename_LIBRARIES will take only the release value, or the debug value if the release one is not set.

  • cmake-modules(7) »


SquishTestScript — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

SquishTestScript

This script launches a GUI test using Squish. You should not call the script directly; instead, you should access it via the SQUISH_ADD_TEST macro that is defined in FindSquish.cmake.

This script starts the Squish server, launches the test on the client, and finally stops the squish server. If any of these steps fail (including if the tests do not pass) then a fatal error is raised.

  • cmake-modules(7) »


TestBigEndian — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

TestBigEndian

Define macro to determine endian type

Check if the system is big endian or little endian

TEST_BIG_ENDIAN(VARIABLE)
VARIABLE - variable to store the result to

  • cmake-modules(7) »


TestForANSIForScope — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

TestForANSIForScope

Check for ANSI for scope support

Check if the compiler restricts the scope of variables declared in a for-init-statement to the loop body.

CMAKE_NO_ANSI_FOR_SCOPE - holds result

  • cmake-modules(7) »


TestForANSIStreamHeaders — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

TestForANSIStreamHeaders

Test for compiler support of ANSI stream headers iostream, etc.

check if the compiler supports the standard ANSI iostream header (without the .h)

CMAKE_NO_ANSI_STREAM_HEADERS - defined by the results

  • cmake-modules(7) »


TestForSSTREAM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

TestForSSTREAM

Test for compiler support of ANSI sstream header

check if the compiler supports the standard ANSI sstream header

CMAKE_NO_ANSI_STRING_STREAM - defined by the results

  • cmake-modules(7) »


TestForSTDNamespace — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

TestForSTDNamespace

Test for std:: namespace support

check if the compiler supports std:: on stl classes

CMAKE_NO_STD_NAMESPACE - defined by the results

  • cmake-modules(7) »


UseEcos — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

UseEcos

This module defines variables and macros required to build eCos application.

This file contains the following macros: ECOS_ADD_INCLUDE_DIRECTORIES() - add the eCos include dirs ECOS_ADD_EXECUTABLE(name source1 … sourceN ) - create an eCos executable ECOS_ADJUST_DIRECTORY(VAR source1 … sourceN ) - adjusts the path of the source files and puts the result into VAR

Macros for selecting the toolchain: ECOS_USE_ARM_ELF_TOOLS() - enable the ARM ELF toolchain for the directory where it is called ECOS_USE_I386_ELF_TOOLS() - enable the i386 ELF toolchain for the directory where it is called ECOS_USE_PPC_EABI_TOOLS() - enable the PowerPC toolchain for the directory where it is called

It contains the following variables: ECOS_DEFINITIONS ECOSCONFIG_EXECUTABLE ECOS_CONFIG_FILE - defaults to ecos.ecc, if your eCos configuration file has a different name, adjust this variable for internal use only:

ECOS_ADD_TARGET_LIB

  • cmake-modules(7) »


UseJavaClassFilelist — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

UseJavaClassFilelist

This script create a list of compiled Java class files to be added to a jar file. This avoids including cmake files which get created in the binary directory.

  • cmake-modules(7) »


UseJava — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

UseJava

Use Module for Java

This file provides functions for Java. It is assumed that FindJava.cmake has already been loaded. See FindJava.cmake for information on how to load Java into your CMake project.

add_jar(target_name
        [SOURCES] source1 [source2 ...] [resource1 ...]
        [INCLUDE_JARS jar1 [jar2 ...]]
        [ENTRY_POINT entry]
        [VERSION version]
        [OUTPUT_NAME name]
        [OUTPUT_DIR dir]
        [GENERATE_NATIVE_HEADERS target [DESTINATION dir]]
        )

This command creates a <target_name>.jar. It compiles the given source files (source) and adds the given resource files (resource) to the jar file. Source files can be java files or listing files (prefixed by ‘@’). If only resource files are given then just a jar file is created. The list of include jars are added to the classpath when compiling the java sources and also to the dependencies of the target. INCLUDE_JARS also accepts other target names created by add_jar. For backwards compatibility, jar files listed as sources are ignored (as they have been since the first version of this module).

The default OUTPUT_DIR can also be changed by setting the variable CMAKE_JAVA_TARGET_OUTPUT_DIR.

Optionally, using option GENERATE_NATIVE_HEADERS, native header files can be generated for methods declared as native. These files provide the connective glue that allow your Java and C code to interact. An INTERFACE target will be created for an easy usage of generated files. Sub-option DESTINATION can be used to specify output directory for generated header files.

GENERATE_NATIVE_HEADERS option requires, at least, version 1.8 of the JDK.

Additional instructions:

To add compile flags to the target you can set these flags with
the following variable:

set(CMAKE_JAVA_COMPILE_FLAGS -nowarn)

To add a path or a jar file to the class path you can do this
with the CMAKE_JAVA_INCLUDE_PATH variable.

set(CMAKE_JAVA_INCLUDE_PATH /usr/share/java/shibboleet.jar)

To use a different output name for the target you can set it with:

add_jar(foobar foobar.java OUTPUT_NAME shibboleet.jar)

To use a different output directory than CMAKE_CURRENT_BINARY_DIR
you can set it with:

add_jar(foobar foobar.java OUTPUT_DIR ${PROJECT_BINARY_DIR}/bin)

To define an entry point in your jar you can set it with the ENTRY_POINT
named argument:

add_jar(example ENTRY_POINT com/examples/MyProject/Main)

To define a custom manifest for the jar, you can set it with the manifest
named argument:

add_jar(example MANIFEST /path/to/manifest)

To add a VERSION to the target output name you can set it using
the VERSION named argument to add_jar. This will create a jar file with the
name shibboleet-1.0.0.jar and will create a symlink shibboleet.jar
pointing to the jar with the version information.

add_jar(shibboleet shibbotleet.java VERSION 1.2.0)

If the target is a JNI library, utilize the following commands to
create a JNI symbolic link:

set(CMAKE_JNI_TARGET TRUE)
add_jar(shibboleet shibbotleet.java VERSION 1.2.0)
install_jar(shibboleet ${LIB_INSTALL_DIR}/shibboleet)
install_jni_symlink(shibboleet ${JAVA_LIB_INSTALL_DIR})

If a single target needs to produce more than one jar from its
java source code, to prevent the accumulation of duplicate class
files in subsequent jars, set/reset CMAKE_JAR_CLASSES_PREFIX prior
to calling the add_jar() function:

set(CMAKE_JAR_CLASSES_PREFIX com/redhat/foo)
add_jar(foo foo.java)

set(CMAKE_JAR_CLASSES_PREFIX com/redhat/bar)
add_jar(bar bar.java)

For an optimum usage of option GENERATE_NATIVE_HEADERS, it is recommended to
include module JNI before any call to add_jar. The produced target for native
headers can then be used to compile C/C++ sources with command
target_link_libraries.

find_package(JNI)
add_jar(foo foo.java GENERATE_NATIVE_HEADERS foo-native)
add_library(bar bar.cpp)
target_link_libraries(bar PRIVATE foo-native)

Target Properties:

The add_jar() function sets some target properties. You can get these
properties with the
   get_property(TARGET <target_name> PROPERTY <propery_name>)
command.

INSTALL_FILES      The files which should be installed. This is used by
                   install_jar().
JNI_SYMLINK        The JNI symlink which should be installed.
                   This is used by install_jni_symlink().
JAR_FILE           The location of the jar file so that you can include
                   it.
CLASSDIR           The directory where the class files can be found. For
                   example to use them with javah.

find_jar(<VAR>
         name | NAMES name1 [name2 ...]
         [PATHS path1 [path2 ... ENV var]]
         [VERSIONS version1 [version2]]
         [DOC "cache documentation string"]
         )

This command is used to find a full path to the named jar. A cache entry named by <VAR> is created to stor the result of this command. If the full path to a jar is found the result is stored in the variable and the search will not repeated unless the variable is cleared. If nothing is found, the result will be <VAR>-NOTFOUND, and the search will be attempted again next time find_jar is invoked with the same variable. The name of the full path to a file that is searched for is specified by the names listed after NAMES argument. Additional search locations can be specified after the PATHS argument. If you require special a version of a jar file you can specify it with the VERSIONS argument. The argument after DOC will be used for the documentation string in the cache.

install_jar(target_name destination)
install_jar(target_name DESTINATION destination [COMPONENT component])

This command installs the TARGET_NAME files to the given DESTINATION. It should be called in the same scope as add_jar() or it will fail.

Target Properties:

The install_jar() function sets the INSTALL_DESTINATION target property
on jars so installed. This property holds the DESTINATION as described
above, and is used by install_jar_exports(). You can get this property
with the
   get_property(TARGET <target_name> PROPERTY INSTALL_DESTINATION)
command.

install_jni_symlink(target_name destination)
install_jni_symlink(target_name DESTINATION destination [COMPONENT component])

This command installs the TARGET_NAME JNI symlinks to the given DESTINATION. It should be called in the same scope as add_jar() or it will fail.

install_jar_exports(TARGETS jars...
                    [NAMESPACE <namespace>]
                    FILE <filename>
                    DESTINATION <dir> [COMPONENT <component>])

This command installs a target export file <filename> for the named jar targets to the given DESTINATION. Its function is similar to that of install(EXPORTS ...).

export_jars(TARGETS jars...
            [NAMESPACE <namespace>]
            FILE <filename>)

This command writes a target export file <filename> for the named jar targets. Its function is similar to that of export(...).

create_javadoc(<VAR>
               PACKAGES pkg1 [pkg2 ...]
               [SOURCEPATH <sourcepath>]
               [CLASSPATH <classpath>]
               [INSTALLPATH <install path>]
               [DOCTITLE "the documentation title"]
               [WINDOWTITLE "the title of the document"]
               [AUTHOR TRUE|FALSE]
               [USE TRUE|FALSE]
               [VERSION TRUE|FALSE]
               )

Create java documentation based on files or packages. For more details please read the javadoc manpage.

There are two main signatures for create_javadoc. The first signature works with package names on a path with source files:

Example:
create_javadoc(my_example_doc
  PACKAGES com.example.foo com.example.bar
  SOURCEPATH "${CMAKE_CURRENT_SOURCE_DIR}"
  CLASSPATH ${CMAKE_JAVA_INCLUDE_PATH}
  WINDOWTITLE "My example"
  DOCTITLE "<h1>My example</h1>"
  AUTHOR TRUE
  USE TRUE
  VERSION TRUE
)

The second signature for create_javadoc works on a given list of files.

create_javadoc(<VAR>
               FILES file1 [file2 ...]
               [CLASSPATH <classpath>]
               [INSTALLPATH <install path>]
               [DOCTITLE "the documentation title"]
               [WINDOWTITLE "the title of the document"]
               [AUTHOR TRUE|FALSE]
               [USE TRUE|FALSE]
               [VERSION TRUE|FALSE]
              )

Example:

create_javadoc(my_example_doc
  FILES ${example_SRCS}
  CLASSPATH ${CMAKE_JAVA_INCLUDE_PATH}
  WINDOWTITLE "My example"
  DOCTITLE "<h1>My example</h1>"
  AUTHOR TRUE
  USE TRUE
  VERSION TRUE
)

Both signatures share most of the options. These options are the same as what you can find in the javadoc manpage. Please look at the manpage for CLASSPATH, DOCTITLE, WINDOWTITLE, AUTHOR, USE and VERSION.

The documentation will be by default installed to

${CMAKE_INSTALL_PREFIX}/share/javadoc/<VAR>

if you don’t set the INSTALLPATH.

create_javah(TARGET <target>
             GENERATED_FILES <VAR>
             CLASSES <class>...
             [CLASSPATH <classpath>...]
             [DEPENDS <depend>...]
             [OUTPUT_NAME <path>|OUTPUT_DIR <path>]
             )

Create C header files from java classes. These files provide the connective glue that allow your Java and C code to interact.

This command will no longer be supported starting with version 10 of the JDK due to the suppression of javah tool. Command add_jar(GENERATE_NATIVE_HEADERS) must be used instead.

There are two main signatures for create_javah. The first signature returns generated files through variable specified by GENERATED_FILES option:

Example:
Create_javah(GENERATED_FILES files_headers
  CLASSES org.cmake.HelloWorld
  CLASSPATH hello.jar
)

The second signature for create_javah creates a target which encapsulates header files generation.

Example:
Create_javah(TARGET target_headers
  CLASSES org.cmake.HelloWorld
  CLASSPATH hello.jar
)

Both signatures share same options.

CLASSES <class>...
Specifies Java classes used to generate headers.
CLASSPATH <classpath>...
Specifies various paths to look up classes. Here .class files, jar files or targets created by command add_jar can be used.
DEPENDS <depend>...
Targets on which the javah target depends
OUTPUT_NAME <path>
Concatenates the resulting header files for all the classes listed by option CLASSES into <path>. Same behavior as option ‘-o’ of javah tool.
OUTPUT_DIR <path>
Sets the directory where the header files will be generated. Same behavior as option ‘-d’ of javah tool. If not specified, ${CMAKE_CURRENT_BINARY_DIR} is used as output directory.

  • cmake-modules(7) »


UseJavaSymlinks — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

UseJavaSymlinks

Helper script for UseJava.cmake

  • cmake-modules(7) »


UseSWIG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

UseSWIG

This file provides support for SWIG. It is assumed that FindSWIG module has already been loaded.

Defines the following command for use with SWIG:

swig_add_library

Define swig module with given name and specified language:

swig_add_library(<name>
                 [TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>]
                 LANGUAGE <language>
                 [NO_PROXY]
                 [OUTPUT_DIR <directory>]
                 [OUTFILE_DIR <directory>]
                 SOURCES <file>...
                )

Targets created with the swig_add_library command have the same capabilities as targets created with the add_library() command, so those targets can be used with any command expecting a target (e.g. target_link_libraries()).

Note

This command creates a target with the specified <name> when policy CMP0078 is set to NEW. Otherwise, the legacy behavior will choose a different target name and store it in the SWIG_MODULE_<name>_REAL_NAME variable.

Note

For multi-config generators, this module does not support configuration-specific files generated by SWIG. All build configurations must result in the same generated source file.

TYPE
SHARED, MODULE and STATIC have the same semantic as for the add_library() command. If USE_BUILD_SHARED_LIBS is specified, the library type will be STATIC or SHARED based on whether the current value of the BUILD_SHARED_LIBS variable is ON. If no type is specified, MODULE will be used.
LANGUAGE
Specify the target language.
NO_PROXY
Prevent the generation of the wrapper layer (swig -noproxy option).
OUTPUT_DIR

Specify where to write the language specific files (swig -outdir option). If not given, the CMAKE_SWIG_OUTDIR variable will be used. If neither is specified, the default depends on the value of the UseSWIG_MODULE_VERSION variable as follows:

  • If UseSWIG_MODULE_VERSION is 1 or is undefined, output is written to the CMAKE_CURRENT_BINARY_DIR directory.
  • If UseSWIG_MODULE_VERSION is 2, a dedicated directory will be used. The path of this directory can be retrieved from the SWIG_SUPPORT_FILES_DIRECTORY target property.
OUTFILE_DIR
Specify an output directory name where the generated source file will be placed (swig -o option). If not specified, the SWIG_OUTFILE_DIR variable will be used. If neither is specified, OUTPUT_DIR or CMAKE_SWIG_OUTDIR is used instead.
SOURCES
List of sources for the library. Files with extension .i will be identified as sources for the SWIG tool. Other files will be handled in the standard way. This behavior can be overriden by specifying the variable SWIG_SOURCE_FILE_EXTENSIONS.

Note

If UseSWIG_MODULE_VERSION is set to 2, it is strongly recommended to use a dedicated directory unique to the target when either the OUTPUT_DIR option or the CMAKE_SWIG_OUTDIR variable are specified. The output directory contents are erased as part of the target build, so to prevent interference between targets or losing other important files, each target should have its own dedicated output directory.

swig_link_libraries

Link libraries to swig module:

swig_link_libraries(<name> <item>...)

This command has same capabilities as target_link_libraries() command.

Note

If variable UseSWIG_TARGET_NAME_PREFERENCE is set to STANDARD, this command is deprecated and target_link_libraries() command must be used instead.

Source file properties on module files must be set before the invocation of the swig_add_library command to specify special behavior of SWIG and ensure generated files will receive the required settings.

CPLUSPLUS

Call SWIG in c++ mode. For example:

set_property(SOURCE mymod.i PROPERTY CPLUSPLUS ON)
swig_add_library(mymod LANGUAGE python SOURCES mymod.i)
INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and COMPILE_OPTIONS
Add custom flags to SWIG compiler and have same semantic as properties INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and COMPILE_OPTIONS.
USE_TARGET_INCLUDE_DIRECTORIES
If set to TRUE, contents of target property INCLUDE_DIRECTORIES will be forwarded to SWIG compiler. If set to FALSE target property INCLUDE_DIRECTORIES will be ignored. If not set, target property SWIG_USE_TARGET_INCLUDE_DIRECTORIES will be considered.
GENERATED_INCLUDE_DIRECTORIES, GENERATED_COMPILE_DEFINITIONS and GENERATED_COMPILE_OPTIONS
Add custom flags to the C/C++ generated source. They will fill, respectively, properties INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and COMPILE_OPTIONS of generated C/C++ file.
DEPENDS
Specify additional dependencies to the source file.
SWIG_MODULE_NAME

Specify the actual import name of the module in the target language. This is required if it cannot be scanned automatically from source or different from the module file basename. For example:

set_property(SOURCE mymod.i PROPERTY SWIG_MODULE_NAME mymod_realname)

Note

If policy CMP0086 is set to NEW, -module <module_name> is passed to SWIG compiler.

Target library properties can be set to apply same configuration to all SWIG input files.

SWIG_INCLUDE_DIRECTORIES, SWIG_COMPILE_DEFINITIONS and SWIG_COMPILE_OPTIONS

These properties will be applied to all SWIG input files and have same semantic as target properties INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and COMPILE_OPTIONS.

set (UseSWIG_TARGET_NAME_PREFERENCE STANDARD)
swig_add_library(mymod LANGUAGE python SOURCES mymod.i)
set_property(TARGET mymod PROPERTY SWIG_COMPILE_DEFINITIONS MY_DEF1 MY_DEF2)
set_property(TARGET mymod PROPERTY SWIG_COMPILE_OPTIONS -bla -blb)
SWIG_USE_TARGET_INCLUDE_DIRECTORIES
If set to TRUE, contents of target property INCLUDE_DIRECTORIES will be forwarded to SWIG compiler. If set to FALSE or not defined, target property INCLUDE_DIRECTORIES will be ignored. This behavior can be overridden by specifying source property USE_TARGET_INCLUDE_DIRECTORIES.
SWIG_GENERATED_INCLUDE_DIRECTORIES, SWIG_GENERATED_COMPILE_DEFINITIONS and SWIG_GENERATED_COMPILE_OPTIONS
These properties will populate, respectively, properties INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and COMPILE_FLAGS of all generated C/C++ files.
SWIG_DEPENDS
Add dependencies to all SWIG input files.

The following target properties are output properties and can be used to get information about support files generated by SWIG interface compilation.

SWIG_SUPPORT_FILES

This output property list of wrapper files generated during SWIG compilation.

set (UseSWIG_TARGET_NAME_PREFERENCE STANDARD)
swig_add_library(mymod LANGUAGE python SOURCES mymod.i)
get_property(support_files TARGET mymod PROPERTY SWIG_SUPPORT_FILES)

Note

Only most principal support files are listed. In case some advanced features of SWIG are used (for example %template), associated support files may not be listed. Prefer to use the SWIG_SUPPORT_FILES_DIRECTORY property to handle support files.

SWIG_SUPPORT_FILES_DIRECTORY
This output property specifies the directory where support files will be generated.

Some variables can be set to customize the behavior of swig_add_library as well as SWIG:

UseSWIG_MODULE_VERSION

Specify different behaviors for UseSWIG module.

  • Set to 1 or undefined: Legacy behavior is applied.
  • Set to 2: A new strategy is applied regarding support files: the output directory of support files is erased before SWIG interface compilation.
CMAKE_SWIG_FLAGS
Add flags to all swig calls.
CMAKE_SWIG_OUTDIR
Specify where to write the language specific files (swig -outdir option).
SWIG_OUTFILE_DIR
Specify an output directory name where the generated source file will be placed. If not specified, CMAKE_SWIG_OUTDIR is used.
SWIG_MODULE_<name>_EXTRA_DEPS
Specify extra dependencies for the generated module for <name>.
SWIG_SOURCE_FILE_EXTENSIONS

Specify a list of source file extensions to override the default behavior of considering only .i files as sources for the SWIG tool. For example:

set(SWIG_SOURCE_FILE_EXTENSIONS ".i" ".swg")

  • cmake-modules(7) »


UsewxWidgets — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

UsewxWidgets

Convenience include for using wxWidgets library.

Determines if wxWidgets was FOUND and sets the appropriate libs, incdirs, flags, etc. INCLUDE_DIRECTORIES and LINK_DIRECTORIES are called.

USAGE

# Note that for MinGW users the order of libs is important!
find_package(wxWidgets REQUIRED net gl core base)
include(${wxWidgets_USE_FILE})
# and for each of your dependent executable/library targets:
target_link_libraries(<YourTarget> ${wxWidgets_LIBRARIES})

DEPRECATED

LINK_LIBRARIES is not called in favor of adding dependencies per target.

AUTHOR

Jan Woetzel <jw -at- mip.informatik.uni-kiel.de>

  • cmake-modules(7) »


WriteCompilerDetectionHeader — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

WriteCompilerDetectionHeader

This module provides the function write_compiler_detection_header().

This function can be used to generate a file suitable for preprocessor inclusion which contains macros to be used in source code:

write_compiler_detection_header(
          FILE <file>
          PREFIX <prefix>
          [OUTPUT_FILES_VAR <output_files_var> OUTPUT_DIR <output_dir>]
          COMPILERS <compiler> [...]
          FEATURES <feature> [...]
          [BARE_FEATURES <feature> [...]]
          [VERSION <version>]
          [PROLOG <prolog>]
          [EPILOG <epilog>]
          [ALLOW_UNKNOWN_COMPILERS]
          [ALLOW_UNKNOWN_COMPILER_VERSIONS]
)

This generates the file <file> with macros which all have the prefix <prefix>.

By default, all content is written directly to the <file>. The OUTPUT_FILES_VAR may be specified to cause the compiler-specific content to be written to separate files. The separate files are then available in the <output_files_var> and may be consumed by the caller for installation for example. The OUTPUT_DIR specifies a relative path from the main <file> to the compiler-specific files. For example:

write_compiler_detection_header(
  FILE climbingstats_compiler_detection.h
  PREFIX ClimbingStats
  OUTPUT_FILES_VAR support_files
  OUTPUT_DIR compilers
  COMPILERS GNU Clang MSVC Intel
  FEATURES cxx_variadic_templates
)
install(FILES
  ${CMAKE_CURRENT_BINARY_DIR}/climbingstats_compiler_detection.h
  DESTINATION include
)
install(FILES
  ${support_files}
  DESTINATION include/compilers
)

VERSION may be used to specify the API version to be generated. Future versions of CMake may introduce alternative APIs. A given API is selected by any <version> value greater than or equal to the version of CMake that introduced the given API and less than the version of CMake that introduced its succeeding API. The value of the CMAKE_MINIMUM_REQUIRED_VERSION variable is used if no explicit version is specified. (As of CMake version 3.14.0-rc4 there is only one API version.)

PROLOG may be specified as text content to write at the start of the header. EPILOG may be specified as text content to write at the end of the header

At least one <compiler> and one <feature> must be listed. Compilers which are known to CMake, but not specified are detected and a preprocessor #error is generated for them. A preprocessor macro matching <PREFIX>_COMPILER_IS_<compiler> is generated for each compiler known to CMake to contain the value 0 or 1.

Possible compiler identifiers are documented with the CMAKE_<LANG>_COMPILER_ID variable. Available features in this version of CMake are listed in the CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES global properties. The {c,cxx}_std_* meta-features are ignored if requested.

See the cmake-compile-features(7) manual for information on compile features.

BARE_FEATURES will define the compatibility macros with the name used in newer versions of the language standard, so the code can use the new feature name unconditionally.

ALLOW_UNKNOWN_COMPILERS and ALLOW_UNKNOWN_COMPILER_VERSIONS cause the module to generate conditions that treat unknown compilers as simply lacking all features. Without these options the default behavior is to generate a #error for unknown compilers and versions.

Feature Test Macros

For each compiler, a preprocessor macro is generated matching <PREFIX>_COMPILER_IS_<compiler> which has the content either 0 or 1, depending on the compiler in use. Preprocessor macros for compiler version components are generated matching <PREFIX>_COMPILER_VERSION_MAJOR <PREFIX>_COMPILER_VERSION_MINOR and <PREFIX>_COMPILER_VERSION_PATCH containing decimal values for the corresponding compiler version components, if defined.

A preprocessor test is generated based on the compiler version denoting whether each feature is enabled. A preprocessor macro matching <PREFIX>_COMPILER_<FEATURE>, where <FEATURE> is the upper-case <feature> name, is generated to contain the value 0 or 1 depending on whether the compiler in use supports the feature:

write_compiler_detection_header(
  FILE climbingstats_compiler_detection.h
  PREFIX ClimbingStats
  COMPILERS GNU Clang AppleClang MSVC Intel
  FEATURES cxx_variadic_templates
)

#if ClimbingStats_COMPILER_CXX_VARIADIC_TEMPLATES
template<typename... T>
void someInterface(T t...) { /* ... */ }
#else
// Compatibility versions
template<typename T1>
void someInterface(T1 t1) { /* ... */ }
template<typename T1, typename T2>
void someInterface(T1 t1, T2 t2) { /* ... */ }
template<typename T1, typename T2, typename T3>
void someInterface(T1 t1, T2 t2, T3 t3) { /* ... */ }
#endif

Symbol Macros

Some additional symbol-defines are created for particular features for use as symbols which may be conditionally defined empty:

class MyClass ClimbingStats_FINAL
{
    ClimbingStats_CONSTEXPR int someInterface() { return 42; }
};

The ClimbingStats_FINAL macro will expand to final if the compiler (and its flags) support the cxx_final feature, and the ClimbingStats_CONSTEXPR macro will expand to constexpr if cxx_constexpr is supported.

If BARE_FEATURES cxx_final was given as argument the final keyword will be defined for old compilers, too.

The following features generate corresponding symbol defines and if they are available as BARE_FEATURES:

Feature | Define | Symbol | bare
c_restrict | <PREFIX>_RESTRICT | restrict | yes
cxx_constexpr | <PREFIX>_CONSTEXPR | constexpr | yes
cxx_deleted_functions | <PREFIX>_DELETED_FUNCTION | = delete |
cxx_extern_templates | <PREFIX>_EXTERN_TEMPLATE | extern |
cxx_final | <PREFIX>_FINAL | final | yes
cxx_noexcept | <PREFIX>_NOEXCEPT | noexcept | yes
cxx_noexcept | <PREFIX>_NOEXCEPT_EXPR(X) | noexcept(X) |
cxx_override | <PREFIX>_OVERRIDE | override | yes

Compatibility Implementation Macros

Some features are suitable for wrapping in a macro with a backward compatibility implementation if the compiler does not support the feature.

When the cxx_static_assert feature is not provided by the compiler, a compatibility implementation is available via the <PREFIX>_STATIC_ASSERT(COND) and <PREFIX>_STATIC_ASSERT_MSG(COND, MSG) function-like macros. The macros expand to static_assert where that compiler feature is available, and to a compatibility implementation otherwise. In the first form, the condition is stringified in the message field of static_assert. In the second form, the message MSG is passed to the message field of static_assert, or ignored if using the backward compatibility implementation.

The cxx_attribute_deprecated feature provides a macro definition <PREFIX>_DEPRECATED, which expands to either the standard [[deprecated]] attribute or a compiler-specific decorator such as __attribute__((__deprecated__)) used by GNU compilers.

The cxx_alignas feature provides a macro definition <PREFIX>_ALIGNAS which expands to either the standard alignas decorator or a compiler-specific decorator such as __attribute__ ((__aligned__)) used by GNU compilers.

The cxx_alignof feature provides a macro definition <PREFIX>_ALIGNOF which expands to either the standard alignof decorator or a compiler-specific decorator such as __alignof__ used by GNU compilers.

Feature | Define | Symbol | bare
cxx_alignas | <PREFIX>_ALIGNAS | alignas |
cxx_alignof | <PREFIX>_ALIGNOF | alignof |
cxx_nullptr | <PREFIX>_NULLPTR | nullptr | yes
cxx_static_assert | <PREFIX>_STATIC_ASSERT | static_assert |
cxx_static_assert | <PREFIX>_STATIC_ASSERT_MSG | static_assert |
cxx_attribute_deprecated | <PREFIX>_DEPRECATED | [[deprecated]] |
cxx_attribute_deprecated | <PREFIX>_DEPRECATED_MSG | [[deprecated]] |
cxx_thread_local | <PREFIX>_THREAD_LOCAL | thread_local |

A use-case which arises with such deprecation macros is the deprecation of an entire library. In that case, all public API in the library may be decorated with the <PREFIX>_DEPRECATED macro. This results in very noisy build output when building the library itself, so the macro may be may be defined to empty in that case when building the deprecated library:

add_library(compat_support ${srcs})
target_compile_definitions(compat_support
  PRIVATE
    CompatSupport_DEPRECATED=
)

  • cmake-modules(7) »


FindALSA — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindALSA

Find alsa

Find the alsa libraries (asound)

IMPORTED Targets

This module defines IMPORTED target ALSA::ALSA, if ALSA has been found.

Result Variables

This module defines the following variables:

ALSA_FOUND
True if ALSA_INCLUDE_DIR & ALSA_LIBRARY are found
ALSA_LIBRARIES
List of libraries when using ALSA.
ALSA_INCLUDE_DIRS
Where to find the ALSA headers.

Cache variables

The following cache variables may also be set:

ALSA_INCLUDE_DIR
the ALSA include directory
ALSA_LIBRARY
the absolute path of the asound library

  • cmake-modules(7) »


FindArmadillo — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindArmadillo

Find Armadillo

Find the Armadillo C++ library

Using Armadillo:

find_package(Armadillo REQUIRED)
include_directories(${ARMADILLO_INCLUDE_DIRS})
add_executable(foo foo.cc)
target_link_libraries(foo ${ARMADILLO_LIBRARIES})

This module sets the following variables:

ARMADILLO_FOUND - set to true if the library is found
ARMADILLO_INCLUDE_DIRS - list of required include directories
ARMADILLO_LIBRARIES - list of libraries to be linked
ARMADILLO_VERSION_MAJOR - major version number
ARMADILLO_VERSION_MINOR - minor version number
ARMADILLO_VERSION_PATCH - patch version number
ARMADILLO_VERSION_STRING - version number as a string (ex: "1.0.4")
ARMADILLO_VERSION_NAME - name of the version (ex: "Antipodean Antileech")

  • cmake-modules(7) »


FindASPELL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindASPELL

Try to find ASPELL

Once done this will define

ASPELL_FOUND - system has ASPELL
ASPELL_EXECUTABLE - the ASPELL executable
ASPELL_INCLUDE_DIR - the ASPELL include directory
ASPELL_LIBRARIES - The libraries needed to use ASPELL
ASPELL_DEFINITIONS - Compiler switches required for using ASPELL

  • cmake-modules(7) »


FindAVIFile — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindAVIFile

Locate AVIFILE library and include paths

AVIFILE (http://avifile.sourceforge.net/)is a set of libraries for i386 machines to use various AVI codecs. Support is limited beyond Linux. Windows provides native AVI support, and so doesn’t need this library. This module defines

AVIFILE_INCLUDE_DIR, where to find avifile.h , etc.
AVIFILE_LIBRARIES, the libraries to link against
AVIFILE_DEFINITIONS, definitions to use when compiling
AVIFILE_FOUND, If false, don't try to use AVIFILE

  • cmake-modules(7) »


FindBISON — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindBISON

Find bison executable and provide a macro to generate custom build rules.

The module defines the following variables:

BISON_EXECUTABLE
path to the bison program
BISON_VERSION
version of bison
BISON_FOUND
true if the program was found

The minimum required version of bison can be specified using the standard CMake syntax, e.g. find_package(BISON 2.1.3).

If bison is found, the module defines the macro:

BISON_TARGET(<Name> <YaccInput> <CodeOutput>
             [COMPILE_FLAGS <flags>]
             [DEFINES_FILE <file>]
             [VERBOSE [<file>]]
             [REPORT_FILE <file>]
             )

which will create a custom rule to generate a parser. <YaccInput> is the path to a yacc file. <CodeOutput> is the name of the source file generated by bison. A header file is also be generated, and contains the token list.

The options are:

COMPILE_FLAGS <flags>
Specify flags to be added to the bison command line.
DEFINES_FILE <file>
Specify a non-default header <file> to be generated by bison.
VERBOSE [<file>]
Tell bison to write a report file of the grammar and parser. If <file> is given, it specifies path the report file is copied to. [<file>] is left for backward compatibility of this module. Use VERBOSE REPORT_FILE <file>.
REPORT_FILE <file>
Specify a non-default report <file>, if generated.

The macro defines the following variables:

BISON_<Name>_DEFINED
true is the macro ran successfully
BISON_<Name>_INPUT
The input source file, an alias for <YaccInput>
BISON_<Name>_OUTPUT_SOURCE
The source file generated by bison
BISON_<Name>_OUTPUT_HEADER
The header file generated by bison
BISON_<Name>_OUTPUTS
All files generated by bison including the source, the header and the report
BISON_<Name>_COMPILE_FLAGS
Options used in the bison command line

Example usage:

find_package(BISON)
BISON_TARGET(MyParser parser.y ${CMAKE_CURRENT_BINARY_DIR}/parser.cpp
             DEFINES_FILE ${CMAKE_CURRENT_BINARY_DIR}/parser.h)
add_executable(Foo main.cpp ${BISON_MyParser_OUTPUTS})

  • cmake-modules(7) »


FindBLAS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindBLAS

Find BLAS library

This module finds an installed fortran library that implements the BLAS linear-algebra interface (see http://www.netlib.org/blas/). The list of libraries searched for is taken from the autoconf macro file, acx_blas.m4 (distributed at http://ac-archive.sourceforge.net/ac-archive/acx_blas.html).

Input Variables

The following variables may be set to influence this module’s behavior:

BLA_STATIC
if ON use static linkage
BLA_VENDOR

If set, checks only the specified vendor, if not set checks all the possibilities. List of vendors valid in this module:

  • Goto
  • OpenBLAS
  • FLAME
  • ATLAS PhiPACK
  • CXML
  • DXML
  • SunPerf
  • SCSL
  • SGIMATH
  • IBMESSL
  • Intel10_32 (intel mkl v10 32 bit)
  • Intel10_64lp (intel mkl v10+ 64 bit, threaded code, lp64 model)
  • Intel10_64lp_seq (intel mkl v10+ 64 bit, sequential code, lp64 model)
  • Intel10_64ilp (intel mkl v10+ 64 bit, threaded code, ilp64 model)
  • Intel10_64ilp_seq (intel mkl v10+ 64 bit, sequential code, ilp64 model)
  • Intel (obsolete versions of mkl 32 and 64 bit)
  • ACML
  • ACML_MP
  • ACML_GPU
  • Apple
  • NAS
  • Generic
BLA_F95
if ON tries to find the BLAS95 interfaces
BLA_PREFER_PKGCONFIG
if set pkg-config will be used to search for a BLAS library first and if one is found that is preferred

Result Variables

This module defines the following variables:

BLAS_FOUND
library implementing the BLAS interface is found
BLAS_LINKER_FLAGS
uncached list of required linker flags (excluding -l and -L).
BLAS_LIBRARIES
uncached list of libraries (using full path name) to link against to use BLAS (may be empty if compiler implicitly links BLAS)
BLAS95_LIBRARIES
uncached list of libraries (using full path name) to link against to use BLAS95 interface
BLAS95_FOUND
library implementing the BLAS95 interface is found

Note

C or CXX must be enabled to use Intel MKL

For example, to use Intel MKL libraries and/or Intel compiler:

set(BLA_VENDOR Intel10_64lp)
find_package(BLAS)

  • cmake-modules(7) »


FindBacktrace — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindBacktrace

Find provider for backtrace(3).

Checks if OS supports backtrace(3) via either libc or custom library. This module defines the following variables:

Backtrace_HEADER
The header file needed for backtrace(3). Cached. Could be forcibly set by user.
Backtrace_INCLUDE_DIRS
The include directories needed to use backtrace(3) header.
Backtrace_LIBRARIES
The libraries (linker flags) needed to use backtrace(3), if any.
Backtrace_FOUND
Is set if and only if backtrace(3) support detected.

The following cache variables are also available to set or use:

Backtrace_LIBRARY
The external library providing backtrace, if any.
Backtrace_INCLUDE_DIR
The directory holding the backtrace(3) header.

Typical usage is to generate of header file using configure_file() with the contents like the following:

#cmakedefine01 Backtrace_FOUND
#if Backtrace_FOUND
# include <${Backtrace_HEADER}>
#endif

And then reference that generated header file in actual source.

  • cmake-modules(7) »


FindBoost — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindBoost

Find Boost include dirs and libraries

Use this module by invoking find_package with the form:

find_package(Boost
  [version] [EXACT]      # Minimum or EXACT version e.g. 1.67.0
  [REQUIRED]             # Fail with error if Boost is not found
  [COMPONENTS <libs>...] # Boost libraries by their canonical name
                         # e.g. "date_time" for "libboost_date_time"
  [OPTIONAL_COMPONENTS <libs>...]
                         # Optional Boost libraries by their canonical name)
  )                      # e.g. "date_time" for "libboost_date_time"

This module finds headers and requested component libraries OR a CMake package configuration file provided by a “Boost CMake” build. For the latter case skip to the “Boost CMake” section below. For the former case results are reported in variables:

Boost_FOUND            - True if headers and requested libraries were found
Boost_INCLUDE_DIRS     - Boost include directories
Boost_LIBRARY_DIRS     - Link directories for Boost libraries
Boost_LIBRARIES        - Boost component libraries to be linked
Boost_<C>_FOUND        - True if component <C> was found (<C> is upper-case)
Boost_<C>_LIBRARY      - Libraries to link for component <C> (may include
                         target_link_libraries debug/optimized keywords)
Boost_VERSION          - BOOST_VERSION value from boost/version.hpp
Boost_LIB_VERSION      - Version string appended to library filenames
Boost_MAJOR_VERSION    - Boost major version number (X in X.y.z)
Boost_MINOR_VERSION    - Boost minor version number (Y in x.Y.z)
Boost_SUBMINOR_VERSION - Boost subminor version number (Z in x.y.Z)
Boost_VERSION_STRING   - Boost version number in x.y.z format
Boost_LIB_DIAGNOSTIC_DEFINITIONS (Windows)
                       - Pass to add_definitions() to have diagnostic
                         information about Boost's automatic linking
                         displayed during compilation

Note that Boost Python components require a Python version suffix (Boost 1.67 and later), e.g. python36 or python27 for the versions built against Python 3.6 and 2.7, respectively. This also applies to additional components using Python including mpi_python and numpy. Earlier Boost releases may use distribution-specific suffixes such as 2, 3 or 2.7. These may also be used as suffixes, but note that they are not portable.

This module reads hints about search locations from variables:

BOOST_ROOT             - Preferred installation prefix
 (or BOOSTROOT)
BOOST_INCLUDEDIR       - Preferred include directory e.g. <prefix>/include
BOOST_LIBRARYDIR       - Preferred library directory e.g. <prefix>/lib
Boost_NO_SYSTEM_PATHS  - Set to ON to disable searching in locations not
                         specified by these hint variables. Default is OFF.
Boost_ADDITIONAL_VERSIONS
                       - List of Boost versions not known to this module
                         (Boost install locations may contain the version)

and saves search results persistently in CMake cache entries:

Boost_INCLUDE_DIR         - Directory containing Boost headers
Boost_LIBRARY_DIR_RELEASE - Directory containing release Boost libraries
Boost_LIBRARY_DIR_DEBUG   - Directory containing debug Boost libraries
Boost_<C>_LIBRARY_DEBUG   - Component <C> library debug variant
Boost_<C>_LIBRARY_RELEASE - Component <C> library release variant

The following IMPORTED targets are also defined:

Boost::boost                  - Target for header-only dependencies
                                (Boost include directory)
Boost::<C>                    - Target for specific component dependency
                                (shared or static library); <C> is lower-
                                case
Boost::diagnostic_definitions - interface target to enable diagnostic
                                information about Boost's automatic linking
                                during compilation (adds BOOST_LIB_DIAGNOSTIC)
Boost::disable_autolinking    - interface target to disable automatic
                                linking with MSVC (adds BOOST_ALL_NO_LIB)
Boost::dynamic_linking        - interface target to enable dynamic linking
                                linking with MSVC (adds BOOST_ALL_DYN_LINK)

Implicit dependencies such as Boost::filesystem requiring Boost::system will be automatically detected and satisfied, even if system is not specified when using find_package and if Boost::system is not added to target_link_libraries. If using Boost::thread, then Threads::Threads will also be added automatically.

It is important to note that the imported targets behave differently than variables created by this module: multiple calls to find_package(Boost) in the same directory or sub-directories with different options (e.g. static or shared) will not override the values of the targets created by the first call.

Users may set these hints or results as cache entries. Projects should not read these entries directly but instead use the above result variables. Note that some hint names start in upper-case “BOOST”. One may specify these as environment variables if they are not specified as CMake variables or cache entries.

This module first searches for the Boost header files using the above hint variables (excluding BOOST_LIBRARYDIR) and saves the result in Boost_INCLUDE_DIR. Then it searches for requested component libraries using the above hints (excluding BOOST_INCLUDEDIR and Boost_ADDITIONAL_VERSIONS), “lib” directories near Boost_INCLUDE_DIR, and the library name configuration settings below. It saves the library directories in Boost_LIBRARY_DIR_DEBUG and Boost_LIBRARY_DIR_RELEASE and individual library locations in Boost_<C>_LIBRARY_DEBUG and Boost_<C>_LIBRARY_RELEASE. When one changes settings used by previous searches in the same build tree (excluding environment variables) this module discards previous search results affected by the changes and searches again.

Boost libraries come in many variants encoded in their file name. Users or projects may tell this module which variant to find by setting variables:

Boost_USE_DEBUG_LIBS     - Set to ON or OFF to specify whether to search
                           and use the debug libraries.  Default is ON.
Boost_USE_RELEASE_LIBS   - Set to ON or OFF to specify whether to search
                           and use the release libraries.  Default is ON.
Boost_USE_MULTITHREADED  - Set to OFF to use the non-multithreaded
                           libraries ('mt' tag).  Default is ON.
Boost_USE_STATIC_LIBS    - Set to ON to force the use of the static
                           libraries.  Default is OFF.
Boost_USE_STATIC_RUNTIME - Set to ON or OFF to specify whether to use
                           libraries linked statically to the C++ runtime
                           ('s' tag).  Default is platform dependent.
Boost_USE_DEBUG_RUNTIME  - Set to ON or OFF to specify whether to use
                           libraries linked to the MS debug C++ runtime
                           ('g' tag).  Default is ON.
Boost_USE_DEBUG_PYTHON   - Set to ON to use libraries compiled with a
                           debug Python build ('y' tag). Default is OFF.
Boost_USE_STLPORT        - Set to ON to use libraries compiled with
                           STLPort ('p' tag).  Default is OFF.
Boost_USE_STLPORT_DEPRECATED_NATIVE_IOSTREAMS
                         - Set to ON to use libraries compiled with
                           STLPort deprecated "native iostreams"
                           ('n' tag).  Default is OFF.
Boost_COMPILER           - Set to the compiler-specific library suffix
                           (e.g. "-gcc43").  Default is auto-computed
                           for the C++ compiler in use.  A list may be
                           used if multiple compatible suffixes should
                           be tested for, in decreasing order of
                           preference.
Boost_ARCHITECTURE       - Set to the architecture-specific library suffix
                           (e.g. "-x64").  Default is auto-computed for the
                           C++ compiler in use.
Boost_THREADAPI          - Suffix for "thread" component library name,
                           such as "pthread" or "win32".  Names with
                           and without this suffix will both be tried.
Boost_NAMESPACE          - Alternate namespace used to build boost with
                           e.g. if set to "myboost", will search for
                           myboost_thread instead of boost_thread.

Other variables one may set to control this module are:

Boost_DEBUG              - Set to ON to enable debug output from FindBoost.
                           Please enable this before filing any bug report.
Boost_DETAILED_FAILURE_MSG
                         - Set to ON to add detailed information to the
                           failure message even when the REQUIRED option
                           is not given to the find_package call.
Boost_REALPATH           - Set to ON to resolve symlinks for discovered
                           libraries to assist with packaging.  For example,
                           the "system" component library may be resolved to
                           "/usr/lib/libboost_system.so.1.67.0" instead of
                           "/usr/lib/libboost_system.so".  This does not
                           affect linking and should not be enabled unless
                           the user needs this information.
Boost_LIBRARY_DIR        - Default value for Boost_LIBRARY_DIR_RELEASE and
                           Boost_LIBRARY_DIR_DEBUG.

On Visual Studio and Borland compilers Boost headers request automatic linking to corresponding libraries. This requires matching libraries to be linked explicitly or available in the link library search path. In this case setting Boost_USE_STATIC_LIBS to OFF may not achieve dynamic linking. Boost automatic linking typically requests static libraries with a few exceptions (such as Boost.Python). Use:

add_definitions(${Boost_LIB_DIAGNOSTIC_DEFINITIONS})

to ask Boost to report information about automatic linking requests.

Example to find Boost headers only:

find_package(Boost 1.36.0)
if(Boost_FOUND)
  include_directories(${Boost_INCLUDE_DIRS})
  add_executable(foo foo.cc)
endif()

Example to find Boost libraries and use imported targets:

find_package(Boost 1.56 REQUIRED COMPONENTS
             date_time filesystem iostreams)
add_executable(foo foo.cc)
target_link_libraries(foo Boost::date_time Boost::filesystem
                          Boost::iostreams)

Example to find Boost Python 3.6 libraries and use imported targets:

find_package(Boost 1.67 REQUIRED COMPONENTS
             python36 numpy36)
add_executable(foo foo.cc)
target_link_libraries(foo Boost::python36 Boost::numpy36)

Example to find Boost headers and some static (release only) libraries:

set(Boost_USE_STATIC_LIBS        ON)  # only find static libs
set(Boost_USE_DEBUG_LIBS         OFF) # ignore debug libs and
set(Boost_USE_RELEASE_LIBS       ON)  # only find release libs
set(Boost_USE_MULTITHREADED      ON)
set(Boost_USE_STATIC_RUNTIME    OFF)
find_package(Boost 1.66.0 COMPONENTS date_time filesystem system ...)
if(Boost_FOUND)
  include_directories(${Boost_INCLUDE_DIRS})
  add_executable(foo foo.cc)
  target_link_libraries(foo ${Boost_LIBRARIES})
endif()

Boost CMake

If Boost was built using the boost-cmake project it provides a package configuration file for use with find_package’s Config mode. This module looks for the package configuration file called BoostConfig.cmake or boost-config.cmake and stores the result in cache entry “Boost_DIR”. If found, the package configuration file is loaded and this module returns with no further action. See documentation of the Boost CMake package configuration for details on what it provides.

Set Boost_NO_BOOST_CMAKE to ON to disable the search for boost-cmake.

  • cmake-modules(7) »


FindBullet — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindBullet

Try to find the Bullet physics engine

This module defines the following variables

BULLET_FOUND - Was bullet found
BULLET_INCLUDE_DIRS - the Bullet include directories
BULLET_LIBRARIES - Link to this, by default it includes
                   all bullet components (Dynamics,
                   Collision, LinearMath, & SoftBody)

This module accepts the following variables

BULLET_ROOT - Can be set to bullet install path or Windows build path

  • cmake-modules(7) »


FindBZip2 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindBZip2

Try to find BZip2

IMPORTED Targets

This module defines IMPORTED target BZip2::BZip2, if BZip2 has been found.

Result Variables

This module defines the following variables:

BZIP2_FOUND
system has BZip2
BZIP2_INCLUDE_DIRS
the BZip2 include directories
BZIP2_LIBRARIES
Link these to use BZip2
BZIP2_NEED_PREFIX
this is set if the functions are prefixed with BZ2_
BZIP2_VERSION_STRING
the version of BZip2 found

Cache variables

The following cache variables may also be set:

BZIP2_INCLUDE_DIR
the BZip2 include directory

  • cmake-modules(7) »


FindCABLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindCABLE

Find CABLE

This module finds if CABLE is installed and determines where the include files and libraries are. This code sets the following variables:

CABLE             the path to the cable executable
CABLE_TCL_LIBRARY the path to the Tcl wrapper library
CABLE_INCLUDE_DIR the path to the include directory

To build Tcl wrappers, you should add shared library and link it to ${CABLE_TCL_LIBRARY}. You should also add ${CABLE_INCLUDE_DIR} as an include directory.

  • cmake-modules(7) »


FindCoin3D — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindCoin3D

Find Coin3D (Open Inventor)

Coin3D is an implementation of the Open Inventor API. It provides data structures and algorithms for 3D visualization.

This module defines the following variables

COIN3D_FOUND         - system has Coin3D - Open Inventor
COIN3D_INCLUDE_DIRS  - where the Inventor include directory can be found
COIN3D_LIBRARIES     - Link to this to use Coin3D

  • cmake-modules(7) »


FindCups — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindCups

Try to find the Cups printing system

Once done this will define

CUPS_FOUND - system has Cups
CUPS_INCLUDE_DIR - the Cups include directory
CUPS_LIBRARIES - Libraries needed to use Cups
CUPS_VERSION_STRING - version of Cups found (since CMake 2.8.8)
Set CUPS_REQUIRE_IPP_DELETE_ATTRIBUTE to TRUE if you need a version which
features this function (i.e. at least 1.1.19)

  • cmake-modules(7) »


FindCURL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindCURL

Find the native CURL headers and libraries.

This module accept optional COMPONENTS to check supported features and protocols:

PROTOCOLS: ICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS POP3
           POP3S RTMP RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP
FEATURES:  SSL IPv6 UnixSockets libz AsynchDNS IDN GSS-API PSL SPNEGO
           Kerberos NTLM NTLM_WB TLS-SRP HTTP2 HTTPS-proxy

IMPORTED Targets

This module defines IMPORTED target CURL::libcurl, if curl has been found.

Result Variables

This module defines the following variables:

CURL_FOUND
True if curl found.
CURL_INCLUDE_DIRS
where to find curl/curl.h, etc.
CURL_LIBRARIES
List of libraries when using curl.
CURL_VERSION_STRING
The version of curl found.

  • cmake-modules(7) »


FindCurses — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindCurses

Find the curses or ncurses include file and library.

Result Variables

This module defines the following variables:

CURSES_FOUND
True if Curses is found.
CURSES_INCLUDE_DIRS
The include directories needed to use Curses.
CURSES_LIBRARIES
The libraries needed to use Curses.
CURSES_HAVE_CURSES_H
True if curses.h is available.
CURSES_HAVE_NCURSES_H
True if ncurses.h is available.
CURSES_HAVE_NCURSES_NCURSES_H
True if ncurses/ncurses.h is available.
CURSES_HAVE_NCURSES_CURSES_H
True if ncurses/curses.h is available.

Set CURSES_NEED_NCURSES to TRUE before the find_package(Curses) call if NCurses functionality is required. Set CURSES_NEED_WIDE to TRUE before the find_package(Curses) call if unicode functionality is required.

Backward Compatibility

The following variable are provided for backward compatibility:

CURSES_INCLUDE_DIR
Path to Curses include. Use CURSES_INCLUDE_DIRS instead.
CURSES_LIBRARY
Path to Curses library. Use CURSES_LIBRARIES instead.

  • cmake-modules(7) »


FindCVS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindCVS

The module defines the following variables:

CVS_EXECUTABLE - path to cvs command line client
CVS_FOUND - true if the command line client was found

Example usage:

find_package(CVS)
if(CVS_FOUND)
  message("CVS found: ${CVS_EXECUTABLE}")
endif()

  • cmake-modules(7) »


FindCxxTest — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindCxxTest

Find CxxTest

Find the CxxTest suite and declare a helper macro for creating unit tests and integrating them with CTest. For more details on CxxTest see http://cxxtest.tigris.org

INPUT Variables

CXXTEST_USE_PYTHON [deprecated since 1.3]
    Only used in the case both Python & Perl
    are detected on the system to control
    which CxxTest code generator is used.
    Valid only for CxxTest version 3.

NOTE: In older versions of this Find Module,
this variable controlled if the Python test
generator was used instead of the Perl one,
regardless of which scripting language the
user had installed.

CXXTEST_TESTGEN_ARGS (since CMake 2.8.3)
    Specify a list of options to pass to the CxxTest code
    generator.  If not defined, --error-printer is
    passed.

OUTPUT Variables

CXXTEST_FOUND
    True if the CxxTest framework was found
CXXTEST_INCLUDE_DIRS
    Where to find the CxxTest include directory
CXXTEST_PERL_TESTGEN_EXECUTABLE
    The perl-based test generator
CXXTEST_PYTHON_TESTGEN_EXECUTABLE
    The python-based test generator
CXXTEST_TESTGEN_EXECUTABLE (since CMake 2.8.3)
    The test generator that is actually used (chosen using user preferences
    and interpreters found in the system)
CXXTEST_TESTGEN_INTERPRETER (since CMake 2.8.3)
    The full path to the Perl or Python executable on the system, on
    platforms where the script cannot be executed using its shebang line.

MACROS for optional use by CMake users:

CXXTEST_ADD_TEST(<test_name> <gen_source_file> <input_files_to_testgen...>)
   Creates a CxxTest runner and adds it to the CTest testing suite
   Parameters:
       test_name               The name of the test
       gen_source_file         The generated source filename to be
                               generated by CxxTest
       input_files_to_testgen  The list of header files containing the
                               CxxTest::TestSuite's to be included in
                               this runner

#==============
Example Usage:

find_package(CxxTest)
if(CXXTEST_FOUND)
    include_directories(${CXXTEST_INCLUDE_DIR})
    enable_testing()

    CXXTEST_ADD_TEST(unittest_foo foo_test.cc
                      ${CMAKE_CURRENT_SOURCE_DIR}/foo_test.h)
    target_link_libraries(unittest_foo foo) # as needed
endif()

This will (if CxxTest is found):
1. Invoke the testgen executable to autogenerate foo_test.cc in the
   binary tree from "foo_test.h" in the current source directory.
2. Create an executable and test called unittest_foo.

#=============
Example foo_test.h:

#include <cxxtest/TestSuite.h>

class MyTestSuite : public CxxTest::TestSuite
{
public:
   void testAddition( void )
   {
      TS_ASSERT( 1 + 1 > 1 );
      TS_ASSERT_EQUALS( 1 + 1, 2 );
   }
};

  • cmake-modules(7) »


FindCygwin — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindCygwin

this module looks for Cygwin

  • cmake-modules(7) »


FindDart — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindDart

Find DART

This module looks for the dart testing software and sets DART_ROOT to point to where it found it.

  • cmake-modules(7) »


FindDCMTK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindDCMTK

Find DCMTK libraries and applications

The module defines the following variables:

DCMTK_INCLUDE_DIRS  - Directories to include to use DCMTK
DCMTK_LIBRARIES     - Files to link against to use DCMTK
DCMTK_FOUND         - If false, don't try to use DCMTK
DCMTK_DIR           - (optional) Source directory for DCMTK

Compatibility

This module is able to find a version of DCMTK that does or does not export a DCMTKConfig.cmake file. It applies a two step process:

  • Step 1: Attempt to find DCMTK version providing a DCMTKConfig.cmake file.
  • Step 2: If step 1 failed, rely on FindDCMTK.cmake to set DCMTK_* variables details below.

Recent DCMTK provides a DCMTKConfig.cmake package configuration file. To exclusively use the package configuration file (recommended when possible), pass the NO_MODULE option to find_package(). For example, find_package(DCMTK NO_MODULE). This requires official DCMTK snapshot 3.6.1_20140617 or newer.

Until all clients update to the more recent DCMTK, build systems will need to support different versions of DCMTK.

On any given system, the following combinations of DCMTK versions could be considered:

 | SYSTEM DCMTK | LOCAL DCMTK | Supported ?
Case A | NA | [ ] DCMTKConfig | YES
Case B | NA | [X] DCMTKConfig | YES
Case C | [ ] DCMTKConfig | NA | YES
Case D | [X] DCMTKConfig | NA | YES
Case E | [ ] DCMTKConfig | [ ] DCMTKConfig | YES (*)
Case F | [X] DCMTKConfig | [ ] DCMTKConfig | NO
Case G | [ ] DCMTKConfig | [X] DCMTKConfig | YES
Case H | [X] DCMTKConfig | [X] DCMTKConfig | YES
(*) See Troubleshooting section.

Legend:

NA ……………: Means that no System or Local DCMTK is available

[ ] DCMTKConfig ..: Means that the version of DCMTK does NOT export a DCMTKConfig.cmake file.

[X] DCMTKConfig ..: Means that the version of DCMTK exports a DCMTKConfig.cmake file.

Troubleshooting

What to do if my project finds a different version of DCMTK?

Remove DCMTK entry from the CMake cache per find_package() documentation.

  • cmake-modules(7) »


FindDevIL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindDevIL

This module locates the developer’s image library. http://openil.sourceforge.net/

This module sets:

IL_LIBRARIES -   the name of the IL library. These include the full path to
                 the core DevIL library. This one has to be linked into the
                 application.
ILU_LIBRARIES -  the name of the ILU library. Again, the full path. This
                 library is for filters and effects, not actual loading. It
                 doesn't have to be linked if the functionality it provides
                 is not used.
ILUT_LIBRARIES - the name of the ILUT library. Full path. This part of the
                 library interfaces with OpenGL. It is not strictly needed
                 in applications.
IL_INCLUDE_DIR - where to find the il.h, ilu.h and ilut.h files.
DevIL_FOUND    - this is set to TRUE if all the above variables were set.
                 This will be set to false if ILU or ILUT are not found,
                 even if they are not needed. In most systems, if one
                 library is found all the others are as well. That's the
                 way the DevIL developers release it.

  • cmake-modules(7) »


FindDoxygen — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindDoxygen

Doxygen is a documentation generation tool (see http://www.doxygen.org). This module looks for Doxygen and some optional tools it supports. These tools are enabled as components in the find_package() command:

dot
Graphviz dot utility used to render various graphs.
mscgen
Message Chart Generator utility used by Doxygen’s \msc and \mscfile commands.
dia
Dia the diagram editor used by Doxygen’s \diafile command.

Examples:

# Require dot, treat the other components as optional
find_package(Doxygen
             REQUIRED dot
             OPTIONAL_COMPONENTS mscgen dia)

The following variables are defined by this module:

DOXYGEN_FOUND

True if the doxygen executable was found.

DOXYGEN_VERSION

The version reported by doxygen --version.

The module defines IMPORTED targets for Doxygen and each component found. These can be used as part of custom commands, etc. and should be preferred over old-style (and now deprecated) variables like DOXYGEN_EXECUTABLE. The following import targets are defined if their corresponding executable could be found (the component import targets will only be defined if that component was requested):

Doxygen::doxygen
Doxygen::dot
Doxygen::mscgen
Doxygen::dia

Functions

doxygen_add_docs

This function is intended as a convenience for adding a target for generating documentation with Doxygen. It aims to provide sensible defaults so that projects can generally just provide the input files and directories and that will be sufficient to give sensible results. The function supports the ability to customize the Doxygen configuration used to build the documentation.

doxygen_add_docs(targetName
    [filesOrDirs...]
    [ALL]
    [WORKING_DIRECTORY dir]
    [COMMENT comment])

The function constructs a Doxyfile and defines a custom target that runs Doxygen on that generated file. The listed files and directories are used as the INPUT of the generated Doxyfile and they can contain wildcards. Any files that are listed explicitly will also be added as SOURCES of the custom target so they will show up in an IDE project’s source list.

So that relative input paths work as expected, by default the working directory of the Doxygen command will be the current source directory (i.e. CMAKE_CURRENT_SOURCE_DIR). This can be overridden with the WORKING_DIRECTORY option to change the directory used as the relative base point. Note also that Doxygen’s default behavior is to strip the working directory from relative paths in the generated documentation (see the STRIP_FROM_PATH Doxygen config option for details).

If provided, the optional comment will be passed as the COMMENT for the add_custom_target() command used to create the custom target internally.

If ALL is set, the target will be added to the default build target.

The contents of the generated Doxyfile can be customized by setting CMake variables before calling doxygen_add_docs(). Any variable with a name of the form DOXYGEN_<tag> will have its value substituted for the corresponding <tag> configuration option in the Doxyfile. See the Doxygen documentation for the full list of supported configuration options.

Some of Doxygen’s defaults are overridden to provide more appropriate behavior for a CMake project. Each of the following will be explicitly set unless the variable already has a value before doxygen_add_docs() is called (with some exceptions noted):

DOXYGEN_HAVE_DOT

Set to YES if the dot component was requested and it was found, NO otherwise. Any existing value of DOXYGEN_HAVE_DOT is ignored.

DOXYGEN_DOT_MULTI_TARGETS

Set to YES by this module (note that this requires a dot version newer than 1.8.10). This option is only meaningful if DOXYGEN_HAVE_DOT is also set to YES.

DOXYGEN_GENERATE_LATEX

Set to NO by this module.

DOXYGEN_WARN_FORMAT

For Visual Studio based generators, this is set to the form recognized by the Visual Studio IDE: $file($line) : $text. For all other generators, Doxygen’s default value is not overridden.

DOXYGEN_PROJECT_NAME

Populated with the name of the current project (i.e. PROJECT_NAME).

DOXYGEN_PROJECT_NUMBER

Populated with the version of the current project (i.e. PROJECT_VERSION).

DOXYGEN_PROJECT_BRIEF

Populated with the description of the current project (i.e. PROJECT_DESCRIPTION).

DOXYGEN_INPUT

Projects should not set this variable. It will be populated with the set of files and directories passed to doxygen_add_docs(), thereby providing consistent behavior with the other built-in commands like add_executable(), add_library() and add_custom_target(). If a variable named DOXYGEN_INPUT is set by the project, it will be ignored and a warning will be issued.

DOXYGEN_RECURSIVE

Set to YES by this module.

DOXYGEN_EXCLUDE_PATTERNS

If the set of inputs includes directories, this variable will specify patterns used to exclude files from them. The following patterns are added by doxygen_add_docs() to ensure CMake-specific files and directories are not included in the input. If the project sets DOXYGEN_EXCLUDE_PATTERNS, those contents are merged with these additional patterns rather than replacing them:

*/.git/*
*/.svn/*
*/.hg/*
*/CMakeFiles/*
*/_CPack_Packages/*
DartConfiguration.tcl
CMakeLists.txt
CMakeCache.txt
DOXYGEN_OUTPUT_DIRECTORY

Set to CMAKE_CURRENT_BINARY_DIR by this module. Note that if the project provides its own value for this and it is a relative path, it will be converted to an absolute path relative to the current binary directory. This is necessary because doxygen will normally be run from a directory within the source tree so that relative source paths work as expected. If this directory does not exist, it will be recursively created prior to executing the doxygen commands.

To change any of these defaults or override any other Doxygen config option, set relevant variables before calling doxygen_add_docs(). For example:

set(DOXYGEN_GENERATE_HTML NO)
set(DOXYGEN_GENERATE_MAN YES)

doxygen_add_docs(
    doxygen
    ${PROJECT_SOURCE_DIR}
    COMMENT "Generate man pages"
)

A number of Doxygen config options accept lists of values, but Doxygen requires them to be separated by whitespace. CMake variables hold lists as a string with items separated by semi-colons, so a conversion needs to be performed. The doxygen_add_docs() command specifically checks the following Doxygen config options and will convert their associated CMake variable’s contents into the required form if set.

ABBREVIATE_BRIEF
ALIASES
CITE_BIB_FILES
DIAFILE_DIRS
DOTFILE_DIRS
DOT_FONTPATH
ENABLED_SECTIONS
EXAMPLE_PATH
EXAMPLE_PATTERNS
EXCLUDE
EXCLUDE_PATTERNS
EXCLUDE_SYMBOLS
EXPAND_AS_DEFINED
EXTENSION_MAPPING
EXTRA_PACKAGES
EXTRA_SEARCH_MAPPINGS
FILE_PATTERNS
FILTER_PATTERNS
FILTER_SOURCE_PATTERNS
HTML_EXTRA_FILES
HTML_EXTRA_STYLESHEET
IGNORE_PREFIX
IMAGE_PATH
INCLUDE_FILE_PATTERNS
INCLUDE_PATH
INPUT
LATEX_EXTRA_FILES
LATEX_EXTRA_STYLESHEET
MATHJAX_EXTENSIONS
MSCFILE_DIRS
PLANTUML_INCLUDE_PATH
PREDEFINED
QHP_CUST_FILTER_ATTRS
QHP_SECT_FILTER_ATTRS
STRIP_FROM_INC_PATH
STRIP_FROM_PATH
TAGFILES
TCL_SUBST

The following single value Doxygen options will be quoted automatically if they contain at least one space:

CHM_FILE
DIA_PATH
DOCBOOK_OUTPUT
DOCSET_FEEDNAME
DOCSET_PUBLISHER_NAME
DOT_FONTNAME
DOT_PATH
EXTERNAL_SEARCH_ID
FILE_VERSION_FILTER
GENERATE_TAGFILE
HHC_LOCATION
HTML_FOOTER
HTML_HEADER
HTML_OUTPUT
HTML_STYLESHEET
INPUT_FILTER
LATEX_FOOTER
LATEX_HEADER
LATEX_OUTPUT
LAYOUT_FILE
MAN_OUTPUT
MAN_SUBDIR
MATHJAX_CODEFILE
MSCGEN_PATH
OUTPUT_DIRECTORY
PERL_PATH
PLANTUML_JAR_PATH
PROJECT_BRIEF
PROJECT_LOGO
PROJECT_NAME
QCH_FILE
QHG_LOCATION
QHP_CUST_FILTER_NAME
QHP_VIRTUAL_FOLDER
RTF_EXTENSIONS_FILE
RTF_OUTPUT
RTF_STYLESHEET_FILE
SEARCHDATA_FILE
USE_MDFILE_AS_MAINPAGE
WARN_FORMAT
WARN_LOGFILE
XML_OUTPUT

There are situations where it may be undesirable for a particular config option to be automatically quoted by doxygen_add_docs(), such as ALIASES which may need to include its own embedded quoting. The DOXYGEN_VERBATIM_VARS variable can be used to specify a list of Doxygen variables (including the leading DOXYGEN_ prefix) which should not be quoted. The project is then responsible for ensuring that those variables’ values make sense when placed directly in the Doxygen input file. In the case of list variables, list items are still separated by spaces, it is only the automatic quoting that is skipped. For example, the following allows doxygen_add_docs() to apply quoting to DOXYGEN_PROJECT_BRIEF, but not each item in the DOXYGEN_ALIASES list (bracket syntax can also be used to make working with embedded quotes easier):

set(DOXYGEN_PROJECT_BRIEF "String with spaces")
set(DOXYGEN_ALIASES
    [[somealias="@some_command param"]]
    "anotherAlias=@foobar"
)
set(DOXYGEN_VERBATIM_VARS DOXYGEN_ALIASES)

The resultant Doxyfile will contain the following lines:

PROJECT_BRIEF = "String with spaces"
ALIASES       = somealias="@some_command param" anotherAlias=@foobar

Deprecated Result Variables

For compatibility with previous versions of CMake, the following variables are also defined but they are deprecated and should no longer be used:

DOXYGEN_EXECUTABLE

The path to the doxygen command. If projects need to refer to the doxygen executable directly, they should use the Doxygen::doxygen import target instead.

DOXYGEN_DOT_FOUND

True if the dot executable was found.

DOXYGEN_DOT_EXECUTABLE

The path to the dot command. If projects need to refer to the dot executable directly, they should use the Doxygen::dot import target instead.

DOXYGEN_DOT_PATH

The path to the directory containing the dot executable as reported in DOXYGEN_DOT_EXECUTABLE. The path may have forward slashes even on Windows and is not suitable for direct substitution into a Doxyfile.in template. If you need this value, get the IMPORTED_LOCATION property of the Doxygen::dot target and use get_filename_component() to extract the directory part of that path. You may also want to consider using file(TO_NATIVE_PATH) to prepare the path for a Doxygen configuration file.

Deprecated Hint Variables

DOXYGEN_SKIP_DOT

This variable has no effect for the component form of find_package. In backward compatibility mode (i.e. without components list) it prevents the finder module from searching for Graphviz’s dot utility.

  • cmake-modules(7) »


FindEXPAT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindEXPAT

Find the native Expat headers and library.

Imported Targets

This module defines the following IMPORTED targets:

EXPAT::EXPAT
The Expat expat library, if found.

Result Variables

This module will set the following variables in your project:

EXPAT_INCLUDE_DIRS
where to find expat.h, etc.
EXPAT_LIBRARIES
the libraries to link against to use Expat.
EXPAT_FOUND
true if the Expat headers and libraries were found.

  • cmake-modules(7) »


FindFLEX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindFLEX

Find flex executable and provides a macro to generate custom build rules

The module defines the following variables:

FLEX_FOUND - true is flex executable is found
FLEX_EXECUTABLE - the path to the flex executable
FLEX_VERSION - the version of flex
FLEX_LIBRARIES - The flex libraries
FLEX_INCLUDE_DIRS - The path to the flex headers

The minimum required version of flex can be specified using the standard syntax, e.g. find_package(FLEX 2.5.13)

If flex is found on the system, the module provides the macro:

FLEX_TARGET(Name FlexInput FlexOutput
            [COMPILE_FLAGS <string>]
            [DEFINES_FILE <string>]
            )

which creates a custom command to generate the <FlexOutput> file from the <FlexInput> file. If COMPILE_FLAGS option is specified, the next parameter is added to the flex command line. If flex is configured to output a header file, the DEFINES_FILE option may be used to specify its name. Name is an alias used to get details of this custom command. Indeed the macro defines the following variables:

FLEX_${Name}_DEFINED - true is the macro ran successfully
FLEX_${Name}_OUTPUTS - the source file generated by the custom rule, an
alias for FlexOutput
FLEX_${Name}_INPUT - the flex source file, an alias for ${FlexInput}
FLEX_${Name}_OUTPUT_HEADER - the header flex output, if any.

Flex scanners often use tokens defined by Bison: the code generated by Flex depends of the header generated by Bison. This module also defines a macro:

ADD_FLEX_BISON_DEPENDENCY(FlexTarget BisonTarget)

which adds the required dependency between a scanner and a parser where <FlexTarget> and <BisonTarget> are the first parameters of respectively FLEX_TARGET and BISON_TARGET macros.

====================================================================
Example:

find_package(BISON)
find_package(FLEX)

BISON_TARGET(MyParser parser.y ${CMAKE_CURRENT_BINARY_DIR}/parser.cpp)
FLEX_TARGET(MyScanner lexer.l  ${CMAKE_CURRENT_BINARY_DIR}/lexer.cpp)
ADD_FLEX_BISON_DEPENDENCY(MyScanner MyParser)

 include_directories(${CMAKE_CURRENT_BINARY_DIR})
 add_executable(Foo
    Foo.cc
    ${BISON_MyParser_OUTPUTS}
    ${FLEX_MyScanner_OUTPUTS}
 )
====================================================================

  • cmake-modules(7) »


FindFLTK2 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindFLTK2

Find the native FLTK2 includes and library

The following settings are defined

FLTK2_FLUID_EXECUTABLE, where to find the Fluid tool
FLTK2_WRAP_UI, This enables the FLTK2_WRAP_UI command
FLTK2_INCLUDE_DIR, where to find include files
FLTK2_LIBRARIES, list of fltk2 libraries
FLTK2_FOUND, Don't use FLTK2 if false.

The following settings should not be used in general.

FLTK2_BASE_LIBRARY   = the full path to fltk2.lib
FLTK2_GL_LIBRARY     = the full path to fltk2_gl.lib
FLTK2_IMAGES_LIBRARY = the full path to fltk2_images.lib

  • cmake-modules(7) »


FindFLTK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindFLTK

Find the FLTK library

Input Variables

By default this module will search for all of the FLTK components and add them to the FLTK_LIBRARIES variable. You can limit the components which get placed in FLTK_LIBRARIES by defining one or more of the following three options:

FLTK_SKIP_OPENGL
Set to true to disable searching for the FLTK GL library
FLTK_SKIP_FORMS
Set to true to disable searching for the FLTK Forms library
FLTK_SKIP_IMAGES
Set to true to disable searching for the FLTK Images library

FLTK is composed also by a binary tool. You can set the following option:

FLTK_SKIP_FLUID
Set to true to not look for the FLUID binary

Result Variables

The following variables will be defined:

FLTK_FOUND
True if all components not skipped were found
FLTK_INCLUDE_DIR
Path to the include directory for FLTK header files
FLTK_LIBRARIES
List of the FLTK libraries found
FLTK_FLUID_EXECUTABLE
Path to the FLUID binary tool
FLTK_WRAP_UI
True if FLUID is found, used to enable the FLTK_WRAP_UI command

Cache Variables

The following cache variables are also available to set or use:

FLTK_BASE_LIBRARY_RELEASE
The FLTK base library (optimized)
FLTK_BASE_LIBRARY_DEBUG
The FLTK base library (debug)
FLTK_GL_LIBRARY_RELEASE
The FLTK GL library (optimized)
FLTK_GL_LIBRARY_DEBUG
The FLTK GL library (debug)
FLTK_FORMS_LIBRARY_RELEASE
The FLTK Forms library (optimized)
FLTK_FORMS_LIBRARY_DEBUG
The FLTK Forms library (debug)
FLTK_IMAGES_LIBRARY_RELEASE
The FLTK Images protobuf library (optimized)
FLTK_IMAGES_LIBRARY_DEBUG
The FLTK Images library (debug)

  • cmake-modules(7) »


FindFontconfig — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindFontconfig

Find Fontconfig headers and library.

Imported Targets

Fontconfig::Fontconfig
The Fontconfig library, if found.

Result Variables

This will define the following variables in your project:

FONTCONFIG_FOUND
true if (the requested version of) Fontconfig is available.
FONTCONFIG_VERSION
the version of Fontconfig.
FONTCONFIG_LIBRARIES
the libraries to link against to use Fontconfig.
FONTCONFIG_INCLUDE_DIRS
where to find the Fontconfig headers.
FONTCONFIG_COMPILE_OPTIONS
this should be passed to target_compile_options(), if the target is not used for linking

  • cmake-modules(7) »


FindFreetype — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindFreetype

Find the FreeType font renderer includes and library.

Imported Targets

This module defines the following IMPORTED target:

Freetype::Freetype
The Freetype freetype library, if found

Result Variables

This module will set the following variables in your project:

FREETYPE_FOUND
true if the Freetype headers and libraries were found
FREETYPE_INCLUDE_DIRS

directories containing the Freetype headers. This is the concatenation of the variables:

FREETYPE_INCLUDE_DIR_ft2build
directory holding the main Freetype API configuration header
FREETYPE_INCLUDE_DIR_freetype2
directory holding Freetype public headers
FREETYPE_LIBRARIES
the library to link against
FREETYPE_VERSION_STRING
the version of freetype found (since CMake 2.8.8)

Hints

The user may set the environment variable FREETYPE_DIR to the root directory of a Freetype installation.

  • cmake-modules(7) »


FindGCCXML — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGCCXML

Find the GCC-XML front-end executable.

This module will define the following variables:

GCCXML - the GCC-XML front-end executable.

  • cmake-modules(7) »


FindGDAL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGDAL

Find GDAL.

IMPORTED Targets

This module defines IMPORTED target GDAL::GDAL if GDAL has been found.

Result Variables

This module will set the following variables in your project:

GDAL_FOUND
True if GDAL is found.
GDAL_INCLUDE_DIRS
Include directories for GDAL headers.
GDAL_LIBRARIES
Libraries to link to GDAL.
GDAL_VERSION
The version of GDAL found.

Cache variables

The following cache variables may also be set:

GDAL_LIBRARY
The libgdal library file.
GDAL_INCLUDE_DIR
The directory containing gdal.h.

Hints

Set GDAL_DIR or GDAL_ROOT in the environment to specify the GDAL installation prefix.

  • cmake-modules(7) »


FindGettext — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGettext

Find GNU gettext tools

This module looks for the GNU gettext tools. This module defines the following values:

GETTEXT_MSGMERGE_EXECUTABLE: the full path to the msgmerge tool.
GETTEXT_MSGFMT_EXECUTABLE: the full path to the msgfmt tool.
GETTEXT_FOUND: True if gettext has been found.
GETTEXT_VERSION_STRING: the version of gettext found (since CMake 2.8.8)

Additionally it provides the following macros:

GETTEXT_CREATE_TRANSLATIONS ( outputFile [ALL] file1 … fileN )

This will create a target "translations" which will convert the
given input po files into the binary output mo file. If the
ALL option is used, the translations will also be created when
building the default target.

GETTEXT_PROCESS_POT_FILE( <potfile> [ALL] [INSTALL_DESTINATION <destdir>] LANGUAGES <lang1> <lang2> … )

Process the given pot file to mo files.
If INSTALL_DESTINATION is given then automatically install rules will
be created, the language subdirectory will be taken into account
(by default use share/locale/).
If ALL is specified, the pot file is processed when building the all traget.
It creates a custom target "potfile".

GETTEXT_PROCESS_PO_FILES( <lang> [ALL] [INSTALL_DESTINATION <dir>] PO_FILES <po1> <po2> … )

Process the given po files to mo files for the given language.
If INSTALL_DESTINATION is given then automatically install rules will
be created, the language subdirectory will be taken into account
(by default use share/locale/).
If ALL is specified, the po files are processed when building the all traget.
It creates a custom target "pofiles".

Note

If you wish to use the Gettext library (libintl), use FindIntl.

  • cmake-modules(7) »


FindGIF — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGIF

This finds the GIF library (giflib)

Imported targets

This module defines the following IMPORTED target:

GIF::GIF
The giflib library, if found.

Result variables

This module will set the following variables in your project:

GIF_FOUND
If false, do not try to use GIF.
GIF_INCLUDE_DIRS
where to find gif_lib.h, etc.
GIF_LIBRARIES
the libraries needed to use GIF.
GIF_VERSION
3, 4 or a full version string (eg 5.1.4) for versions >= 4.1.6.

Cache variables

The following cache variables may also be set:

GIF_INCLUDE_DIR
where to find the GIF headers.
GIF_LIBRARY
where to find the GIF library.

Hints

GIF_DIR is an environment variable that would correspond to the ./configure --prefix=$GIF_DIR.

  • cmake-modules(7) »


FindGit — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGit

The module defines the following IMPORTED targets (when CMAKE_ROLE is PROJECT):

Git::Git
Executable of the Git command-line client.

The module defines the following variables:

GIT_EXECUTABLE
Path to Git command-line client.
Git_FOUND, GIT_FOUND
True if the Git command-line client was found.
GIT_VERSION_STRING
The version of Git found.

Example usage:

find_package(Git)
if(Git_FOUND)
  message("Git found: ${GIT_EXECUTABLE}")
endif()

  • cmake-modules(7) »


FindGLEW — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGLEW

Find the OpenGL Extension Wrangler Library (GLEW)

IMPORTED Targets

This module defines the IMPORTED target GLEW::GLEW, if GLEW has been found.

Result Variables

This module defines the following variables:

GLEW_INCLUDE_DIRS - include directories for GLEW
GLEW_LIBRARIES - libraries to link against GLEW
GLEW_FOUND - true if GLEW has been found and can be used

  • cmake-modules(7) »


FindGLUT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGLUT

try to find glut library and include files.

IMPORTED Targets

This module defines the IMPORTED targets:

GLUT::GLUT
Defined if the system has GLUT.

Result Variables

This module sets the following variables:

GLUT_INCLUDE_DIR, where to find GL/glut.h, etc.
GLUT_LIBRARIES, the libraries to link against
GLUT_FOUND, If false, do not try to use GLUT.

Also defined, but not for general use are:

GLUT_glut_LIBRARY = the full path to the glut library.
GLUT_Xmu_LIBRARY  = the full path to the Xmu library.
GLUT_Xi_LIBRARY   = the full path to the Xi Library.

  • cmake-modules(7) »


FindGnuplot — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGnuplot

this module looks for gnuplot

Once done this will define

GNUPLOT_FOUND - system has Gnuplot
GNUPLOT_EXECUTABLE - the Gnuplot executable
GNUPLOT_VERSION_STRING - the version of Gnuplot found (since CMake 2.8.8)

GNUPLOT_VERSION_STRING will not work for old versions like 3.7.1.

  • cmake-modules(7) »


FindGnuTLS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGnuTLS

Try to find the GNU Transport Layer Security library (gnutls)

Once done this will define

GNUTLS_FOUND - System has gnutls
GNUTLS_INCLUDE_DIR - The gnutls include directory
GNUTLS_LIBRARIES - The libraries needed to use gnutls
GNUTLS_DEFINITIONS - Compiler switches required for using gnutls

  • cmake-modules(7) »


FindGSL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGSL

Find the native GSL includes and libraries.

The GNU Scientific Library (GSL) is a numerical library for C and C++ programmers. It is free software under the GNU General Public License.

Imported Targets

If GSL is found, this module defines the following IMPORTED targets:

GSL::gsl      - The main GSL library.
GSL::gslcblas - The CBLAS support library used by GSL.

Result Variables

This module will set the following variables in your project:

GSL_FOUND          - True if GSL found on the local system
GSL_INCLUDE_DIRS   - Location of GSL header files.
GSL_LIBRARIES      - The GSL libraries.
GSL_VERSION        - The version of the discovered GSL install.

Hints

Set GSL_ROOT_DIR to a directory that contains a GSL installation.

This script expects to find libraries at $GSL_ROOT_DIR/lib and the GSL headers at $GSL_ROOT_DIR/include/gsl. The library directory may optionally provide Release and Debug folders. If available, the libraries named gsld, gslblasd or cblasd are recognized as debug libraries. For Unix-like systems, this script will use $GSL_ROOT_DIR/bin/gsl-config (if found) to aid in the discovery of GSL.

Cache Variables

This module may set the following variables depending on platform and type of GSL installation discovered. These variables may optionally be set to help this module find the correct files:

GSL_CBLAS_LIBRARY       - Location of the GSL CBLAS library.
GSL_CBLAS_LIBRARY_DEBUG - Location of the debug GSL CBLAS library (if any).
GSL_CONFIG_EXECUTABLE   - Location of the ``gsl-config`` script (if any).
GSL_LIBRARY             - Location of the GSL library.
GSL_LIBRARY_DEBUG       - Location of the debug GSL library (if any).

  • cmake-modules(7) »


FindGTest — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGTest

Locate the Google C++ Testing Framework.

Imported targets

This module defines the following IMPORTED targets:

GTest::GTest
The Google Test gtest library, if found; adds Thread::Thread automatically
GTest::Main
The Google Test gtest_main library, if found

Result variables

This module will set the following variables in your project:

GTEST_FOUND
Found the Google Testing framework
GTEST_INCLUDE_DIRS
the directory containing the Google Test headers

The library variables below are set as normal variables. These contain debug/optimized keywords when a debugging library is found.

GTEST_LIBRARIES
The Google Test gtest library; note it also requires linking with an appropriate thread library
GTEST_MAIN_LIBRARIES
The Google Test gtest_main library
GTEST_BOTH_LIBRARIES
Both gtest and gtest_main

Cache variables

The following cache variables may also be set:

GTEST_ROOT
The root directory of the Google Test installation (may also be set as an environment variable)
GTEST_MSVC_SEARCH
If compiling with MSVC, this variable can be set to MT or MD (the default) to enable searching a GTest build tree

Example usage

enable_testing()
find_package(GTest REQUIRED)

add_executable(foo foo.cc)
target_link_libraries(foo GTest::GTest GTest::Main)

add_test(AllTestsInFoo foo)

Deeper integration with CTest

See GoogleTest for information on the gtest_add_tests() and gtest_discover_tests() commands.

  • cmake-modules(7) »


FindGTK2 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGTK2

FindGTK2.cmake

This module can find the GTK2 widget libraries and several of its other optional components like gtkmm, glade, and glademm.

NOTE: If you intend to use version checking, CMake 2.6.2 or later is

required.

Specify one or more of the following components as you call this find module. See example below.

gtk
gtkmm
glade
glademm

The following variables will be defined for your use

GTK2_FOUND - Were all of your specified components found?
GTK2_INCLUDE_DIRS - All include directories
GTK2_LIBRARIES - All libraries
GTK2_TARGETS - All imported targets
GTK2_DEFINITIONS - Additional compiler flags

GTK2_VERSION - The version of GTK2 found (x.y.z)
GTK2_MAJOR_VERSION - The major version of GTK2
GTK2_MINOR_VERSION - The minor version of GTK2
GTK2_PATCH_VERSION - The patch version of GTK2

Optional variables you can define prior to calling this module:

GTK2_DEBUG - Enables verbose debugging of the module
GTK2_ADDITIONAL_SUFFIXES - Allows defining additional directories to
                           search for include files

================= Example Usage:

Call find_package() once, here are some examples to pick from:

Require GTK 2.6 or later
    find_package(GTK2 2.6 REQUIRED gtk)

Require GTK 2.10 or later and Glade
    find_package(GTK2 2.10 REQUIRED gtk glade)

Search for GTK/GTKMM 2.8 or later
    find_package(GTK2 2.8 COMPONENTS gtk gtkmm)

if(GTK2_FOUND)
   include_directories(${GTK2_INCLUDE_DIRS})
   add_executable(mygui mygui.cc)
   target_link_libraries(mygui ${GTK2_LIBRARIES})
endif()

  • cmake-modules(7) »


FindGTK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindGTK

try to find GTK (and glib) and GTKGLArea

GTK_INCLUDE_DIR   - Directories to include to use GTK
GTK_LIBRARIES     - Files to link against to use GTK
GTK_FOUND         - GTK was found
GTK_GL_FOUND      - GTK's GL features were found

  • cmake-modules(7) »


FindHDF5 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindHDF5

Find HDF5, a library for reading and writing self describing array data.

This module invokes the HDF5 wrapper compiler that should be installed alongside HDF5. Depending upon the HDF5 Configuration, the wrapper compiler is called either h5cc or h5pcc. If this succeeds, the module will then call the compiler with the -show argument to see what flags are used when compiling an HDF5 client application.

The module will optionally accept the COMPONENTS argument. If no COMPONENTS are specified, then the find module will default to finding only the HDF5 C library. If one or more COMPONENTS are specified, the module will attempt to find the language bindings for the specified components. The only valid components are C, CXX, Fortran, HL, and Fortran_HL. If the COMPONENTS argument is not given, the module will attempt to find only the C bindings.

This module will read the variable HDF5_USE_STATIC_LIBRARIES to determine whether or not to prefer a static link to a dynamic link for HDF5 and all of it’s dependencies. To use this feature, make sure that the HDF5_USE_STATIC_LIBRARIES variable is set before the call to find_package.

To provide the module with a hint about where to find your HDF5 installation, you can set the environment variable HDF5_ROOT. The Find module will then look in this path when searching for HDF5 executables, paths, and libraries.

Both the serial and parallel HDF5 wrappers are considered and the first directory to contain either one will be used. In the event that both appear in the same directory the serial version is preferentially selected. This behavior can be reversed by setting the variable HDF5_PREFER_PARALLEL to true.

In addition to finding the includes and libraries required to compile an HDF5 client application, this module also makes an effort to find tools that come with the HDF5 distribution that may be useful for regression testing.

Result Variables

This module will set the following variables in your project:

HDF5_FOUND
HDF5 was found on the system
HDF5_VERSION
HDF5 library version
HDF5_INCLUDE_DIRS
Location of the HDF5 header files
HDF5_DEFINITIONS
Required compiler definitions for HDF5
HDF5_LIBRARIES
Required libraries for all requested bindings
HDF5_HL_LIBRARIES
Required libraries for the HDF5 high level API for all bindings, if the HL component is enabled

Available components are: C CXX Fortran and HL. For each enabled language binding, a corresponding HDF5_${LANG}_LIBRARIES variable, and potentially HDF5_${LANG}_DEFINITIONS, will be defined. If the HL component is enabled, then an HDF5_${LANG}_HL_LIBRARIES will also be defined. With all components enabled, the following variables will be defined:

HDF5_C_DEFINITIONS
Required compiler definitions for HDF5 C bindings
HDF5_CXX_DEFINITIONS
Required compiler definitions for HDF5 C++ bindings
HDF5_Fortran_DEFINITIONS
Required compiler definitions for HDF5 Fortran bindings
HDF5_C_INCLUDE_DIRS
Required include directories for HDF5 C bindings
HDF5_CXX_INCLUDE_DIRS
Required include directories for HDF5 C++ bindings
HDF5_Fortran_INCLUDE_DIRS
Required include directories for HDF5 Fortran bindings
HDF5_C_LIBRARIES
Required libraries for the HDF5 C bindings
HDF5_CXX_LIBRARIES
Required libraries for the HDF5 C++ bindings
HDF5_Fortran_LIBRARIES
Required libraries for the HDF5 Fortran bindings
HDF5_C_HL_LIBRARIES
Required libraries for the high level C bindings
HDF5_CXX_HL_LIBRARIES
Required libraries for the high level C++ bindings
HDF5_Fortran_HL_LIBRARIES
Required libraries for the high level Fortran bindings.
HDF5_IS_PARALLEL
HDF5 library has parallel IO support
HDF5_C_COMPILER_EXECUTABLE
path to the HDF5 C wrapper compiler
HDF5_CXX_COMPILER_EXECUTABLE
path to the HDF5 C++ wrapper compiler
HDF5_Fortran_COMPILER_EXECUTABLE
path to the HDF5 Fortran wrapper compiler
HDF5_C_COMPILER_EXECUTABLE_NO_INTERROGATE
path to the primary C compiler which is also the HDF5 wrapper
HDF5_CXX_COMPILER_EXECUTABLE_NO_INTERROGATE
path to the primary C++ compiler which is also the HDF5 wrapper
HDF5_Fortran_COMPILER_EXECUTABLE_NO_INTERROGATE
path to the primary Fortran compiler which is also the HDF5 wrapper
HDF5_DIFF_EXECUTABLE
path to the HDF5 dataset comparison tool

Hints

The following variable can be set to guide the search for HDF5 libraries and includes:

HDF5_ROOT
Specify the path to the HDF5 installation to use.
HDF5_FIND_DEBUG
Set true to get extra debugging output.
HDF5_NO_FIND_PACKAGE_CONFIG_FILE
Set true to skip trying to find hdf5-config.cmake.

  • cmake-modules(7) »


FindHg — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindHg

Extract information from a mercurial working copy.

The module defines the following variables:

HG_EXECUTABLE - path to mercurial command line client (hg)
HG_FOUND - true if the command line client was found
HG_VERSION_STRING - the version of mercurial found

If the command line client executable is found the following macro is defined:

HG_WC_INFO(<dir> <var-prefix>)

Hg_WC_INFO extracts information of a mercurial working copy at a given location. This macro defines the following variables:

<var-prefix>_WC_CHANGESET - current changeset
<var-prefix>_WC_REVISION - current revision

Example usage:

find_package(Hg)
if(HG_FOUND)
  message("hg found: ${HG_EXECUTABLE}")
  HG_WC_INFO(${PROJECT_SOURCE_DIR} Project)
  message("Current revision is ${Project_WC_REVISION}")
  message("Current changeset is ${Project_WC_CHANGESET}")
endif()

  • cmake-modules(7) »


FindHSPELL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindHSPELL

Try to find Hspell

Once done this will define

HSPELL_FOUND - system has Hspell
HSPELL_INCLUDE_DIR - the Hspell include directory
HSPELL_LIBRARIES - The libraries needed to use Hspell
HSPELL_DEFINITIONS - Compiler switches required for using Hspell

HSPELL_VERSION_STRING - The version of Hspell found (x.y)
HSPELL_MAJOR_VERSION  - the major version of Hspell
HSPELL_MINOR_VERSION  - The minor version of Hspell

  • cmake-modules(7) »


FindHTMLHelp — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindHTMLHelp

This module looks for Microsoft HTML Help Compiler

It defines:

HTML_HELP_COMPILER     : full path to the Compiler (hhc.exe)
HTML_HELP_INCLUDE_PATH : include path to the API (htmlhelp.h)
HTML_HELP_LIBRARY      : full path to the library (htmlhelp.lib)

  • cmake-modules(7) »


FindIce — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindIce

Find the ZeroC Internet Communication Engine (ICE) programs, libraries and datafiles.

This module supports multiple components. Components can include any of: Freeze, Glacier2, Ice, IceBox, IceDB, IceDiscovery, IceGrid, IceLocatorDiscovery, IcePatch, IceSSL, IceStorm, IceUtil, IceXML, or Slice.

Ice 3.7 and later also include C++11-specific components: Glacier2++11, Ice++11, IceBox++11, IceDiscovery++11 IceGrid, IceLocatorDiscovery++11, IceSSL++11, IceStorm++11

Note that the set of supported components is Ice version-specific.

This module reports information about the Ice installation in several variables. General variables:

Ice_VERSION - Ice release version
Ice_FOUND - true if the main programs and libraries were found
Ice_LIBRARIES - component libraries to be linked
Ice_INCLUDE_DIRS - the directories containing the Ice headers
Ice_SLICE_DIRS - the directories containing the Ice slice interface
                 definitions

Imported targets:

Ice::<C>

Where <C> is the name of an Ice component, for example Ice::Glacier2 or Ice++11.

Ice slice programs are reported in:

Ice_SLICE2CONFLUENCE_EXECUTABLE - path to slice2confluence executable
Ice_SLICE2CPP_EXECUTABLE - path to slice2cpp executable
Ice_SLICE2CS_EXECUTABLE - path to slice2cs executable
Ice_SLICE2FREEZEJ_EXECUTABLE - path to slice2freezej executable
Ice_SLICE2FREEZE_EXECUTABLE - path to slice2freeze executable
Ice_SLICE2HTML_EXECUTABLE - path to slice2html executable
Ice_SLICE2JAVA_EXECUTABLE - path to slice2java executable
Ice_SLICE2JS_EXECUTABLE - path to slice2js executable
Ice_SLICE2MATLAB_EXECUTABLE - path to slice2matlab executable
Ice_SLICE2OBJC_EXECUTABLE - path to slice2objc executable
Ice_SLICE2PHP_EXECUTABLE - path to slice2php executable
Ice_SLICE2PY_EXECUTABLE - path to slice2py executable
Ice_SLICE2RB_EXECUTABLE - path to slice2rb executable

Ice programs are reported in:

Ice_GLACIER2ROUTER_EXECUTABLE - path to glacier2router executable
Ice_ICEBOX_EXECUTABLE - path to icebox executable
Ice_ICEBOXXX11_EXECUTABLE - path to icebox++11 executable
Ice_ICEBOXADMIN_EXECUTABLE - path to iceboxadmin executable
Ice_ICEBOXD_EXECUTABLE - path to iceboxd executable
Ice_ICEBOXNET_EXECUTABLE - path to iceboxnet executable
Ice_ICEBRIDGE_EXECUTABLE - path to icebridge executable
Ice_ICEGRIDADMIN_EXECUTABLE - path to icegridadmin executable
Ice_ICEGRIDDB_EXECUTABLE - path to icegriddb executable
Ice_ICEGRIDNODE_EXECUTABLE - path to icegridnode executable
Ice_ICEGRIDNODED_EXECUTABLE - path to icegridnoded executable
Ice_ICEGRIDREGISTRY_EXECUTABLE - path to icegridregistry executable
Ice_ICEGRIDREGISTRYD_EXECUTABLE - path to icegridregistryd executable
Ice_ICEPATCH2CALC_EXECUTABLE - path to icepatch2calc executable
Ice_ICEPATCH2CLIENT_EXECUTABLE - path to icepatch2client executable
Ice_ICEPATCH2SERVER_EXECUTABLE - path to icepatch2server executable
Ice_ICESERVICEINSTALL_EXECUTABLE - path to iceserviceinstall executable
Ice_ICESTORMADMIN_EXECUTABLE - path to icestormadmin executable
Ice_ICESTORMDB_EXECUTABLE - path to icestormdb executable
Ice_ICESTORMMIGRATE_EXECUTABLE - path to icestormmigrate executable

Ice db programs (Windows only; standard system versions on all other platforms) are reported in:

Ice_DB_ARCHIVE_EXECUTABLE - path to db_archive executable
Ice_DB_CHECKPOINT_EXECUTABLE - path to db_checkpoint executable
Ice_DB_DEADLOCK_EXECUTABLE - path to db_deadlock executable
Ice_DB_DUMP_EXECUTABLE - path to db_dump executable
Ice_DB_HOTBACKUP_EXECUTABLE - path to db_hotbackup executable
Ice_DB_LOAD_EXECUTABLE - path to db_load executable
Ice_DB_LOG_VERIFY_EXECUTABLE - path to db_log_verify executable
Ice_DB_PRINTLOG_EXECUTABLE - path to db_printlog executable
Ice_DB_RECOVER_EXECUTABLE - path to db_recover executable
Ice_DB_STAT_EXECUTABLE - path to db_stat executable
Ice_DB_TUNER_EXECUTABLE - path to db_tuner executable
Ice_DB_UPGRADE_EXECUTABLE - path to db_upgrade executable
Ice_DB_VERIFY_EXECUTABLE - path to db_verify executable
Ice_DUMPDB_EXECUTABLE - path to dumpdb executable
Ice_TRANSFORMDB_EXECUTABLE - path to transformdb executable

Ice component libraries are reported in:

Ice_<C>_FOUND - ON if component was found
Ice_<C>_LIBRARIES - libraries for component

Note that <C> is the uppercased name of the component.

This module reads hints about search results from:

Ice_HOME - the root of the Ice installation

The environment variable ICE_HOME may also be used; the Ice_HOME variable takes precedence.

Note

On Windows, Ice 3.7.0 and later provide libraries via the NuGet package manager. Appropriate NuGet packages will be searched for using CMAKE_PREFIX_PATH, or alternatively Ice_HOME may be set to the location of a specific NuGet package to restrict the search.

The following cache variables may also be set:

Ice_<P>_EXECUTABLE - the path to executable <P>
Ice_INCLUDE_DIR - the directory containing the Ice headers
Ice_SLICE_DIR - the directory containing the Ice slice interface
                definitions
Ice_<C>_LIBRARY - the library for component <C>

Note

In most cases none of the above variables will require setting, unless multiple Ice versions are available and a specific version is required. On Windows, the most recent version of Ice will be found through the registry. On Unix, the programs, headers and libraries will usually be in standard locations, but Ice_SLICE_DIRS might not be automatically detected (commonly known locations are searched). All the other variables are defaulted using Ice_HOME, if set. It’s possible to set Ice_HOME and selectively specify alternative locations for the other components; this might be required for e.g. newer versions of Visual Studio if the heuristics are not sufficient to identify the correct programs and libraries for the specific Visual Studio version.

Other variables one may set to control this module are:

Ice_DEBUG - Set to ON to enable debug output from FindIce.

  • cmake-modules(7) »


FindIcotool — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindIcotool

Find icotool

This module looks for icotool. This module defines the following values:

ICOTOOL_EXECUTABLE: the full path to the icotool tool.
ICOTOOL_FOUND: True if icotool has been found.
ICOTOOL_VERSION_STRING: the version of icotool found.

  • cmake-modules(7) »


FindICU — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindICU

Find the International Components for Unicode (ICU) libraries and programs.

This module supports multiple components. Components can include any of: data, i18n, io, le, lx, test, tu and uc.

Note that on Windows data is named dt and i18n is named in; any of the names may be used, and the appropriate platform-specific library name will be automatically selected.

This module reports information about the ICU installation in several variables. General variables:

ICU_VERSION - ICU release version
ICU_FOUND - true if the main programs and libraries were found
ICU_LIBRARIES - component libraries to be linked
ICU_INCLUDE_DIRS - the directories containing the ICU headers

Imported targets:

ICU::<C>

Where <C> is the name of an ICU component, for example ICU::i18n.

ICU programs are reported in:

ICU_GENCNVAL_EXECUTABLE - path to gencnval executable
ICU_ICUINFO_EXECUTABLE - path to icuinfo executable
ICU_GENBRK_EXECUTABLE - path to genbrk executable
ICU_ICU-CONFIG_EXECUTABLE - path to icu-config executable
ICU_GENRB_EXECUTABLE - path to genrb executable
ICU_GENDICT_EXECUTABLE - path to gendict executable
ICU_DERB_EXECUTABLE - path to derb executable
ICU_PKGDATA_EXECUTABLE - path to pkgdata executable
ICU_UCONV_EXECUTABLE - path to uconv executable
ICU_GENCFU_EXECUTABLE - path to gencfu executable
ICU_MAKECONV_EXECUTABLE - path to makeconv executable
ICU_GENNORM2_EXECUTABLE - path to gennorm2 executable
ICU_GENCCODE_EXECUTABLE - path to genccode executable
ICU_GENSPREP_EXECUTABLE - path to gensprep executable
ICU_ICUPKG_EXECUTABLE - path to icupkg executable
ICU_GENCMN_EXECUTABLE - path to gencmn executable

ICU component libraries are reported in:

ICU_<C>_FOUND - ON if component was found
ICU_<C>_LIBRARIES - libraries for component

ICU datafiles are reported in:

ICU_MAKEFILE_INC - Makefile.inc
ICU_PKGDATA_INC - pkgdata.inc

Note that <C> is the uppercased name of the component.

This module reads hints about search results from:

ICU_ROOT - the root of the ICU installation

The environment variable ICU_ROOT may also be used; the ICU_ROOT variable takes precedence.

The following cache variables may also be set:

ICU_<P>_EXECUTABLE - the path to executable <P>
ICU_INCLUDE_DIR - the directory containing the ICU headers
ICU_<C>_LIBRARY - the library for component <C>

Note

In most cases none of the above variables will require setting, unless multiple ICU versions are available and a specific version is required.

Other variables one may set to control this module are:

ICU_DEBUG - Set to ON to enable debug output from FindICU.

  • cmake-modules(7) »


FindImageMagick — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindImageMagick

Find the ImageMagick binary suite.

This module will search for a set of ImageMagick tools specified as components in the FIND_PACKAGE call. Typical components include, but are not limited to (future versions of ImageMagick might have additional components not listed here):

animate
compare
composite
conjure
convert
display
identify
import
mogrify
montage
stream

If no component is specified in the FIND_PACKAGE call, then it only searches for the ImageMagick executable directory. This code defines the following variables:

ImageMagick_FOUND                  - TRUE if all components are found.
ImageMagick_EXECUTABLE_DIR         - Full path to executables directory.
ImageMagick_<component>_FOUND      - TRUE if <component> is found.
ImageMagick_<component>_EXECUTABLE - Full path to <component> executable.
ImageMagick_VERSION_STRING         - the version of ImageMagick found
                                     (since CMake 2.8.8)

ImageMagick_VERSION_STRING will not work for old versions like 5.2.3.

There are also components for the following ImageMagick APIs:

Magick++
MagickWand
MagickCore

For these components the following variables are set:

ImageMagick_FOUND                    - TRUE if all components are found.
ImageMagick_INCLUDE_DIRS             - Full paths to all include dirs.
ImageMagick_LIBRARIES                - Full paths to all libraries.
ImageMagick_<component>_FOUND        - TRUE if <component> is found.
ImageMagick_<component>_INCLUDE_DIRS - Full path to <component> include dirs.
ImageMagick_<component>_LIBRARIES    - Full path to <component> libraries.

Example Usages:

find_package(ImageMagick)
find_package(ImageMagick COMPONENTS convert)
find_package(ImageMagick COMPONENTS convert mogrify display)
find_package(ImageMagick COMPONENTS Magick++)
find_package(ImageMagick COMPONENTS Magick++ convert)

Note that the standard FIND_PACKAGE features are supported (i.e., QUIET, REQUIRED, etc.).

  • cmake-modules(7) »


FindIconv — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindIconv

This module finds the iconv() POSIX.1 functions on the system. These functions might be provided in the regular C library or externally in the form of an additional library.

The following variables are provided to indicate iconv support:

Iconv_FOUND

Variable indicating if the iconv support was found.

Iconv_INCLUDE_DIRS

The directories containing the iconv headers.

Iconv_LIBRARIES

The iconv libraries to be linked.

Iconv_IS_BUILT_IN

A variable indicating whether iconv support is stemming from the C library or not. Even if the C library provides iconv(), the presence of an external libiconv implementation might lead to this being false.

Additionally, the following IMPORTED target is being provided:

Iconv::Iconv

Imported target for using iconv.

The following cache variables may also be set:

Iconv_INCLUDE_DIR

The directory containing the iconv headers.

Iconv_LIBRARY

The iconv library (if not implicitly given in the C library).

Note

On POSIX platforms, iconv might be part of the C library and the cache variables Iconv_INCLUDE_DIR and Iconv_LIBRARY might be empty.

  • cmake-modules(7) »


FindIntl — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindIntl

Find the Gettext libintl headers and libraries.

This module reports information about the Gettext libintl installation in several variables. General variables:

Intl_FOUND - true if the libintl headers and libraries were found
Intl_INCLUDE_DIRS - the directory containing the libintl headers
Intl_LIBRARIES - libintl libraries to be linked

The following cache variables may also be set:

Intl_INCLUDE_DIR - the directory containing the libintl headers
Intl_LIBRARY - the libintl library (if any)

Note

On some platforms, such as Linux with GNU libc, the gettext functions are present in the C standard library and libintl is not required. Intl_LIBRARIES will be empty in this case.

Note

If you wish to use the Gettext tools (msgmerge, msgfmt, etc.), use FindGettext.

  • cmake-modules(7) »


FindITK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindITK

This module no longer exists.

This module existed in versions of CMake prior to 3.1, but became only a thin wrapper around find_package(ITK NO_MODULE) to provide compatibility for projects using long-outdated conventions. Now find_package(ITK) will search for ITKConfig.cmake directly.

  • cmake-modules(7) »


FindJasper — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindJasper

Try to find the Jasper JPEG2000 library

Once done this will define

JASPER_FOUND - system has Jasper
JASPER_INCLUDE_DIR - the Jasper include directory
JASPER_LIBRARIES - the libraries needed to use Jasper
JASPER_VERSION_STRING - the version of Jasper found (since CMake 2.8.8)

  • cmake-modules(7) »


FindJava — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindJava

Find Java

This module finds if Java is installed and determines where the include files and libraries are. The caller may set variable JAVA_HOME to specify a Java installation prefix explicitly.

See also the FindJNI module to find Java Native Interface (JNI).

Specify one or more of the following components as you call this find module. See example below.

Runtime     = Java Runtime Environment used to execute Java byte-compiled applications
Development = Development tools (java, javac, javah, jar and javadoc), includes Runtime component
IdlJ        = Interface Description Language (IDL) to Java compiler
JarSigner   = Signer and verifier tool for Java Archive (JAR) files

This module sets the following result variables:

Java_JAVA_EXECUTABLE      = the full path to the Java runtime
Java_JAVAC_EXECUTABLE     = the full path to the Java compiler
Java_JAVAH_EXECUTABLE     = the full path to the Java header generator
Java_JAVADOC_EXECUTABLE   = the full path to the Java documentation generator
Java_IDLJ_EXECUTABLE      = the full path to the Java idl compiler
Java_JAR_EXECUTABLE       = the full path to the Java archiver
Java_JARSIGNER_EXECUTABLE = the full path to the Java jar signer
Java_VERSION_STRING       = Version of java found, eg. 1.6.0_12
Java_VERSION_MAJOR        = The major version of the package found.
Java_VERSION_MINOR        = The minor version of the package found.
Java_VERSION_PATCH        = The patch version of the package found.
Java_VERSION_TWEAK        = The tweak version of the package found (after '_')
Java_VERSION              = This is set to: $major[.$minor[.$patch[.$tweak]]]

The minimum required version of Java can be specified using the find_package() syntax, e.g.

find_package(Java 1.8)

NOTE: ${Java_VERSION} and ${Java_VERSION_STRING} are not guaranteed to be identical. For example some java version may return: Java_VERSION_STRING = 1.8.0_17 and Java_VERSION = 1.8.0.17

another example is the Java OEM, with: Java_VERSION_STRING = 1.8.0-oem and Java_VERSION = 1.8.0

For these components the following variables are set:

Java_FOUND                    - TRUE if all components are found.
Java_<component>_FOUND        - TRUE if <component> is found.

Example Usages:

find_package(Java)
find_package(Java 1.8 REQUIRED)
find_package(Java COMPONENTS Runtime)
find_package(Java COMPONENTS Development)

  • cmake-modules(7) »


FindJNI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindJNI

Find Java Native Interface (JNI) libraries.

JNI enables Java code running in a Java Virtual Machine (JVM) to call and be called by native applications and libraries written in other languages such as C, C++.

This module finds if Java is installed and determines where the include files and libraries are. It also determines what the name of the library is. The caller may set variable JAVA_HOME to specify a Java installation prefix explicitly.

Result Variables

This module sets the following result variables:

JNI_INCLUDE_DIRS
the include dirs to use
JNI_LIBRARIES
the libraries to use (JAWT and JVM)
JNI_FOUND
TRUE if JNI headers and libraries were found.

Cache Variables

The following cache variables are also available to set or use:

JAVA_AWT_LIBRARY
the path to the Java AWT Native Interface (JAWT) library
JAVA_JVM_LIBRARY
the path to the Java Virtual Machine (JVM) library
JAVA_INCLUDE_PATH
the include path to jni.h
JAVA_INCLUDE_PATH2
the include path to jni_md.h and jniport.h
JAVA_AWT_INCLUDE_PATH
the include path to jawt.h

  • cmake-modules(7) »


FindJPEG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindJPEG

Find the JPEG library (libjpeg)

Imported targets

This module defines the following IMPORTED targets:

JPEG::JPEG
The JPEG library, if found.

Result variables

This module will set the following variables in your project:

JPEG_FOUND
If false, do not try to use JPEG.
JPEG_INCLUDE_DIRS
where to find jpeglib.h, etc.
JPEG_LIBRARIES
the libraries needed to use JPEG.
JPEG_VERSION
the version of the JPEG library found

Cache variables

The following cache variables may also be set:

JPEG_INCLUDE_DIRS
where to find jpeglib.h, etc.
JPEG_LIBRARY_RELEASE
where to find the JPEG library (optimized).
JPEG_LIBRARY_DEBUG
where to find the JPEG library (debug).

Obsolete variables

JPEG_INCLUDE_DIR
where to find jpeglib.h, etc. (same as JPEG_INCLUDE_DIRS)
JPEG_LIBRARY
where to find the JPEG library.

  • cmake-modules(7) »


FindKDE3 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindKDE3

Find the KDE3 include and library dirs, KDE preprocessors and define a some macros

This module defines the following variables:

KDE3_DEFINITIONS
compiler definitions required for compiling KDE software
KDE3_INCLUDE_DIR
the KDE include directory
KDE3_INCLUDE_DIRS
the KDE and the Qt include directory, for use with include_directories()
KDE3_LIB_DIR
the directory where the KDE libraries are installed, for use with link_directories()
QT_AND_KDECORE_LIBS
this contains both the Qt and the kdecore library
KDE3_DCOPIDL_EXECUTABLE
the dcopidl executable
KDE3_DCOPIDL2CPP_EXECUTABLE
the dcopidl2cpp executable
KDE3_KCFGC_EXECUTABLE
the kconfig_compiler executable
KDE3_FOUND
set to TRUE if all of the above has been found

The following user adjustable options are provided:

KDE3_BUILD_TESTS
enable this to build KDE testcases

It also adds the following macros (from KDE3Macros.cmake) SRCS_VAR is always the variable which contains the list of source files for your application or library.

KDE3_AUTOMOC(file1 … fileN)

Call this if you want to have automatic moc file handling.
This means if you include "foo.moc" in the source file foo.cpp
a moc file for the header foo.h will be created automatically.
You can set the property SKIP_AUTOMAKE using set_source_files_properties()
to exclude some files in the list from being processed.

KDE3_ADD_MOC_FILES(SRCS_VAR file1 … fileN )

If you don't use the KDE3_AUTOMOC() macro, for the files
listed here moc files will be created (named "foo.moc.cpp")

KDE3_ADD_DCOP_SKELS(SRCS_VAR header1.h … headerN.h )

Use this to generate DCOP skeletions from the listed headers.

KDE3_ADD_DCOP_STUBS(SRCS_VAR header1.h … headerN.h )

Use this to generate DCOP stubs from the listed headers.

KDE3_ADD_UI_FILES(SRCS_VAR file1.ui … fileN.ui )

Use this to add the Qt designer ui files to your application/library.

KDE3_ADD_KCFG_FILES(SRCS_VAR file1.kcfgc … fileN.kcfgc )

Use this to add KDE kconfig compiler files to your application/library.

KDE3_INSTALL_LIBTOOL_FILE(target)

This will create and install a simple libtool file for the given target.

KDE3_ADD_EXECUTABLE(name file1 … fileN )

Currently identical to add_executable(), may provide some advanced
features in the future.

KDE3_ADD_KPART(name [WITH_PREFIX] file1 … fileN )

Create a KDE plugin (KPart, kioslave, etc.) from the given source files.
If WITH_PREFIX is given, the resulting plugin will have the prefix "lib",
otherwise it won't.
It creates and installs an appropriate libtool la-file.

KDE3_ADD_KDEINIT_EXECUTABLE(name file1 … fileN )

Create a KDE application in the form of a module loadable via kdeinit.
A library named kdeinit_<name> will be created and a small executable
which links to it.

The option KDE3_ENABLE_FINAL to enable all-in-one compilation is no longer supported.

Author: Alexander Neundorf <neundorf@kde.org>

  • cmake-modules(7) »


FindKDE4 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindKDE4

Find KDE4 and provide all necessary variables and macros to compile software for it. It looks for KDE 4 in the following directories in the given order:

CMAKE_INSTALL_PREFIX
KDEDIRS
/opt/kde4

Please look in FindKDE4Internal.cmake and KDE4Macros.cmake for more information. They are installed with the KDE 4 libraries in $KDEDIRS/share/apps/cmake/modules/.

Author: Alexander Neundorf <neundorf@kde.org>

  • cmake-modules(7) »


FindLAPACK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLAPACK

Find LAPACK library

This module finds an installed fortran library that implements the LAPACK linear-algebra interface (see http://www.netlib.org/lapack/).

The approach follows that taken for the autoconf macro file, acx_lapack.m4 (distributed at http://ac-archive.sourceforge.net/ac-archive/acx_lapack.html).

Input Variables

The following variables may be set to influence this module’s behavior:

BLA_STATIC
if ON use static linkage
BLA_VENDOR

If set, checks only the specified vendor, if not set checks all the possibilities. List of vendors valid in this module:

  • Intel10_32 (intel mkl v10 32 bit)
  • Intel10_64lp (intel mkl v10+ 64 bit, threaded code, lp64 model)
  • Intel10_64lp_seq (intel mkl v10+ 64 bit, sequential code, lp64 model)
  • Intel10_64ilp (intel mkl v10+ 64 bit, threaded code, ilp64 model)
  • Intel10_64ilp_seq (intel mkl v10+ 64 bit, sequential code, ilp64 model)
  • Intel (obsolete versions of mkl 32 and 64 bit)
  • OpenBLAS
  • FLAME
  • ACML
  • Apple
  • NAS
  • Generic
BLA_F95
if ON tries to find BLAS95/LAPACK95

Result Variables

This module defines the following variables:

LAPACK_FOUND
library implementing the LAPACK interface is found
LAPACK_LINKER_FLAGS
uncached list of required linker flags (excluding -l and -L).
LAPACK_LIBRARIES
uncached list of libraries (using full path name) to link against to use LAPACK
LAPACK95_LIBRARIES
uncached list of libraries (using full path name) to link against to use LAPACK95
LAPACK95_FOUND
library implementing the LAPACK95 interface is found

Note

C or CXX must be enabled to use Intel MKL

For example, to use Intel MKL libraries and/or Intel compiler:

set(BLA_VENDOR Intel10_64lp)
find_package(LAPACK)

  • cmake-modules(7) »


FindLATEX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLATEX

Find Latex

This module finds an installed Latex and determines the location of the compiler. Additionally the module looks for Latex-related software like BibTeX.

This module sets the following result variables:

LATEX_FOUND:          whether found Latex and requested components
LATEX_<component>_FOUND:  whether found <component>
LATEX_COMPILER:       path to the LaTeX compiler
PDFLATEX_COMPILER:    path to the PdfLaTeX compiler
XELATEX_COMPILER:     path to the XeLaTeX compiler
LUALATEX_COMPILER:    path to the LuaLaTeX compiler
BIBTEX_COMPILER:      path to the BibTeX compiler
BIBER_COMPILER:       path to the Biber compiler
MAKEINDEX_COMPILER:   path to the MakeIndex compiler
XINDY_COMPILER:       path to the xindy compiler
DVIPS_CONVERTER:      path to the DVIPS converter
DVIPDF_CONVERTER:     path to the DVIPDF converter
PS2PDF_CONVERTER:     path to the PS2PDF converter
PDFTOPS_CONVERTER:    path to the pdftops converter
LATEX2HTML_CONVERTER: path to the LaTeX2Html converter
HTLATEX_COMPILER:     path to the htlatex compiler

Possible components are:

PDFLATEX
XELATEX
LUALATEX
BIBTEX
BIBER
MAKEINDEX
XINDY
DVIPS
DVIPDF
PS2PDF
PDFTOPS
LATEX2HTML
HTLATEX

Example Usages:

find_package(LATEX)
find_package(LATEX COMPONENTS PDFLATEX)
find_package(LATEX COMPONENTS BIBTEX PS2PDF)

  • cmake-modules(7) »


FindLibArchive — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLibArchive

Find libarchive library and headers

The module defines the following variables:

LibArchive_FOUND        - true if libarchive was found
LibArchive_INCLUDE_DIRS - include search path
LibArchive_LIBRARIES    - libraries to link
LibArchive_VERSION      - libarchive 3-component version number

  • cmake-modules(7) »


FindLibinput — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLibinput

Find libinput headers and library.

Imported Targets

Libinput::Libinput
The libinput library, if found.

Result Variables

This will define the following variables in your project:

Libinput_FOUND
true if (the requested version of) libinput is available.
Libinput_VERSION
the version of libinput.
Libinput_LIBRARIES
the libraries to link against to use libinput.
Libinput_INCLUDE_DIRS
where to find the libinput headers.
Libinput_COMPILE_OPTIONS
this should be passed to target_compile_options(), if the target is not used for linking

  • cmake-modules(7) »


FindLibLZMA — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLibLZMA

Find LZMA compression algorithm headers and library.

Imported Targets

This module defines IMPORTED target LibLZMA::LibLZMA, if liblzma has been found.

Result variables

This module will set the following variables in your project:

LIBLZMA_FOUND
True if liblzma headers and library were found.
LIBLZMA_INCLUDE_DIRS
Directory where liblzma headers are located.
LIBLZMA_LIBRARIES
Lzma libraries to link against.
LIBLZMA_HAS_AUTO_DECODER
True if lzma_auto_decoder() is found (required).
LIBLZMA_HAS_EASY_ENCODER
True if lzma_easy_encoder() is found (required).
LIBLZMA_HAS_LZMA_PRESET
True if lzma_lzma_preset() is found (required).
LIBLZMA_VERSION_MAJOR
The major version of lzma
LIBLZMA_VERSION_MINOR
The minor version of lzma
LIBLZMA_VERSION_PATCH
The patch version of lzma
LIBLZMA_VERSION_STRING
version number as a string (ex: “5.0.3”)

  • cmake-modules(7) »


FindLibXml2 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLibXml2

Find the XML processing library (libxml2).

IMPORTED Targets

This module defines IMPORTED target LibXml2::LibXml2, if libxml2 has been found.

Result variables

This module will set the following variables in your project:

LibXml2_FOUND
true if libxml2 headers and libraries were found
LIBXML2_INCLUDE_DIR
the directory containing LibXml2 headers
LIBXML2_INCLUDE_DIRS
list of the include directories needed to use LibXml2
LIBXML2_LIBRARIES
LibXml2 libraries to be linked
LIBXML2_DEFINITIONS
the compiler switches required for using LibXml2
LIBXML2_XMLLINT_EXECUTABLE
path to the XML checking tool xmllint coming with LibXml2
LIBXML2_VERSION_STRING
the version of LibXml2 found (since CMake 2.8.8)

Cache variables

The following cache variables may also be set:

LIBXML2_INCLUDE_DIR
the directory containing LibXml2 headers
LIBXML2_LIBRARY
path to the LibXml2 library

  • cmake-modules(7) »


FindLibXslt — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLibXslt

Try to find the LibXslt library

Once done this will define

LIBXSLT_FOUND - system has LibXslt
LIBXSLT_INCLUDE_DIR - the LibXslt include directory
LIBXSLT_LIBRARIES - Link these to LibXslt
LIBXSLT_DEFINITIONS - Compiler switches required for using LibXslt
LIBXSLT_VERSION_STRING - version of LibXslt found (since CMake 2.8.8)

Additionally, the following two variables are set (but not required for using xslt):

LIBXSLT_EXSLT_LIBRARIES
Link to these if you need to link against the exslt library.
LIBXSLT_XSLTPROC_EXECUTABLE
Contains the full path to the xsltproc executable if found.

  • cmake-modules(7) »


FindLTTngUST — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLTTngUST

This module finds the LTTng-UST library.

Imported target

This module defines the following IMPORTED target:

LTTng::UST
The LTTng-UST library, if found

Result variables

This module sets the following

LTTNGUST_FOUND
TRUE if system has LTTng-UST
LTTNGUST_INCLUDE_DIRS
The LTTng-UST include directories
LTTNGUST_LIBRARIES
The libraries needed to use LTTng-UST
LTTNGUST_VERSION_STRING
The LTTng-UST version
LTTNGUST_HAS_TRACEF
TRUE if the tracef() API is available in the system’s LTTng-UST
LTTNGUST_HAS_TRACELOG
TRUE if the tracelog() API is available in the system’s LTTng-UST

  • cmake-modules(7) »


FindLua50 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLua50

Locate Lua library This module defines

LUA50_FOUND, if false, do not try to link to Lua
LUA_LIBRARIES, both lua and lualib
LUA_INCLUDE_DIR, where to find lua.h and lualib.h (and probably lauxlib.h)

Note that the expected include convention is

#include "lua.h"

and not

#include <lua/lua.h>

This is because, the lua location is not standardized and may exist in locations other than lua/

  • cmake-modules(7) »


FindLua51 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLua51

Locate Lua library This module defines

LUA51_FOUND, if false, do not try to link to Lua
LUA_LIBRARIES
LUA_INCLUDE_DIR, where to find lua.h
LUA_VERSION_STRING, the version of Lua found (since CMake 2.8.8)

Note that the expected include convention is

#include "lua.h"

and not

#include <lua/lua.h>

This is because, the lua location is not standardized and may exist in locations other than lua/

  • cmake-modules(7) »


FindLua — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindLua

Locate Lua library This module defines

LUA_FOUND          - if false, do not try to link to Lua
LUA_LIBRARIES      - both lua and lualib
LUA_INCLUDE_DIR    - where to find lua.h
LUA_VERSION_STRING - the version of Lua found
LUA_VERSION_MAJOR  - the major version of Lua
LUA_VERSION_MINOR  - the minor version of Lua
LUA_VERSION_PATCH  - the patch version of Lua

Note that the expected include convention is

#include "lua.h"

and not

#include <lua/lua.h>

This is because, the lua location is not standardized and may exist in locations other than lua/

  • cmake-modules(7) »


FindMatlab — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindMatlab

Finds Matlab or Matlab Compiler Runtime (MCR) and provides Matlab tools, libraries and compilers to CMake.

This package primary purpose is to find the libraries associated with Matlab or the MCR in order to be able to build Matlab extensions (mex files). It can also be used:

  • to run specific commands in Matlab in case Matlab is available
  • for declaring Matlab unit test
  • to retrieve various information from Matlab (mex extensions, versions and release queries, …)

The module supports the following components:

  • ENG_LIBRARY and MAT_LIBRARY: respectively the ENG and MAT libraries of Matlab
  • MAIN_PROGRAM the Matlab binary program. Note that this component is not available on the MCR version, and will yield an error if the MCR is found instead of the regular Matlab installation.
  • MEX_COMPILER the MEX compiler.
  • MCC_COMPILER the MCC compiler, included with the Matlab Compiler add-on.
  • SIMULINK the Simulink environment.

Note

The version given to the find_package() directive is the Matlab version, which should not be confused with the Matlab release name (eg. R2014). The matlab_get_version_from_release_name() and matlab_get_release_name_from_version() provide a mapping between the release name and the version.

The variable Matlab_ROOT_DIR may be specified in order to give the path of the desired Matlab version. Otherwise, the behaviour is platform specific:

  • Windows: The installed versions of Matlab/MCR are retrieved from the Windows registry
  • OS X: The installed versions of Matlab/MCR are given by the MATLAB default installation paths in /Application. If no such application is found, it falls back to the one that might be accessible from the PATH.
  • Unix: The desired Matlab should be accessible from the PATH. This does not work for MCR installation and Matlab_ROOT_DIR should be specified on this platform.

Additional information is provided when MATLAB_FIND_DEBUG is set. When a Matlab/MCR installation is found automatically and the MATLAB_VERSION is not given, the version is queried from Matlab directly (on Windows this may pop up a Matlab window) or from the MCR installation.

The mapping of the release names and the version of Matlab is performed by defining pairs (name, version). The variable MATLAB_ADDITIONAL_VERSIONS may be provided before the call to the find_package() in order to handle additional versions.

A Matlab scripts can be added to the set of tests using the matlab_add_unit_test(). By default, the Matlab unit test framework will be used (>= 2013a) to run this script, but regular .m files returning an exit code can be used as well (0 indicating a success).

Module Input Variables

Users or projects may set the following variables to configure the module behaviour:

Matlab_ROOT_DIR
the root of the Matlab installation.
MATLAB_FIND_DEBUG
outputs debug information
MATLAB_ADDITIONAL_VERSIONS
additional versions of Matlab for the automatic retrieval of the installed versions.

Variables defined by the module

Result variables

Matlab_FOUND
TRUE if the Matlab installation is found, FALSE otherwise. All variable below are defined if Matlab is found.
Matlab_ROOT_DIR
the final root of the Matlab installation determined by the FindMatlab module.
Matlab_MAIN_PROGRAM
the Matlab binary program. Available only if the component MAIN_PROGRAM is given in the find_package() directive.
Matlab_INCLUDE_DIRS
the path of the Matlab libraries headers
Matlab_MEX_LIBRARY
library for mex, always available.
Matlab_MX_LIBRARY
mx library of Matlab (arrays), always available.
Matlab_ENG_LIBRARY
Matlab engine library. Available only if the component ENG_LIBRARY is requested.
Matlab_MAT_LIBRARY
Matlab matrix library. Available only if the component MAT_LIBRARY is requested.
Matlab_ENGINE_LIBRARY
Matlab C++ engine library, always available for R2018a and newer.
Matlab_DATAARRAY_LIBRARY
Matlab C++ data array library, always available for R2018a and newer.
Matlab_LIBRARIES
the whole set of libraries of Matlab
Matlab_MEX_COMPILER
the mex compiler of Matlab. Currently not used. Available only if the component MEX_COMPILER is requested.
Matlab_MCC_COMPILER
the mcc compiler of Matlab. Included with the Matlab Compiler add-on. Available only if the component MCC_COMPILER is requested.

Cached variables

Matlab_MEX_EXTENSION
the extension of the mex files for the current platform (given by Matlab).
Matlab_ROOT_DIR
the location of the root of the Matlab installation found. If this value is changed by the user, the result variables are recomputed.

Provided macros

matlab_get_version_from_release_name()
returns the version from the release name
matlab_get_release_name_from_version()
returns the release name from the Matlab version

Provided functions

matlab_add_mex()
adds a target compiling a MEX file.
matlab_add_unit_test()
adds a Matlab unit test file as a test to the project.
matlab_extract_all_installed_versions_from_registry()
parses the registry for all Matlab versions. Available on Windows only. The part of the registry parsed is dependent on the host processor
matlab_get_all_valid_matlab_roots_from_registry()
returns all the possible Matlab or MCR paths, according to a previously given list. Only the existing/accessible paths are kept. This is mainly useful for the searching all possible Matlab installation.
matlab_get_mex_suffix()
returns the suffix to be used for the mex files (platform/architecture dependent)
matlab_get_version_from_matlab_run()
returns the version of Matlab/MCR, given the full directory of the Matlab/MCR installation path.

Known issues

Symbol clash in a MEX target

By default, every symbols inside a MEX file defined with the command matlab_add_mex() have hidden visibility, except for the entry point. This is the default behaviour of the MEX compiler, which lowers the risk of symbol collision between the libraries shipped with Matlab, and the libraries to which the MEX file is linking to. This is also the default on Windows platforms.

However, this is not sufficient in certain case, where for instance your MEX file is linking against libraries that are already loaded by Matlab, even if those libraries have different SONAMES. A possible solution is to hide the symbols of the libraries to which the MEX target is linking to. This can be achieved in GNU GCC compilers with the linker option -Wl,--exclude-libs,ALL.

Tests using GPU resources
in case your MEX file is using the GPU and in order to be able to run unit tests on this MEX file, the GPU resources should be properly released by Matlab. A possible solution is to make Matlab aware of the use of the GPU resources in the session, which can be performed by a command such as D = gpuDevice() at the beginning of the test script (or via a fixture).

Reference

Matlab_ROOT_DIR

The root folder of the Matlab installation. If set before the call to find_package(), the module will look for the components in that path. If not set, then an automatic search of Matlab will be performed. If set, it should point to a valid version of Matlab.

MATLAB_FIND_DEBUG

If set, the lookup of Matlab and the intermediate configuration steps are outputted to the console.

MATLAB_ADDITIONAL_VERSIONS

If set, specifies additional versions of Matlab that may be looked for. The variable should be a list of strings, organised by pairs of release name and versions, such as follows:

set(MATLAB_ADDITIONAL_VERSIONS
    "release_name1=corresponding_version1"
    "release_name2=corresponding_version2"
    ...
    )

Example:

set(MATLAB_ADDITIONAL_VERSIONS
    "R2013b=8.2"
    "R2013a=8.1"
    "R2012b=8.0")

The order of entries in this list matters when several versions of Matlab are installed. The priority is set according to the ordering in this list.

matlab_get_version_from_release_name

Returns the version of Matlab (17.58) from a release name (R2017k)

matlab_get_release_name_from_version

Returns the release name (R2017k) from the version of Matlab (17.58)

matlab_extract_all_installed_versions_from_registry

This function parses the registry and founds the Matlab versions that are installed. The found versions are returned in matlab_versions. Set win64 to TRUE if the 64 bit version of Matlab should be looked for The returned list contains all versions under HKLM\\SOFTWARE\\Mathworks\\MATLAB and HKLM\\SOFTWARE\\Mathworks\\MATLAB Runtime or an empty list in case an error occurred (or nothing found).

Note

Only the versions are provided. No check is made over the existence of the installation referenced in the registry,

matlab_get_all_valid_matlab_roots_from_registry

Populates the Matlab root with valid versions of Matlab or Matlab Runtime (MCR). The returned matlab_roots is organized in triplets (type,version_number,matlab_root_path), where type indicates either MATLAB or MCR.

matlab_get_all_valid_matlab_roots_from_registry(
    matlab_versions
    matlab_roots)
matlab_versions
the versions of each of the Matlab or MCR installations
matlab_roots
the location of each of the Matlab or MCR installations
matlab_get_mex_suffix

Returns the extension of the mex files (the suffixes). This function should not be called before the appropriate Matlab root has been found.

matlab_get_mex_suffix(
    matlab_root
    mex_suffix)
matlab_root
the root of the Matlab/MCR installation
mex_suffix
the variable name in which the suffix will be returned.
matlab_get_version_from_matlab_run

This function runs Matlab program specified on arguments and extracts its version. If the path provided for the Matlab installation points to an MCR installation, the version is extracted from the installed files.

matlab_get_version_from_matlab_run(
    matlab_binary_path
    matlab_list_versions)
matlab_binary_path
the location of the matlab binary executable
matlab_list_versions
the version extracted from Matlab
matlab_add_unit_test

Adds a Matlab unit test to the test set of cmake/ctest. This command requires the component MAIN_PROGRAM and hence is not available for an MCR installation.

The unit test uses the Matlab unittest framework (default, available starting Matlab 2013b+) except if the option NO_UNITTEST_FRAMEWORK is given.

The function expects one Matlab test script file to be given. In the case NO_UNITTEST_FRAMEWORK is given, the unittest script file should contain the script to be run, plus an exit command with the exit value. This exit value will be passed to the ctest framework (0 success, non 0 failure). Additional arguments accepted by add_test() can be passed through TEST_ARGS (eg. CONFIGURATION <config> ...).

matlab_add_unit_test(
    NAME <name>
    UNITTEST_FILE matlab_file_containing_unittest.m
    [CUSTOM_TEST_COMMAND matlab_command_to_run_as_test]
    [UNITTEST_PRECOMMAND matlab_command_to_run]
    [TIMEOUT timeout]
    [ADDITIONAL_PATH path1 [path2 ...]]
    [MATLAB_ADDITIONAL_STARTUP_OPTIONS option1 [option2 ...]]
    [TEST_ARGS arg1 [arg2 ...]]
    [NO_UNITTEST_FRAMEWORK]
    )

The function arguments are:

NAME
name of the unittest in ctest.
UNITTEST_FILE
the matlab unittest file. Its path will be automatically added to the Matlab path.
CUSTOM_TEST_COMMAND
Matlab script command to run as the test. If this is not set, then the following is run: runtests('matlab_file_name'), exit(max([ans(1,:).Failed])) where matlab_file_name is the UNITTEST_FILE without the extension.
UNITTEST_PRECOMMAND
Matlab script command to be ran before the file containing the test (eg. GPU device initialisation based on CMake variables).
TIMEOUT
the test timeout in seconds. Defaults to 180 seconds as the Matlab unit test may hang.
ADDITIONAL_PATH
a list of paths to add to the Matlab path prior to running the unit test.
MATLAB_ADDITIONAL_STARTUP_OPTIONS
a list of additional option in order to run Matlab from the command line. -nosplash -nodesktop -nodisplay are always added.
TEST_ARGS
Additional options provided to the add_test command. These options are added to the default options (eg. “CONFIGURATIONS Release”)
NO_UNITTEST_FRAMEWORK
when set, indicates that the test should not use the unittest framework of Matlab (available for versions >= R2013a).
WORKING_DIRECTORY
This will be the working directory for the test. If specified it will also be the output directory used for the log file of the test run. If not specified the temporary directory ${CMAKE_BINARY_DIR}/Matlab will be used as the working directory and the log location.
matlab_add_mex

Adds a Matlab MEX target. This commands compiles the given sources with the current tool-chain in order to produce a MEX file. The final name of the produced output may be specified, as well as additional link libraries, and a documentation entry for the MEX file. Remaining arguments of the call are passed to the add_library() or add_executable() command.

matlab_add_mex(
    NAME <name>
    [EXECUTABLE | MODULE | SHARED]
    SRC src1 [src2 ...]
    [OUTPUT_NAME output_name]
    [DOCUMENTATION file.txt]
    [LINK_TO target1 target2 ...]
    [R2017b | R2018a]
    [...]
)
NAME
name of the target.
SRC
list of source files.
LINK_TO
a list of additional link dependencies. The target links to libmex and libmx by default.
OUTPUT_NAME
if given, overrides the default name. The default name is the name of the target without any prefix and with Matlab_MEX_EXTENSION suffix.
DOCUMENTATION
if given, the file file.txt will be considered as being the documentation file for the MEX file. This file is copied into the same folder without any processing, with the same name as the final mex file, and with extension .m. In that case, typing help <name> in Matlab prints the documentation contained in this file.
R2017b or R2018a may be given to specify the version of the C API
to use: R2017b specifies the traditional (separate complex) C API, and corresponds to the -R2017b flag for the mex command. R2018a specifies the new interleaved complex C API, and corresponds to the -R2018a flag for the mex command. Ignored if MATLAB version prior to R2018a. Defaults to R2017b.
MODULE or SHARED may be given to specify the type of library to be
created. EXECUTABLE may be given to create an executable instead of a library. If no type is given explicitly, the type is SHARED.

The documentation file is not processed and should be in the following format:

% This is the documentation
function ret = mex_target_output_name(input1)

  • cmake-modules(7) »


FindMFC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindMFC

Find MFC on Windows

Find the native MFC - i.e. decide if an application can link to the MFC libraries.

MFC_FOUND - Was MFC support found

You don’t need to include anything or link anything to use it.

  • cmake-modules(7) »


FindMotif — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindMotif

Try to find Motif (or lesstif)

Once done this will define:

MOTIF_FOUND        - system has MOTIF
MOTIF_INCLUDE_DIR  - include paths to use Motif
MOTIF_LIBRARIES    - Link these to use Motif

  • cmake-modules(7) »


FindMPEG2 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindMPEG2

Find the native MPEG2 includes and library

This module defines

MPEG2_INCLUDE_DIR, path to mpeg2dec/mpeg2.h, etc.
MPEG2_LIBRARIES, the libraries required to use MPEG2.
MPEG2_FOUND, If false, do not try to use MPEG2.

also defined, but not for general use are

MPEG2_mpeg2_LIBRARY, where to find the MPEG2 library.
MPEG2_vo_LIBRARY, where to find the vo library.

  • cmake-modules(7) »


FindMPEG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindMPEG

Find the native MPEG includes and library

This module defines

MPEG_INCLUDE_DIR, where to find MPEG.h, etc.
MPEG_LIBRARIES, the libraries required to use MPEG.
MPEG_FOUND, If false, do not try to use MPEG.

also defined, but not for general use are

MPEG_mpeg2_LIBRARY, where to find the MPEG library.
MPEG_vo_LIBRARY, where to find the vo library.

  • cmake-modules(7) »


FindMPI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindMPI

Find a Message Passing Interface (MPI) implementation.

The Message Passing Interface (MPI) is a library used to write high-performance distributed-memory parallel applications, and is typically deployed on a cluster. MPI is a standard interface (defined by the MPI forum) for which many implementations are available.

Variables for using MPI

The module exposes the components C, CXX, MPICXX and Fortran. Each of these controls the various MPI languages to search for. The difference between CXX and MPICXX is that CXX refers to the MPI C API being usable from C++, whereas MPICXX refers to the MPI-2 C++ API that was removed again in MPI-3.

Depending on the enabled components the following variables will be set:

MPI_FOUND
Variable indicating that MPI settings for all requested languages have been found. If no components are specified, this is true if MPI settings for all enabled languages were detected. Note that the MPICXX component does not affect this variable.
MPI_VERSION
Minimal version of MPI detected among the requested languages, or all enabled languages if no components were specified.

This module will set the following variables per language in your project, where <lang> is one of C, CXX, or Fortran:

MPI_<lang>_FOUND
Variable indicating the MPI settings for <lang> were found and that simple MPI test programs compile with the provided settings.
MPI_<lang>_COMPILER
MPI compiler for <lang> if such a program exists.
MPI_<lang>_COMPILE_OPTIONS
Compilation options for MPI programs in <lang>, given as a ;-list.
MPI_<lang>_COMPILE_DEFINITIONS
Compilation definitions for MPI programs in <lang>, given as a ;-list.
MPI_<lang>_INCLUDE_DIRS
Include path(s) for MPI header.
MPI_<lang>_LINK_FLAGS
Linker flags for MPI programs.
MPI_<lang>_LIBRARIES
All libraries to link MPI programs against.

Additionally, the following IMPORTED targets are defined:

MPI::MPI_<lang>
Target for using MPI from <lang>.

The following variables indicating which bindings are present will be defined:

MPI_MPICXX_FOUND
Variable indicating whether the MPI-2 C++ bindings are present (introduced in MPI-2, removed with MPI-3).
MPI_Fortran_HAVE_F77_HEADER
True if the Fortran 77 header mpif.h is available.
MPI_Fortran_HAVE_F90_MODULE
True if the Fortran 90 module mpi can be used for accessing MPI (MPI-2 and higher only).
MPI_Fortran_HAVE_F08_MODULE
True if the Fortran 2008 mpi_f08 is available to MPI programs (MPI-3 and higher only).

If possible, the MPI version will be determined by this module. The facilities to detect the MPI version were introduced with MPI-1.2, and therefore cannot be found for older MPI versions.

MPI_<lang>_VERSION_MAJOR
Major version of MPI implemented for <lang> by the MPI distribution.
MPI_<lang>_VERSION_MINOR
Minor version of MPI implemented for <lang> by the MPI distribution.
MPI_<lang>_VERSION
MPI version implemented for <lang> by the MPI distribution.

Note that there’s no variable for the C bindings being accessible through mpi.h, since the MPI standards always have required this binding to work in both C and C++ code.

For running MPI programs, the module sets the following variables

MPIEXEC_EXECUTABLE
Executable for running MPI programs, if such exists.
MPIEXEC_NUMPROC_FLAG
Flag to pass to mpiexec before giving it the number of processors to run on.
MPIEXEC_MAX_NUMPROCS
Number of MPI processors to utilize. Defaults to the number of processors detected on the host system.
MPIEXEC_PREFLAGS
Flags to pass to mpiexec directly before the executable to run.
MPIEXEC_POSTFLAGS
Flags to pass to mpiexec after other flags.

Variables for locating MPI

This module performs a three step search for an MPI implementation:

  1. Check if the compiler has MPI support built-in. This is the case if the user passed a compiler wrapper as CMAKE_<LANG>_COMPILER or if they’re on a Cray system.
  2. Attempt to find an MPI compiler wrapper and determine the compiler information from it.
  3. Try to find an MPI implementation that does not ship such a wrapper by guessing settings. Currently, only Microsoft MPI and MPICH2 on Windows are supported.

For controlling the second step, the following variables may be set:

MPI_<lang>_COMPILER
Search for the specified compiler wrapper and use it.
MPI_<lang>_COMPILER_FLAGS
Flags to pass to the MPI compiler wrapper during interrogation. Some compiler wrappers support linking debug or tracing libraries if a specific flag is passed and this variable may be used to obtain them.
MPI_COMPILER_FLAGS
Used to initialize MPI_<lang>_COMPILER_FLAGS if no language specific flag has been given. Empty by default.
MPI_EXECUTABLE_SUFFIX
A suffix which is appended to all names that are being looked for. For instance you may set this to .mpich or .openmpi to prefer the one or the other on Debian and its derivatives.

In order to control the guessing step, the following variable may be set:

MPI_GUESS_LIBRARY_NAME
Valid values are MSMPI and MPICH2. If set, only the given library will be searched for. By default, MSMPI will be preferred over MPICH2 if both are available. This also sets MPI_SKIP_COMPILER_WRAPPER to true, which may be overridden.

Each of the search steps may be skipped with the following control variables:

MPI_ASSUME_NO_BUILTIN_MPI
If true, the module assumes that the compiler itself does not provide an MPI implementation and skips to step 2.
MPI_SKIP_COMPILER_WRAPPER
If true, no compiler wrapper will be searched for.
MPI_SKIP_GUESSING
If true, the guessing step will be skipped.

Additionally, the following control variable is available to change search behavior:

MPI_CXX_SKIP_MPICXX
Add some definitions that will disable the MPI-2 C++ bindings. Currently supported are MPICH, Open MPI, Platform MPI and derivatives thereof, for example MVAPICH or Intel MPI.

If the find procedure fails for a variable MPI_<lang>_WORKS, then the settings detected by or passed to the module did not work and even a simple MPI test program failed to compile.

If all of these parameters were not sufficient to find the right MPI implementation, a user may disable the entire autodetection process by specifying both a list of libraries in MPI_<lang>_LIBRARIES and a list of include directories in MPI_<lang>_ADDITIONAL_INCLUDE_DIRS. Any other variable may be set in addition to these two. The module will then validate the MPI settings and store the settings in the cache.

Cache variables for MPI

The variable MPI_<lang>_INCLUDE_DIRS will be assembled from the following variables. For C and CXX:

MPI_<lang>_HEADER_DIR
Location of the mpi.h header on disk.

For Fortran:

MPI_Fortran_F77_HEADER_DIR
Location of the Fortran 77 header mpif.h, if it exists.
MPI_Fortran_MODULE_DIR
Location of the mpi or mpi_f08 modules, if available.

For all languages the following variables are additionally considered:

MPI_<lang>_ADDITIONAL_INCLUDE_DIRS
A ;-list of paths needed in addition to the normal include directories.
MPI_<include_name>_INCLUDE_DIR
Path variables for include folders referred to by <include_name>.
MPI_<lang>_ADDITIONAL_INCLUDE_VARS
A ;-list of <include_name> that will be added to the include locations of <lang>.

The variable MPI_<lang>_LIBRARIES will be assembled from the following variables:

MPI_<lib_name>_LIBRARY
The location of a library called <lib_name> for use with MPI.
MPI_<lang>_LIB_NAMES
A ;-list of <lib_name> that will be added to the include locations of <lang>.

Usage of mpiexec

When using MPIEXEC_EXECUTABLE to execute MPI applications, you should typically use all of the MPIEXEC_EXECUTABLE flags as follows:

${MPIEXEC_EXECUTABLE} ${MPIEXEC_NUMPROC_FLAG} ${MPIEXEC_MAX_NUMPROCS}
  ${MPIEXEC_PREFLAGS} EXECUTABLE ${MPIEXEC_POSTFLAGS} ARGS

where EXECUTABLE is the MPI program, and ARGS are the arguments to pass to the MPI program.

Advanced variables for using MPI

The module can perform some advanced feature detections upon explicit request.

Important notice: The following checks cannot be performed without executing an MPI test program. Consider the special considerations for the behavior of try_run() during cross compilation. Moreover, running an MPI program can cause additional issues, like a firewall notification on some systems. You should only enable these detections if you absolutely need the information.

If the following variables are set to true, the respective search will be performed:

MPI_DETERMINE_Fortran_CAPABILITIES
Determine for all available Fortran bindings what the values of MPI_SUBARRAYS_SUPPORTED and MPI_ASYNC_PROTECTS_NONBLOCKING are and make their values available as MPI_Fortran_<binding>_SUBARRAYS and MPI_Fortran_<binding>_ASYNCPROT, where <binding> is one of F77_HEADER, F90_MODULE and F08_MODULE.
MPI_DETERMINE_LIBRARY_VERSION
For each language, find the output of MPI_Get_library_version and make it available as MPI_<lang>_LIBRARY_VERSION. This information is usually tied to the runtime component of an MPI implementation and might differ depending on <lang>. Note that the return value is entirely implementation defined. This information might be used to identify the MPI vendor and for example pick the correct one of multiple third party binaries that matches the MPI vendor.

Backward Compatibility

For backward compatibility with older versions of FindMPI, these variables are set, but deprecated:

MPI_COMPILER        MPI_LIBRARY        MPI_EXTRA_LIBRARY
MPI_COMPILE_FLAGS   MPI_INCLUDE_PATH   MPI_LINK_FLAGS
MPI_LIBRARIES

In new projects, please use the MPI_<lang>_XXX equivalents. Additionally, the following variables are deprecated:

MPI_<lang>_COMPILE_FLAGS
Use MPI_<lang>_COMPILE_OPTIONS and MPI_<lang>_COMPILE_DEFINITIONS instead.
MPI_<lang>_INCLUDE_PATH
For consumption use MPI_<lang>_INCLUDE_DIRS and for specifying folders use MPI_<lang>_ADDITIONAL_INCLUDE_DIRS instead.
MPIEXEC
Use MPIEXEC_EXECUTABLE instead.

  • cmake-modules(7) »


FindODBC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindODBC

Find an Open Database Connectivity (ODBC) include directory and library.

On Windows, when building with Visual Studio, this module assumes the ODBC library is provided by the available Windows SDK.

On Unix, this module allows to search for ODBC library provided by unixODBC or iODBC implementations of ODBC API. This module reads hint about location of the config program:

ODBC_CONFIG

Location of odbc_config or iodbc-config program

Otherwise, this module tries to find the config program, first from unixODBC, then from iODBC. If no config program found, this module searches for ODBC header and library in list of known locations.

Imported targets

This module defines the following IMPORTED targets:

ODBC::ODBC

Imported target for using the ODBC library, if found.

Result variables

ODBC_FOUND

Set to true if ODBC library found, otherwise false or undefined.

ODBC_INCLUDE_DIRS

Paths to include directories listed in one variable for use by ODBC client. May be empty on Windows, where the include directory corresponding to the expected Windows SDK is already available in the compilation environment.

ODBC_LIBRARIES

Paths to libraries to linked against to use ODBC. May just a library name on Windows, where the library directory corresponding to the expected Windows SDK is already available in the compilation environment.

ODBC_CONFIG

Path to unixODBC or iODBC config program, if found or specified.

Cache variables

For users who wish to edit and control the module behavior, this module reads hints about search locations from the following variables:

ODBC_INCLUDE_DIR

Path to ODBC include directory with sql.h header.

ODBC_LIBRARY

Path to ODBC library to be linked.

These variables should not be used directly by project code.

Limitations

On Windows, this module does not search for iODBC. On Unix, there is no way to prefer unixODBC over iODBC, or vice versa, other than providing the config program location using the ODBC_CONFIG. This module does not allow to search for a specific ODBC driver.

  • cmake-modules(7) »


FindOpenACC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindOpenACC

Detect OpenACC support by the compiler.

This module can be used to detect OpenACC support in a compiler. If the compiler supports OpenACC, the flags required to compile with OpenACC support are returned in variables for the different languages. Currently, only PGI, GNU and Cray compilers are supported.

Variables

This module will set the following variables per language in your project, where <lang> is one of C, CXX, or Fortran:

OpenACC_<lang>_FOUND
Variable indicating if OpenACC support for <lang> was detected.
OpenACC_<lang>_FLAGS
OpenACC compiler flags for <lang>, separated by spaces.

The module will also try to provide the OpenACC version variables:

OpenACC_<lang>_SPEC_DATE
Date of the OpenACC specification implemented by the <lang> compiler.
OpenACC_<lang>_VERSION_MAJOR
Major version of OpenACC implemented by the <lang> compiler.
OpenACC_<lang>_VERSION_MINOR
Minor version of OpenACC implemented by the <lang> compiler.
OpenACC_<lang>_VERSION
OpenACC version implemented by the <lang> compiler.

The specification date is formatted as given in the OpenACC standard: yyyymm where yyyy and mm represents the year and month of the OpenACC specification implemented by the <lang> compiler.

Input Variables

OpenACC_ACCEL_TARGET=<target> If set, will the correct target accelerator flag set to the <target> will be returned with OpenACC_<lang>_FLAGS.

  • cmake-modules(7) »


FindOpenAL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindOpenAL

Locate OpenAL This module defines OPENAL_LIBRARY OPENAL_FOUND, if false, do not try to link to OpenAL OPENAL_INCLUDE_DIR, where to find the headers

$OPENALDIR is an environment variable that would correspond to the ./configure –prefix=$OPENALDIR used in building OpenAL.

Created by Eric Wing. This was influenced by the FindSDL.cmake module.

  • cmake-modules(7) »


FindOpenCL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindOpenCL

Try to find OpenCL

IMPORTED Targets

This module defines IMPORTED target OpenCL::OpenCL, if OpenCL has been found.

Result Variables

This module defines the following variables:

OpenCL_FOUND          - True if OpenCL was found
OpenCL_INCLUDE_DIRS   - include directories for OpenCL
OpenCL_LIBRARIES      - link against this library to use OpenCL
OpenCL_VERSION_STRING - Highest supported OpenCL version (eg. 1.2)
OpenCL_VERSION_MAJOR  - The major version of the OpenCL implementation
OpenCL_VERSION_MINOR  - The minor version of the OpenCL implementation

The module will also define two cache variables:

OpenCL_INCLUDE_DIR    - the OpenCL include directory
OpenCL_LIBRARY        - the path to the OpenCL library

  • cmake-modules(7) »


FindOpenGL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindOpenGL

FindModule for OpenGL and GLU.

Optional COMPONENTS

This module respects several optional COMPONENTS: EGL, GLX, and OpenGL. There are corresponding import targets for each of these flags.

IMPORTED Targets

This module defines the IMPORTED targets:

OpenGL::GL
Defined to the platform-specific OpenGL libraries if the system has OpenGL.
OpenGL::OpenGL
Defined to libOpenGL if the system is GLVND-based.
OpenGL::GLU
Defined if the system has GLU.
OpenGL::GLX
Defined if the system has GLX.
OpenGL::EGL
Defined if the system has EGL.

Result Variables

This module sets the following variables:

OPENGL_FOUND
True, if the system has OpenGL and all components are found.
OPENGL_XMESA_FOUND
True, if the system has XMESA.
OPENGL_GLU_FOUND
True, if the system has GLU.
OpenGL_OpenGL_FOUND
True, if the system has an OpenGL library.
OpenGL_GLX_FOUND
True, if the system has GLX.
OpenGL_EGL_FOUND
True, if the system has EGL.
OPENGL_INCLUDE_DIR
Path to the OpenGL include directory.
OPENGL_EGL_INCLUDE_DIRS
Path to the EGL include directory.
OPENGL_LIBRARIES
Paths to the OpenGL library, windowing system libraries, and GLU libraries. On Linux, this assumes GLX and is never correct for EGL-based targets. Clients are encouraged to use the OpenGL::* import targets instead.

Cache variables

The following cache variables may also be set:

OPENGL_egl_LIBRARY
Path to the EGL library.
OPENGL_glu_LIBRARY
Path to the GLU library.
OPENGL_glx_LIBRARY
Path to the GLVND ‘GLX’ library.
OPENGL_opengl_LIBRARY
Path to the GLVND ‘OpenGL’ library
OPENGL_gl_LIBRARY
Path to the OpenGL library. New code should prefer the OpenGL::* import targets.

Linux-specific

Some Linux systems utilize GLVND as a new ABI for OpenGL. GLVND separates context libraries from OpenGL itself; OpenGL lives in “libOpenGL”, and contexts are defined in “libGLX” or “libEGL”. GLVND is currently the only way to get OpenGL 3+ functionality via EGL in a manner portable across vendors. Projects may use GLVND explicitly with target OpenGL::OpenGL and either OpenGL::GLX or OpenGL::EGL.

Projects may use the OpenGL::GL target (or OPENGL_LIBRARIES variable) to use legacy GL interfaces. These will use the legacy GL library located by OPENGL_gl_LIBRARY, if available. If OPENGL_gl_LIBRARY is empty or not found and GLVND is available, the OpenGL::GL target will use GLVND OpenGL::OpenGL and OpenGL::GLX (and the OPENGL_LIBRARIES variable will use the corresponding libraries). Thus, for non-EGL-based Linux targets, the OpenGL::GL target is most portable.

A OpenGL_GL_PREFERENCE variable may be set to specify the preferred way to provide legacy GL interfaces in case multiple choices are available. The value may be one of:

GLVND
If the GLVND OpenGL and GLX libraries are available, prefer them. This forces OPENGL_gl_LIBRARY to be empty. This is the default if components were requested (since components correspond to GLVND libraries) or if policy CMP0072 is set to NEW.
LEGACY
Prefer to use the legacy libGL library, if available. This is the default if no components were requested and policy CMP0072 is not set to NEW.

For EGL targets the client must rely on GLVND support on the user’s system. Linking should use the OpenGL::OpenGL OpenGL::EGL targets. Using GLES* libraries is theoretically possible in place of OpenGL::OpenGL, but this module does not currently support that; contributions welcome.

OPENGL_egl_LIBRARY and OPENGL_EGL_INCLUDE_DIRS are defined in the case of GLVND. For non-GLVND Linux and other systems these are left undefined.

macOS-Specific

On OSX FindOpenGL defaults to using the framework version of OpenGL. People will have to change the cache values of OPENGL_glu_LIBRARY and OPENGL_gl_LIBRARY to use OpenGL with X11 on OSX.

  • cmake-modules(7) »


FindOpenMP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindOpenMP

Finds OpenMP support

This module can be used to detect OpenMP support in a compiler. If the compiler supports OpenMP, the flags required to compile with OpenMP support are returned in variables for the different languages. The variables may be empty if the compiler does not need a special flag to support OpenMP.

Variables

The module exposes the components C, CXX, and Fortran. Each of these controls the various languages to search OpenMP support for.

Depending on the enabled components the following variables will be set:

OpenMP_FOUND
Variable indicating that OpenMP flags for all requested languages have been found. If no components are specified, this is true if OpenMP settings for all enabled languages were detected.
OpenMP_VERSION
Minimal version of the OpenMP standard detected among the requested languages, or all enabled languages if no components were specified.

This module will set the following variables per language in your project, where <lang> is one of C, CXX, or Fortran:

OpenMP_<lang>_FOUND
Variable indicating if OpenMP support for <lang> was detected.
OpenMP_<lang>_FLAGS
OpenMP compiler flags for <lang>, separated by spaces.

For linking with OpenMP code written in <lang>, the following variables are provided:

OpenMP_<lang>_LIB_NAMES
;-list of libraries for OpenMP programs for <lang>.
OpenMP_<libname>_LIBRARY
Location of the individual libraries needed for OpenMP support in <lang>.
OpenMP_<lang>_LIBRARIES
A list of libraries needed to link with OpenMP code written in <lang>.

Additionally, the module provides IMPORTED targets:

OpenMP::OpenMP_<lang>
Target for using OpenMP from <lang>.

Specifically for Fortran, the module sets the following variables:

OpenMP_Fortran_HAVE_OMPLIB_HEADER
Boolean indicating if OpenMP is accessible through omp_lib.h.
OpenMP_Fortran_HAVE_OMPLIB_MODULE
Boolean indicating if OpenMP is accessible through the omp_lib Fortran module.

The module will also try to provide the OpenMP version variables:

OpenMP_<lang>_SPEC_DATE
Date of the OpenMP specification implemented by the <lang> compiler.
OpenMP_<lang>_VERSION_MAJOR
Major version of OpenMP implemented by the <lang> compiler.
OpenMP_<lang>_VERSION_MINOR
Minor version of OpenMP implemented by the <lang> compiler.
OpenMP_<lang>_VERSION
OpenMP version implemented by the <lang> compiler.

The specification date is formatted as given in the OpenMP standard: yyyymm where yyyy and mm represents the year and month of the OpenMP specification implemented by the <lang> compiler.

  • cmake-modules(7) »


FindOpenSceneGraph — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindOpenSceneGraph

Find OpenSceneGraph

This module searches for the OpenSceneGraph core “osg” library as well as OpenThreads, and whatever additional COMPONENTS (nodekits) that you specify.

See http://www.openscenegraph.org

NOTE: To use this module effectively you must either require CMake >= 2.6.3 with cmake_minimum_required(VERSION 2.6.3) or download and place FindOpenThreads.cmake, Findosg_functions.cmake, Findosg.cmake, and Find<etc>.cmake files into your CMAKE_MODULE_PATH.

This module accepts the following variables (note mixed case)

OpenSceneGraph_DEBUG - Enable debugging output

OpenSceneGraph_MARK_AS_ADVANCED - Mark cache variables as advanced
                                  automatically

The following environment variables are also respected for finding the OSG and it’s various components. CMAKE_PREFIX_PATH can also be used for this (see find_library() CMake documentation).

<MODULE>_DIR
(where MODULE is of the form “OSGVOLUME” and there is a FindosgVolume.cmake file)
OSG_DIR
OSGDIR
OSG_ROOT

[CMake 2.8.10]: The CMake variable OSG_DIR can now be used as well to influence detection, instead of needing to specify an environment variable.

This module defines the following output variables:

OPENSCENEGRAPH_FOUND - Was the OSG and all of the specified components found?

OPENSCENEGRAPH_VERSION - The version of the OSG which was found

OPENSCENEGRAPH_INCLUDE_DIRS - Where to find the headers

OPENSCENEGRAPH_LIBRARIES - The OSG libraries

================================== Example Usage:

find_package(OpenSceneGraph 2.0.0 REQUIRED osgDB osgUtil)
    # libOpenThreads & libosg automatically searched
include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})

add_executable(foo foo.cc)
target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})

  • cmake-modules(7) »


FindOpenSSL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindOpenSSL

Find the OpenSSL encryption library.

Optional COMPONENTS

This module supports two optional COMPONENTS: Crypto and SSL. Both components have associated imported targets, as described below.

Imported Targets

This module defines the following IMPORTED targets:

OpenSSL::SSL
The OpenSSL ssl library, if found.
OpenSSL::Crypto
The OpenSSL crypto library, if found.

Result Variables

This module will set the following variables in your project:

OPENSSL_FOUND
System has the OpenSSL library. If no components are requested it only requires the crypto library.
OPENSSL_INCLUDE_DIR
The OpenSSL include directory.
OPENSSL_CRYPTO_LIBRARY
The OpenSSL crypto library.
OPENSSL_SSL_LIBRARY
The OpenSSL SSL library.
OPENSSL_LIBRARIES
All OpenSSL libraries.
OPENSSL_VERSION
This is set to $major.$minor.$revision$patch (e.g. 0.9.8s).

Hints

Set OPENSSL_ROOT_DIR to the root directory of an OpenSSL installation. Set OPENSSL_USE_STATIC_LIBS to TRUE to look for static libraries. Set OPENSSL_MSVC_STATIC_RT set TRUE to choose the MT version of the lib.

  • cmake-modules(7) »


FindOpenThreads — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindOpenThreads

OpenThreads is a C++ based threading library. Its largest userbase seems to OpenSceneGraph so you might notice I accept OSGDIR as an environment path. I consider this part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module.

Locate OpenThreads This module defines OPENTHREADS_LIBRARY OPENTHREADS_FOUND, if false, do not try to link to OpenThreads OPENTHREADS_INCLUDE_DIR, where to find the headers

$OPENTHREADS_DIR is an environment variable that would correspond to the ./configure –prefix=$OPENTHREADS_DIR used in building osg.

[CMake 2.8.10]: The CMake variables OPENTHREADS_DIR or OSG_DIR can now be used as well to influence detection, instead of needing to specify an environment variable.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgAnimation — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgAnimation

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgAnimation This module defines

OSGANIMATION_FOUND - Was osgAnimation found? OSGANIMATION_INCLUDE_DIR - Where to find the headers OSGANIMATION_LIBRARIES - The libraries to link against for the OSG (use this)

OSGANIMATION_LIBRARY - The OSG library OSGANIMATION_LIBRARY_DEBUG - The OSG debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgDB — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgDB

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgDB This module defines

OSGDB_FOUND - Was osgDB found? OSGDB_INCLUDE_DIR - Where to find the headers OSGDB_LIBRARIES - The libraries to link against for the osgDB (use this)

OSGDB_LIBRARY - The osgDB library OSGDB_LIBRARY_DEBUG - The osgDB debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


Findosg_functions — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

Findosg_functions

This CMake file contains two macros to assist with searching for OSG libraries and nodekits. Please see FindOpenSceneGraph.cmake for full documentation.

  • cmake-modules(7) »


FindosgFX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgFX

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgFX This module defines

OSGFX_FOUND - Was osgFX found? OSGFX_INCLUDE_DIR - Where to find the headers OSGFX_LIBRARIES - The libraries to link against for the osgFX (use this)

OSGFX_LIBRARY - The osgFX library OSGFX_LIBRARY_DEBUG - The osgFX debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgGA — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgGA

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgGA This module defines

OSGGA_FOUND - Was osgGA found? OSGGA_INCLUDE_DIR - Where to find the headers OSGGA_LIBRARIES - The libraries to link against for the osgGA (use this)

OSGGA_LIBRARY - The osgGA library OSGGA_LIBRARY_DEBUG - The osgGA debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgIntrospection — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgIntrospection

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgINTROSPECTION This module defines

OSGINTROSPECTION_FOUND - Was osgIntrospection found? OSGINTROSPECTION_INCLUDE_DIR - Where to find the headers OSGINTROSPECTION_LIBRARIES - The libraries to link for osgIntrospection (use this)

OSGINTROSPECTION_LIBRARY - The osgIntrospection library OSGINTROSPECTION_LIBRARY_DEBUG - The osgIntrospection debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgManipulator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgManipulator

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgManipulator This module defines

OSGMANIPULATOR_FOUND - Was osgManipulator found? OSGMANIPULATOR_INCLUDE_DIR - Where to find the headers OSGMANIPULATOR_LIBRARIES - The libraries to link for osgManipulator (use this)

OSGMANIPULATOR_LIBRARY - The osgManipulator library OSGMANIPULATOR_LIBRARY_DEBUG - The osgManipulator debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgParticle — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgParticle

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgParticle This module defines

OSGPARTICLE_FOUND - Was osgParticle found? OSGPARTICLE_INCLUDE_DIR - Where to find the headers OSGPARTICLE_LIBRARIES - The libraries to link for osgParticle (use this)

OSGPARTICLE_LIBRARY - The osgParticle library OSGPARTICLE_LIBRARY_DEBUG - The osgParticle debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgPresentation — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgPresentation

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgPresentation This module defines

OSGPRESENTATION_FOUND - Was osgPresentation found? OSGPRESENTATION_INCLUDE_DIR - Where to find the headers OSGPRESENTATION_LIBRARIES - The libraries to link for osgPresentation (use this)

OSGPRESENTATION_LIBRARY - The osgPresentation library OSGPRESENTATION_LIBRARY_DEBUG - The osgPresentation debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing. Modified to work with osgPresentation by Robert Osfield, January 2012.

  • cmake-modules(7) »


FindosgProducer — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgProducer

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgProducer This module defines

OSGPRODUCER_FOUND - Was osgProducer found? OSGPRODUCER_INCLUDE_DIR - Where to find the headers OSGPRODUCER_LIBRARIES - The libraries to link for osgProducer (use this)

OSGPRODUCER_LIBRARY - The osgProducer library OSGPRODUCER_LIBRARY_DEBUG - The osgProducer debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgQt — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgQt

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgQt This module defines

OSGQT_FOUND - Was osgQt found? OSGQT_INCLUDE_DIR - Where to find the headers OSGQT_LIBRARIES - The libraries to link for osgQt (use this)

OSGQT_LIBRARY - The osgQt library OSGQT_LIBRARY_DEBUG - The osgQt debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing. Modified to work with osgQt by Robert Osfield, January 2012.

  • cmake-modules(7) »


Findosg — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

Findosg

NOTE: It is highly recommended that you use the new FindOpenSceneGraph.cmake introduced in CMake 2.6.3 and not use this Find module directly.

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osg This module defines

OSG_FOUND - Was the Osg found? OSG_INCLUDE_DIR - Where to find the headers OSG_LIBRARIES - The libraries to link against for the OSG (use this)

OSG_LIBRARY - The OSG library OSG_LIBRARY_DEBUG - The OSG debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgShadow — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgShadow

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgShadow This module defines

OSGSHADOW_FOUND - Was osgShadow found? OSGSHADOW_INCLUDE_DIR - Where to find the headers OSGSHADOW_LIBRARIES - The libraries to link for osgShadow (use this)

OSGSHADOW_LIBRARY - The osgShadow library OSGSHADOW_LIBRARY_DEBUG - The osgShadow debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgSim — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgSim

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgSim This module defines

OSGSIM_FOUND - Was osgSim found? OSGSIM_INCLUDE_DIR - Where to find the headers OSGSIM_LIBRARIES - The libraries to link for osgSim (use this)

OSGSIM_LIBRARY - The osgSim library OSGSIM_LIBRARY_DEBUG - The osgSim debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgTerrain — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgTerrain

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgTerrain This module defines

OSGTERRAIN_FOUND - Was osgTerrain found? OSGTERRAIN_INCLUDE_DIR - Where to find the headers OSGTERRAIN_LIBRARIES - The libraries to link for osgTerrain (use this)

OSGTERRAIN_LIBRARY - The osgTerrain library OSGTERRAIN_LIBRARY_DEBUG - The osgTerrain debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgText — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgText

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgText This module defines

OSGTEXT_FOUND - Was osgText found? OSGTEXT_INCLUDE_DIR - Where to find the headers OSGTEXT_LIBRARIES - The libraries to link for osgText (use this)

OSGTEXT_LIBRARY - The osgText library OSGTEXT_LIBRARY_DEBUG - The osgText debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgUtil — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgUtil

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgUtil This module defines

OSGUTIL_FOUND - Was osgUtil found? OSGUTIL_INCLUDE_DIR - Where to find the headers OSGUTIL_LIBRARIES - The libraries to link for osgUtil (use this)

OSGUTIL_LIBRARY - The osgUtil library OSGUTIL_LIBRARY_DEBUG - The osgUtil debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgViewer — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgViewer

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgViewer This module defines

OSGVIEWER_FOUND - Was osgViewer found? OSGVIEWER_INCLUDE_DIR - Where to find the headers OSGVIEWER_LIBRARIES - The libraries to link for osgViewer (use this)

OSGVIEWER_LIBRARY - The osgViewer library OSGVIEWER_LIBRARY_DEBUG - The osgViewer debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgVolume — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgVolume

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgVolume This module defines

OSGVOLUME_FOUND - Was osgVolume found? OSGVOLUME_INCLUDE_DIR - Where to find the headers OSGVOLUME_LIBRARIES - The libraries to link for osgVolume (use this)

OSGVOLUME_LIBRARY - The osgVolume library OSGVOLUME_LIBRARY_DEBUG - The osgVolume debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindosgWidget — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindosgWidget

This is part of the Findosg* suite used to find OpenSceneGraph components. Each component is separate and you must opt in to each module. You must also opt into OpenGL and OpenThreads (and Producer if needed) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate osgWidget This module defines

OSGWIDGET_FOUND - Was osgWidget found? OSGWIDGET_INCLUDE_DIR - Where to find the headers OSGWIDGET_LIBRARIES - The libraries to link for osgWidget (use this)

OSGWIDGET_LIBRARY - The osgWidget library OSGWIDGET_LIBRARY_DEBUG - The osgWidget debug library

$OSGDIR is an environment variable that would correspond to the ./configure –prefix=$OSGDIR used in building osg.

FindosgWidget.cmake tweaked from Findosg* suite as created by Eric Wing.

  • cmake-modules(7) »


FindPatch — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPatch

The module defines the following variables:

Patch_EXECUTABLE
Path to patch command-line executable.
Patch_FOUND
True if the patch command-line executable was found.

The following IMPORTED targets are also defined:

Patch::patch
The command-line executable.

Example usage:

find_package(Patch)
if(Patch_FOUND)
  message("Patch found: ${Patch_EXECUTABLE}")
endif()

  • cmake-modules(7) »


FindPerlLibs — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPerlLibs

Find Perl libraries

This module finds if PERL is installed and determines where the include files and libraries are. It also determines what the name of the library is. This code sets the following variables:

PERLLIBS_FOUND    = True if perl.h & libperl were found
PERL_INCLUDE_PATH = path to where perl.h is found
PERL_LIBRARY      = path to libperl
PERL_EXECUTABLE   = full path to the perl binary

The minimum required version of Perl can be specified using the standard syntax, e.g. find_package(PerlLibs 6.0)

The following variables are also available if needed
(introduced after CMake 2.6.4)

PERL_SITESEARCH     = path to the sitesearch install dir (-V:installsitesearch)
PERL_SITEARCH       = path to the sitelib install directory (-V:installsitearch)
PERL_SITELIB        = path to the sitelib install directory (-V:installsitelib)
PERL_VENDORARCH     = path to the vendor arch install directory (-V:installvendorarch)
PERL_VENDORLIB      = path to the vendor lib install directory (-V:installvendorlib)
PERL_ARCHLIB        = path to the core arch lib install directory (-V:archlib)
PERL_PRIVLIB        = path to the core priv lib install directory (-V:privlib)
PERL_UPDATE_ARCHLIB = path to the update arch lib install directory (-V:installarchlib)
PERL_UPDATE_PRIVLIB = path to the update priv lib install directory (-V:installprivlib)
PERL_EXTRA_C_FLAGS = Compilation flags used to build perl

  • cmake-modules(7) »


FindPerl — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPerl

Find perl

this module looks for Perl

PERL_EXECUTABLE     - the full path to perl
PERL_FOUND          - If false, don't attempt to use perl.
PERL_VERSION_STRING - version of perl found (since CMake 2.8.8)

  • cmake-modules(7) »


FindPHP4 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPHP4

Find PHP4

This module finds if PHP4 is installed and determines where the include files and libraries are. It also determines what the name of the library is. This code sets the following variables:

PHP4_INCLUDE_PATH       = path to where php.h can be found
PHP4_EXECUTABLE         = full path to the php4 binary

  • cmake-modules(7) »


FindPhysFS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPhysFS

Locate PhysFS library This module defines PHYSFS_LIBRARY, the name of the library to link against PHYSFS_FOUND, if false, do not try to link to PHYSFS PHYSFS_INCLUDE_DIR, where to find physfs.h

$PHYSFSDIR is an environment variable that would correspond to the ./configure –prefix=$PHYSFSDIR used in building PHYSFS.

Created by Eric Wing.

  • cmake-modules(7) »


FindPike — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPike

Find Pike

This module finds if PIKE is installed and determines where the include files and libraries are. It also determines what the name of the library is. This code sets the following variables:

PIKE_INCLUDE_PATH       = path to where program.h is found
PIKE_EXECUTABLE         = full path to the pike binary

  • cmake-modules(7) »


FindPkgConfig — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPkgConfig

A pkg-config module for CMake.

Finds the pkg-config executable and adds the pkg_get_variable(), pkg_check_modules() and pkg_search_module() commands. The following variables will also be set:

PKG_CONFIG_FOUND
if pkg-config executable was found
PKG_CONFIG_EXECUTABLE
pathname of the pkg-config program
PKG_CONFIG_VERSION_STRING
version of pkg-config (since CMake 2.8.8)
pkg_get_variable

Retrieves the value of a pkg-config variable varName and stores it in the result variable resultVar in the calling scope.

pkg_get_variable(<resultVar> <moduleName> <varName>)

If pkg-config returns multiple values for the specified variable, resultVar will contain a ;-list.

For example:

pkg_get_variable(GI_GIRDIR gobject-introspection-1.0 girdir)
pkg_check_modules

Checks for all the given modules, setting a variety of result variables in the calling scope.

pkg_check_modules(<prefix>
                  [REQUIRED] [QUIET]
                  [NO_CMAKE_PATH]
                  [NO_CMAKE_ENVIRONMENT_PATH]
                  [IMPORTED_TARGET [GLOBAL]]
                  <moduleSpec> [<moduleSpec>...])

When the REQUIRED argument is given, the command will fail with an error if module(s) could not be found.

When the QUIET argument is given, no status messages will be printed.

By default, if CMAKE_MINIMUM_REQUIRED_VERSION is 3.1 or later, or if PKG_CONFIG_USE_CMAKE_PREFIX_PATH is set to a boolean True value, then the CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH, and CMAKE_APPBUNDLE_PATH cache and environment variables will be added to the pkg-config search path. The NO_CMAKE_PATH and NO_CMAKE_ENVIRONMENT_PATH arguments disable this behavior for the cache variables and environment variables respectively.

The IMPORTED_TARGET argument will create an imported target named PkgConfig::<prefix> that can be passed directly as an argument to target_link_libraries(). The GLOBAL argument will make the imported target available in global scope.

Each <moduleSpec> can be either a bare module name or it can be a module name with a version constraint (operators =, <, >, <= and >= are supported). The following are examples for a module named foo with various constraints:

  • foo matches any version.
  • foo<2 only matches versions before 2.
  • foo>=3.1 matches any version from 3.1 or later.
  • foo=1.2.3 requires that foo must be exactly version 1.2.3.

The following variables may be set upon return. Two sets of values exist: One for the common case (<XXX> = <prefix>) and another for the information pkg-config provides when called with the --static option (<XXX> = <prefix>_STATIC).

<XXX>_FOUND
set to 1 if module(s) exist
<XXX>_LIBRARIES
only the libraries (without the ‘-l’)
<XXX>_LINK_LIBRARIES
the libraries and their absolute paths
<XXX>_LIBRARY_DIRS
the paths of the libraries (without the ‘-L’)
<XXX>_LDFLAGS
all required linker flags
<XXX>_LDFLAGS_OTHER
all other linker flags
<XXX>_INCLUDE_DIRS
the ‘-I’ preprocessor flags (without the ‘-I’)
<XXX>_CFLAGS
all required cflags
<XXX>_CFLAGS_OTHER
the other compiler flags

All but <XXX>_FOUND may be a ;-list if the associated variable returned from pkg-config has multiple values.

There are some special variables whose prefix depends on the number of <moduleSpec> given. When there is only one <moduleSpec>, <YYY> will simply be <prefix>, but if two or more <moduleSpec> items are given, <YYY> will be <prefix>_<moduleName>.

<YYY>_VERSION
version of the module
<YYY>_PREFIX
prefix directory of the module
<YYY>_INCLUDEDIR
include directory of the module
<YYY>_LIBDIR
lib directory of the module

Examples:

pkg_check_modules (GLIB2 glib-2.0)

Looks for any version of glib2. If found, the output variable GLIB2_VERSION will hold the actual version found.

pkg_check_modules (GLIB2 glib-2.0>=2.10)

Looks for at least version 2.10 of glib2. If found, the output variable GLIB2_VERSION will hold the actual version found.

pkg_check_modules (FOO glib-2.0>=2.10 gtk+-2.0)

Looks for both glib2-2.0 (at least version 2.10) and any version of gtk2+-2.0. Only if both are found will FOO be considered found. The FOO_glib-2.0_VERSION and FOO_gtk+-2.0_VERSION variables will be set to their respective found module versions.

pkg_check_modules (XRENDER REQUIRED xrender)

Requires any version of xrender. Example output variables set by a successful call:

XRENDER_LIBRARIES=Xrender;X11
XRENDER_STATIC_LIBRARIES=Xrender;X11;pthread;Xau;Xdmcp
pkg_search_module

The behavior of this command is the same as pkg_check_modules(), except that rather than checking for all the specified modules, it searches for just the first successful match.

pkg_search_module(<prefix>
                  [REQUIRED] [QUIET]
                  [NO_CMAKE_PATH]
                  [NO_CMAKE_ENVIRONMENT_PATH]
                  [IMPORTED_TARGET [GLOBAL]]
                  <moduleSpec> [<moduleSpec>...])

Example:

pkg_search_module (BAR libxml-2.0 libxml2 libxml>=2)

Variables Affecting Behavior

PKG_CONFIG_EXECUTABLE

This can be set to the path of the pkg-config executable. If not provided, it will be set by the module as a result of calling find_program() internally. The PKG_CONFIG environment variable can be used as a hint.

PKG_CONFIG_USE_CMAKE_PREFIX_PATH

Specifies whether pkg_check_modules() and pkg_search_module() should add the paths in the CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH cache and environment variables to the pkg-config search path.

If this variable is not set, this behavior is enabled by default if CMAKE_MINIMUM_REQUIRED_VERSION is 3.1 or later, disabled otherwise.

  • cmake-modules(7) »


FindPNG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPNG

Find libpng, the official reference library for the PNG image format.

Imported targets

This module defines the following IMPORTED target:

PNG::PNG
The libpng library, if found.

Result variables

This module will set the following variables in your project:

PNG_INCLUDE_DIRS
where to find png.h, etc.
PNG_LIBRARIES
the libraries to link against to use PNG.
PNG_DEFINITIONS
You should add_definitions(${PNG_DEFINITIONS}) before compiling code that includes png library files.
PNG_FOUND
If false, do not try to use PNG.
PNG_VERSION_STRING
the version of the PNG library found (since CMake 2.8.8)

Obsolete variables

The following variables may also be set, for backwards compatibility:

PNG_LIBRARY
where to find the PNG library.
PNG_INCLUDE_DIR
where to find the PNG headers (same as PNG_INCLUDE_DIRS)

Since PNG depends on the ZLib compression library, none of the above will be defined unless ZLib can be found.

  • cmake-modules(7) »


FindPostgreSQL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPostgreSQL

Find the PostgreSQL installation.

IMPORTED Targets

This module defines IMPORTED target PostgreSQL::PostgreSQL if PostgreSQL has been found.

Result Variables

This module will set the following variables in your project:

PostgreSQL_FOUND
True if PostgreSQL is found.
PostgreSQL_LIBRARIES
the PostgreSQL libraries needed for linking
PostgreSQL_INCLUDE_DIRS
the directories of the PostgreSQL headers
PostgreSQL_LIBRARY_DIRS
the link directories for PostgreSQL libraries
PostgreSQL_VERSION_STRING
the version of PostgreSQL found

  • cmake-modules(7) »


FindProducer — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindProducer

Though Producer isn’t directly part of OpenSceneGraph, its primary user is OSG so I consider this part of the Findosg* suite used to find OpenSceneGraph components. You’ll notice that I accept OSGDIR as an environment path.

Each component is separate and you must opt in to each module. You must also opt into OpenGL (and OpenThreads?) as these modules won’t do it for you. This is to allow you control over your own system piece by piece in case you need to opt out of certain components or change the Find behavior for a particular module (perhaps because the default FindOpenGL.cmake module doesn’t work with your system as an example). If you want to use a more convenient module that includes everything, use the FindOpenSceneGraph.cmake instead of the Findosg*.cmake modules.

Locate Producer This module defines PRODUCER_LIBRARY PRODUCER_FOUND, if false, do not try to link to Producer PRODUCER_INCLUDE_DIR, where to find the headers

$PRODUCER_DIR is an environment variable that would correspond to the ./configure –prefix=$PRODUCER_DIR used in building osg.

Created by Eric Wing.

  • cmake-modules(7) »


FindProtobuf — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindProtobuf

Locate and configure the Google Protocol Buffers library.

The following variables can be set and are optional:

Protobuf_SRC_ROOT_FOLDER
When compiling with MSVC, if this cache variable is set the protobuf-default VS project build locations (vsprojects/Debug and vsprojects/Release or vsprojects/x64/Debug and vsprojects/x64/Release) will be searched for libraries and binaries.
Protobuf_IMPORT_DIRS
List of additional directories to be searched for imported .proto files.
Protobuf_DEBUG
Show debug messages.
Protobuf_USE_STATIC_LIBS
Set to ON to force the use of the static libraries. Default is OFF.

Defines the following variables:

Protobuf_FOUND
Found the Google Protocol Buffers library (libprotobuf & header files)
Protobuf_VERSION
Version of package found.
Protobuf_INCLUDE_DIRS
Include directories for Google Protocol Buffers
Protobuf_LIBRARIES
The protobuf libraries
Protobuf_PROTOC_LIBRARIES
The protoc libraries
Protobuf_LITE_LIBRARIES
The protobuf-lite libraries

The following IMPORTED targets are also defined:

protobuf::libprotobuf
The protobuf library.
protobuf::libprotobuf-lite
The protobuf lite library.
protobuf::libprotoc
The protoc library.
protobuf::protoc
The protoc compiler.

The following cache variables are also available to set or use:

Protobuf_LIBRARY
The protobuf library
Protobuf_PROTOC_LIBRARY
The protoc library
Protobuf_INCLUDE_DIR
The include directory for protocol buffers
Protobuf_PROTOC_EXECUTABLE
The protoc compiler
Protobuf_LIBRARY_DEBUG
The protobuf library (debug)
Protobuf_PROTOC_LIBRARY_DEBUG
The protoc library (debug)
Protobuf_LITE_LIBRARY
The protobuf lite library
Protobuf_LITE_LIBRARY_DEBUG
The protobuf lite library (debug)

Example:

find_package(Protobuf REQUIRED)
include_directories(${Protobuf_INCLUDE_DIRS})
include_directories(${CMAKE_CURRENT_BINARY_DIR})
protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS foo.proto)
protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS EXPORT_MACRO DLL_EXPORT foo.proto)
protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS DESCRIPTORS PROTO_DESCS foo.proto)
protobuf_generate_python(PROTO_PY foo.proto)
add_executable(bar bar.cc ${PROTO_SRCS} ${PROTO_HDRS})
target_link_libraries(bar ${Protobuf_LIBRARIES})

Note

The protobuf_generate_cpp and protobuf_generate_python functions and add_executable() or add_library() calls only work properly within the same directory.

protobuf_generate_cpp

Add custom commands to process .proto files to C++:

protobuf_generate_cpp (<SRCS> <HDRS>
    [DESCRIPTORS <DESC>] [EXPORT_MACRO <MACRO>] [<ARGN>...])
SRCS
Variable to define with autogenerated source files
HDRS
Variable to define with autogenerated header files
DESCRIPTORS
Variable to define with autogenerated descriptor files, if requested.
EXPORT_MACRO
is a macro which should expand to __declspec(dllexport) or __declspec(dllimport) depending on what is being compiled.
ARGN
.proto files
protobuf_generate_python

Add custom commands to process .proto files to Python:

protobuf_generate_python (<PY> [<ARGN>...])
PY
Variable to define with autogenerated Python files
ARGN
.proto filess

  • cmake-modules(7) »


FindPython — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPython

Find Python interpreter, compiler and development environment (include directories and libraries).

Three components are supported:

  • Interpreter: search for Python interpreter.
  • Compiler: search for Python compiler. Only offered by IronPython.
  • Development: search for development artifacts (include directories and libraries).
  • NumPy: search for NumPy include directories.

If no COMPONENTS is specified, Interpreter is assumed.

To ensure consistent versions between components Interpreter, Compiler, Development and NumPy, specify all components at the same time:

find_package (Python COMPONENTS Interpreter Development)

This module looks preferably for version 3 of Python. If not found, version 2 is searched. To manage concurrent versions 3 and 2 of Python, use FindPython3 and FindPython2 modules rather than this one.

Imported Targets

This module defines the following Imported Targets (when CMAKE_ROLE is PROJECT):

Python::Interpreter
Python interpreter. Target defined if component Interpreter is found.
Python::Compiler
Python compiler. Target defined if component Compiler is found.
Python::Python
Python library. Target defined if component Development is found.
Python::NumPy
NumPy Python library. Target defined if component NumPy is found.

Result Variables

This module will set the following variables in your project (see Standard Variable Names):

Python_FOUND
System has the Python requested components.
Python_Interpreter_FOUND
System has the Python interpreter.
Python_EXECUTABLE
Path to the Python interpreter.
Python_INTERPRETER_ID
A short string unique to the interpreter. Possible values include:
  • Python
  • ActivePython
  • Anaconda
  • Canopy
  • IronPython
Python_STDLIB

Standard platform independent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=True).

Python_STDARCH

Standard platform dependent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=True).

Python_SITELIB

Third-party platform independent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False).

Python_SITEARCH

Third-party platform dependent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=False).

Python_Compiler_FOUND
System has the Python compiler.
Python_COMPILER
Path to the Python compiler. Only offered by IronPython.
Python_COMPILER_ID
A short string unique to the compiler. Possible values include:
  • IronPython
Python_Development_FOUND
System has the Python development artifacts.
Python_INCLUDE_DIRS
The Python include directories.
Python_LIBRARIES
The Python libraries.
Python_LIBRARY_DIRS
The Python library directories.
Python_RUNTIME_LIBRARY_DIRS
The Python runtime library directories.
Python_VERSION
Python version.
Python_VERSION_MAJOR
Python major version.
Python_VERSION_MINOR
Python minor version.
Python_VERSION_PATCH
Python patch version.
Python_NumPy_FOUND
System has the NumPy.
Python_NumPy_INCLUDE_DIRS
The NumPy include directries.
Python_NumPy_VERSION
The NumPy version.

Hints

Python_ROOT_DIR
Define the root directory of a Python installation.
Python_USE_STATIC_LIBS
  • If not defined, search for shared libraries and static libraries in that order.
  • If set to TRUE, search only for static libraries.
  • If set to FALSE, search only for shared libraries.
Python_FIND_REGISTRY

On Windows the Python_FIND_REGISTRY variable determine the order of preference between registry and environment variables. the Python_FIND_REGISTRY variable can be set to empty or one of the following:

  • FIRST: Try to use registry before environment variables. This is the default.
  • LAST: Try to use registry after environment variables.
  • NEVER: Never try to use registry.
CMAKE_FIND_FRAMEWORK

On OS X the CMAKE_FIND_FRAMEWORK variable determine the order of preference between Apple-style and unix-style package components.

Note

Value ONLY is not supported so FIRST will be used instead.

Note

If a Python virtual environment is configured, set variable Python_FIND_REGISTRY (Windows) or CMAKE_FIND_FRAMEWORK (macOS) with value LAST or NEVER to select it preferably.

Commands

This module defines the command Python_add_library (when CMAKE_ROLE is PROJECT), which has the same semantics as add_library(), but takes care of Python module naming rules (only applied if library is of type MODULE), and adds a dependency to target Python::Python:

Python_add_library (my_module MODULE src1.cpp)

If library type is not specified, MODULE is assumed.

  • cmake-modules(7) »


FindPython2 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPython2

Find Python 2 interpreter, compiler and development environment (include directories and libraries).

Three components are supported:

  • Interpreter: search for Python 2 interpreter
  • Compiler: search for Python 2 compiler. Only offered by IronPython.
  • Development: search for development artifacts (include directories and libraries)
  • NumPy: search for NumPy include directories.

If no COMPONENTS is specified, Interpreter is assumed.

To ensure consistent versions between components Interpreter, Compiler, Development and NumPy, specify all components at the same time:

find_package (Python2 COMPONENTS Interpreter Development)

This module looks only for version 2 of Python. This module can be used concurrently with FindPython3 module to use both Python versions.

The FindPython module can be used if Python version does not matter for you.

Imported Targets

This module defines the following Imported Targets (when CMAKE_ROLE is PROJECT):

Python2::Interpreter
Python 2 interpreter. Target defined if component Interpreter is found.
Python2::Compiler
Python 2 compiler. Target defined if component Compiler is found.
Python2::Python
Python 2 library. Target defined if component Development is found.
Python2::NumPy
NumPy library for Python 2. Target defined if component NumPy is found.

Result Variables

This module will set the following variables in your project (see Standard Variable Names):

Python2_FOUND
System has the Python 2 requested components.
Python2_Interpreter_FOUND
System has the Python 2 interpreter.
Python2_EXECUTABLE
Path to the Python 2 interpreter.
Python2_INTERPRETER_ID
A short string unique to the interpreter. Possible values include:
  • Python
  • ActivePython
  • Anaconda
  • Canopy
  • IronPython
Python2_STDLIB

Standard platform independent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=True).

Python2_STDARCH

Standard platform dependent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=True).

Python2_SITELIB

Third-party platform independent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False).

Python2_SITEARCH

Third-party platform dependent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=False).

Python2_Compiler_FOUND
System has the Python 2 compiler.
Python2_COMPILER
Path to the Python 2 compiler. Only offered by IronPython.
Python2_COMPILER_ID
A short string unique to the compiler. Possible values include:
  • IronPython
Python2_Development_FOUND
System has the Python 2 development artifacts.
Python2_INCLUDE_DIRS
The Python 2 include directories.
Python2_LIBRARIES
The Python 2 libraries.
Python2_LIBRARY_DIRS
The Python 2 library directories.
Python2_RUNTIME_LIBRARY_DIRS
The Python 2 runtime library directories.
Python2_VERSION
Python 2 version.
Python2_VERSION_MAJOR
Python 2 major version.
Python2_VERSION_MINOR
Python 2 minor version.
Python2_VERSION_PATCH
Python 2 patch version.
Python2_NumPy_FOUND
System has the NumPy.
Python2_NumPy_INCLUDE_DIRS
The NumPy include directries.
Python2_NumPy_VERSION
The NumPy version.

Hints

Python2_ROOT_DIR
Define the root directory of a Python 2 installation.
Python2_USE_STATIC_LIBS
  • If not defined, search for shared libraries and static libraries in that order.
  • If set to TRUE, search only for static libraries.
  • If set to FALSE, search only for shared libraries.
Python2_FIND_REGISTRY

On Windows the Python2_FIND_REGISTRY variable determine the order of preference between registry and environment variables. the Python2_FIND_REGISTRY variable can be set to empty or one of the following:

  • FIRST: Try to use registry before environment variables. This is the default.
  • LAST: Try to use registry after environment variables.
  • NEVER: Never try to use registry.
CMAKE_FIND_FRAMEWORK

On macOS the CMAKE_FIND_FRAMEWORK variable determine the order of preference between Apple-style and unix-style package components.

Note

Value ONLY is not supported so FIRST will be used instead.

Note

If a Python virtual environment is configured, set variable Python_FIND_REGISTRY (Windows) or CMAKE_FIND_FRAMEWORK (macOS) with value LAST or NEVER to select it preferably.

Commands

This module defines the command Python2_add_library (when CMAKE_ROLE is PROJECT), which has the same semantics as add_library(), but takes care of Python module naming rules (only applied if library is of type MODULE), and adds a dependency to target Python2::Python:

Python2_add_library (my_module MODULE src1.cpp)

If library type is not specified, MODULE is assumed.

  • cmake-modules(7) »


FindPython3 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPython3

Find Python 3 interpreter, compiler and development environment (include directories and libraries).

Three components are supported:

  • Interpreter: search for Python 3 interpreter
  • Compiler: search for Python 3 compiler. Only offered by IronPython.
  • Development: search for development artifacts (include directories and libraries)
  • NumPy: search for NumPy include directories.

If no COMPONENTS is specified, Interpreter is assumed.

To ensure consistent versions between components Interpreter, Compiler, Development and NumPy, specify all components at the same time:

find_package (Python3 COMPONENTS Interpreter Development)

This module looks only for version 3 of Python. This module can be used concurrently with FindPython2 module to use both Python versions.

The FindPython module can be used if Python version does not matter for you.

Imported Targets

This module defines the following Imported Targets (when CMAKE_ROLE is PROJECT):

Python3::Interpreter
Python 3 interpreter. Target defined if component Interpreter is found.
Python3::Compiler
Python 3 compiler. Target defined if component Compiler is found.
Python3::Python
Python 3 library. Target defined if component Development is found.
Python3::NumPy
NumPy library for Python 3. Target defined if component NumPy is found.

Result Variables

This module will set the following variables in your project (see Standard Variable Names):

Python3_FOUND
System has the Python 3 requested components.
Python3_Interpreter_FOUND
System has the Python 3 interpreter.
Python3_EXECUTABLE
Path to the Python 3 interpreter.
Python3_INTERPRETER_ID
A short string unique to the interpreter. Possible values include:
  • Python
  • ActivePython
  • Anaconda
  • Canopy
  • IronPython
Python3_STDLIB

Standard platform independent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=True).

Python3_STDARCH

Standard platform dependent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=True).

Python3_SITELIB

Third-party platform independent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False).

Python3_SITEARCH

Third-party platform dependent installation directory.

Information returned by distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=False).

Python3_Compiler_FOUND
System has the Python 3 compiler.
Python3_COMPILER
Path to the Python 3 compiler. Only offered by IronPython.
Python3_COMPILER_ID
A short string unique to the compiler. Possible values include:
  • IronPython
Python3_Development_FOUND
System has the Python 3 development artifacts.
Python3_INCLUDE_DIRS
The Python 3 include directories.
Python3_LIBRARIES
The Python 3 libraries.
Python3_LIBRARY_DIRS
The Python 3 library directories.
Python3_RUNTIME_LIBRARY_DIRS
The Python 3 runtime library directories.
Python3_VERSION
Python 3 version.
Python3_VERSION_MAJOR
Python 3 major version.
Python3_VERSION_MINOR
Python 3 minor version.
Python3_VERSION_PATCH
Python 3 patch version.
Python3_NumPy_FOUND
System has the NumPy.
Python3_NumPy_INCLUDE_DIRS
The NumPy include directries.
Python3_NumPy_VERSION
The NumPy version.

Hints

Python3_ROOT_DIR
Define the root directory of a Python 3 installation.
Python3_USE_STATIC_LIBS
  • If not defined, search for shared libraries and static libraries in that order.
  • If set to TRUE, search only for static libraries.
  • If set to FALSE, search only for shared libraries.
Python3_FIND_REGISTRY

On Windows the Python3_FIND_REGISTRY variable determine the order of preference between registry and environment variables. the Python3_FIND_REGISTRY variable can be set to empty or one of the following:

  • FIRST: Try to use registry before environment variables. This is the default.
  • LAST: Try to use registry after environment variables.
  • NEVER: Never try to use registry.
CMAKE_FIND_FRAMEWORK

On OS X the CMAKE_FIND_FRAMEWORK variable determine the order of preference between Apple-style and unix-style package components.

Note

Value ONLY is not supported so FIRST will be used instead.

Note

If a Python virtual environment is configured, set variable Python_FIND_REGISTRY (Windows) or CMAKE_FIND_FRAMEWORK (macOS) with value LAST or NEVER to select it preferably.

Commands

This module defines the command Python3_add_library (when CMAKE_ROLE is PROJECT), which has the same semantics as add_library(), but takes care of Python module naming rules (only applied if library is of type MODULE), and adds a dependency to target Python3::Python:

Python3_add_library (my_module MODULE src1.cpp)

If library type is not specified, MODULE is assumed.

  • cmake-modules(7) »


FindQt3 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindQt3

Locate Qt include paths and libraries

This module defines:

QT_INCLUDE_DIR    - where to find qt.h, etc.
QT_LIBRARIES      - the libraries to link against to use Qt.
QT_DEFINITIONS    - definitions to use when
                    compiling code that uses Qt.
QT_FOUND          - If false, don't try to use Qt.
QT_VERSION_STRING - the version of Qt found

If you need the multithreaded version of Qt, set QT_MT_REQUIRED to TRUE

Also defined, but not for general use are:

QT_MOC_EXECUTABLE, where to find the moc tool.
QT_UIC_EXECUTABLE, where to find the uic tool.
QT_QT_LIBRARY, where to find the Qt library.
QT_QTMAIN_LIBRARY, where to find the qtmain
 library. This is only required by Qt3 on Windows.

  • cmake-modules(7) »


FindQt4 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindQt4

Finding and Using Qt4

This module can be used to find Qt4. The most important issue is that the Qt4 qmake is available via the system path. This qmake is then used to detect basically everything else. This module defines a number of IMPORTED targets, macros and variables.

Typical usage could be something like:

set(CMAKE_AUTOMOC ON)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
find_package(Qt4 4.4.3 REQUIRED QtGui QtXml)
add_executable(myexe main.cpp)
target_link_libraries(myexe Qt4::QtGui Qt4::QtXml)

Note

When using IMPORTED targets, the qtmain.lib static library is automatically linked on Windows for WIN32 executables. To disable that globally, set the QT4_NO_LINK_QTMAIN variable before finding Qt4. To disable that for a particular executable, set the QT4_NO_LINK_QTMAIN target property to TRUE on the executable.

Qt Build Tools

Qt relies on some bundled tools for code generation, such as moc for meta-object code generation,``uic`` for widget layout and population, and rcc for virtual filesystem content generation. These tools may be automatically invoked by cmake(1) if the appropriate conditions are met. See cmake-qt(7) for more.

Qt Macros

In some cases it can be necessary or useful to invoke the Qt build tools in a more-manual way. Several macros are available to add targets for such uses.

macro QT4_WRAP_CPP(outfiles inputfile ... [TARGET tgt] OPTIONS ...)
      create moc code from a list of files containing Qt class with
      the Q_OBJECT declaration.  Per-directory preprocessor definitions
      are also added.  If the <tgt> is specified, the
      INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS from
      the <tgt> are passed to moc.  Options may be given to moc, such as
      those found when executing "moc -help".

macro QT4_WRAP_UI(outfiles inputfile ... OPTIONS ...)
      create code from a list of Qt designer ui files.
      Options may be given to uic, such as those found
      when executing "uic -help"

macro QT4_ADD_RESOURCES(outfiles inputfile ... OPTIONS ...)
      create code from a list of Qt resource files.
      Options may be given to rcc, such as those found
      when executing "rcc -help"

macro QT4_GENERATE_MOC(inputfile outputfile [TARGET tgt])
      creates a rule to run moc on infile and create outfile.
      Use this if for some reason QT4_WRAP_CPP() isn't appropriate, e.g.
      because you need a custom filename for the moc file or something
      similar.  If the <tgt> is specified, the
      INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS from
      the <tgt> are passed to moc.

macro QT4_ADD_DBUS_INTERFACE(outfiles interface basename)
      Create the interface header and implementation files with the
      given basename from the given interface xml file and add it to
      the list of sources.

      You can pass additional parameters to the qdbusxml2cpp call by setting
      properties on the input file:

      INCLUDE the given file will be included in the generate interface header

      CLASSNAME the generated class is named accordingly

      NO_NAMESPACE the generated class is not wrapped in a namespace

macro QT4_ADD_DBUS_INTERFACES(outfiles inputfile ... )
      Create the interface header and implementation files
      for all listed interface xml files.
      The basename will be automatically determined from the name
      of the xml file.

      The source file properties described for
      QT4_ADD_DBUS_INTERFACE also apply here.

macro QT4_ADD_DBUS_ADAPTOR(outfiles xmlfile parentheader parentclassname
                           [basename] [classname])
      create a dbus adaptor (header and implementation file) from the xml file
      describing the interface, and add it to the list of sources. The adaptor
      forwards the calls to a parent class, defined in parentheader and named
      parentclassname. The name of the generated files will be
      <basename>adaptor.{cpp,h} where basename defaults to the basename of the
      xml file.
      If <classname> is provided, then it will be used as the classname of the
      adaptor itself.

macro QT4_GENERATE_DBUS_INTERFACE( header [interfacename] OPTIONS ...)
      generate the xml interface file from the given header.
      If the optional argument interfacename is omitted, the name of the
      interface file is constructed from the basename of the header with
      the suffix .xml appended.
      Options may be given to qdbuscpp2xml, such as those found when
      executing "qdbuscpp2xml --help"

macro QT4_CREATE_TRANSLATION( qm_files directories ... sources ...
                              ts_files ... OPTIONS ...)
      out: qm_files
      in:  directories sources ts_files
      options: flags to pass to lupdate, such as -extensions to specify
      extensions for a directory scan.
      generates commands to create .ts (vie lupdate) and .qm
      (via lrelease) - files from directories and/or sources. The ts files are
      created and/or updated in the source tree (unless given with full paths).
      The qm files are generated in the build tree.
      Updating the translations can be done by adding the qm_files
      to the source list of your library/executable, so they are
      always updated, or by adding a custom target to control when
      they get updated/generated.

macro QT4_ADD_TRANSLATION( qm_files ts_files ... )
      out: qm_files
      in:  ts_files
      generates commands to create .qm from .ts - files. The generated
      filenames can be found in qm_files. The ts_files
      must exist and are not updated in any way.

macro QT4_AUTOMOC(sourcefile1 sourcefile2 ... [TARGET tgt])
      The qt4_automoc macro is obsolete.  Use the CMAKE_AUTOMOC feature instead.
      This macro is still experimental.
      It can be used to have moc automatically handled.
      So if you have the files foo.h and foo.cpp, and in foo.h a
      a class uses the Q_OBJECT macro, moc has to run on it. If you don't
      want to use QT4_WRAP_CPP() (which is reliable and mature), you can insert
      #include "foo.moc"
      in foo.cpp and then give foo.cpp as argument to QT4_AUTOMOC(). This will
      scan all listed files at cmake-time for such included moc files and if it
      finds them cause a rule to be generated to run moc at build time on the
      accompanying header file foo.h.
      If a source file has the SKIP_AUTOMOC property set it will be ignored by
      this macro.
      If the <tgt> is specified, the INTERFACE_INCLUDE_DIRECTORIES and
      INTERFACE_COMPILE_DEFINITIONS from the <tgt> are passed to moc.

function QT4_USE_MODULES( target [link_type] modules...)
       This function is obsolete. Use target_link_libraries with IMPORTED targets
       instead.
       Make <target> use the <modules> from Qt. Using a Qt module means
       to link to the library, add the relevant include directories for the
       module, and add the relevant compiler defines for using the module.
       Modules are roughly equivalent to components of Qt4, so usage would be
       something like:
        qt4_use_modules(myexe Core Gui Declarative)
       to use QtCore, QtGui and QtDeclarative. The optional <link_type> argument
       can be specified as either LINK_PUBLIC or LINK_PRIVATE to specify the
       same argument to the target_link_libraries call.

IMPORTED Targets

A particular Qt library may be used by using the corresponding IMPORTED target with the target_link_libraries() command:

target_link_libraries(myexe Qt4::QtGui Qt4::QtXml)

Using a target in this way causes :cmake(1)` to use the appropriate include directories and compile definitions for the target when compiling myexe.

Targets are aware of their dependencies, so for example it is not necessary to list Qt4::QtCore if another Qt library is listed, and it is not necessary to list Qt4::QtGui if Qt4::QtDeclarative is listed. Targets may be tested for existence in the usual way with the if(TARGET) command.

The Qt toolkit may contain both debug and release libraries. cmake(1) will choose the appropriate version based on the build configuration.

Qt4::QtCore
The QtCore target
Qt4::QtGui
The QtGui target
Qt4::Qt3Support
The Qt3Support target
Qt4::QtAssistant
The QtAssistant target
Qt4::QtAssistantClient
The QtAssistantClient target
Qt4::QAxContainer
The QAxContainer target (Windows only)
Qt4::QAxServer
The QAxServer target (Windows only)
Qt4::QtDBus
The QtDBus target
Qt4::QtDeclarative
The QtDeclarative target
Qt4::QtDesigner
The QtDesigner target
Qt4::QtDesignerComponents
The QtDesignerComponents target
Qt4::QtHelp
The QtHelp target
Qt4::QtMotif
The QtMotif target
Qt4::QtMultimedia
The QtMultimedia target
Qt4::QtNetwork
The QtNetwork target
Qt4::QtNsPLugin
The QtNsPLugin target
Qt4::QtOpenGL
The QtOpenGL target
Qt4::QtScript
The QtScript target
Qt4::QtScriptTools
The QtScriptTools target
Qt4::QtSql
The QtSql target
Qt4::QtSvg
The QtSvg target
Qt4::QtTest
The QtTest target
Qt4::QtUiTools
The QtUiTools target
Qt4::QtWebKit
The QtWebKit target
Qt4::QtXml
The QtXml target
Qt4::QtXmlPatterns
The QtXmlPatterns target
Qt4::phonon
The phonon target

Result Variables

Below is a detailed list of variables that FindQt4.cmake sets.
Qt4_FOUND
If false, don’t try to use Qt 4.
QT_FOUND
If false, don’t try to use Qt. This variable is for compatibility only.
QT4_FOUND
If false, don’t try to use Qt 4. This variable is for compatibility only.
QT_VERSION_MAJOR
The major version of Qt found.
QT_VERSION_MINOR
The minor version of Qt found.
QT_VERSION_PATCH
The patch version of Qt found.

  • cmake-modules(7) »


FindQuickTime — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindQuickTime

Locate QuickTime This module defines QUICKTIME_LIBRARY QUICKTIME_FOUND, if false, do not try to link to gdal QUICKTIME_INCLUDE_DIR, where to find the headers

$QUICKTIME_DIR is an environment variable that would correspond to the ./configure –prefix=$QUICKTIME_DIR

Created by Eric Wing.

  • cmake-modules(7) »


FindRTI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindRTI

Try to find M&S HLA RTI libraries

This module finds if any HLA RTI is installed and locates the standard RTI include files and libraries.

RTI is a simulation infrastructure standardized by IEEE and SISO. It has a well defined C++ API that assures that simulation applications are independent on a particular RTI implementation.

http://en.wikipedia.org/wiki/Run-Time_Infrastructure_(simulation)

This code sets the following variables:

RTI_INCLUDE_DIR = the directory where RTI includes file are found
RTI_LIBRARIES = The libraries to link against to use RTI
RTI_DEFINITIONS = -DRTI_USES_STD_FSTREAM
RTI_FOUND = Set to FALSE if any HLA RTI was not found

Report problems to <certi-devel@nongnu.org>

  • cmake-modules(7) »


FindRuby — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindRuby

Find Ruby

This module finds if Ruby is installed and determines where the include files and libraries are. Ruby 1.8, 1.9, 2.0 and 2.1 are supported.

The minimum required version of Ruby can be specified using the standard syntax, e.g. find_package(Ruby 1.8)

It also determines what the name of the library is. This code sets the following variables:

RUBY_EXECUTABLE
full path to the ruby binary
RUBY_INCLUDE_DIRS
include dirs to be used when using the ruby library
RUBY_LIBRARY
full path to the ruby library
RUBY_VERSION
the version of ruby which was found, e.g. “1.8.7”
RUBY_FOUND
set to true if ruby ws found successfully

Also:

RUBY_INCLUDE_PATH
same as RUBY_INCLUDE_DIRS, only provided for compatibility reasons, don’t use it

  • cmake-modules(7) »


FindSDL_image — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSDL_image

Locate SDL_image library

This module defines:

SDL_IMAGE_LIBRARIES, the name of the library to link against
SDL_IMAGE_INCLUDE_DIRS, where to find the headers
SDL_IMAGE_FOUND, if false, do not try to link against
SDL_IMAGE_VERSION_STRING - human-readable string containing the
                           version of SDL_image

For backward compatibility the following variables are also set:

SDLIMAGE_LIBRARY (same value as SDL_IMAGE_LIBRARIES)
SDLIMAGE_INCLUDE_DIR (same value as SDL_IMAGE_INCLUDE_DIRS)
SDLIMAGE_FOUND (same value as SDL_IMAGE_FOUND)

$SDLDIR is an environment variable that would correspond to the ./configure –prefix=$SDLDIR used in building SDL.

Created by Eric Wing. This was influenced by the FindSDL.cmake module, but with modifications to recognize OS X frameworks and additional Unix paths (FreeBSD, etc).

  • cmake-modules(7) »


FindSDL_mixer — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSDL_mixer

Locate SDL_mixer library

This module defines:

SDL_MIXER_LIBRARIES, the name of the library to link against
SDL_MIXER_INCLUDE_DIRS, where to find the headers
SDL_MIXER_FOUND, if false, do not try to link against
SDL_MIXER_VERSION_STRING - human-readable string containing the
                           version of SDL_mixer

For backward compatibility the following variables are also set:

SDLMIXER_LIBRARY (same value as SDL_MIXER_LIBRARIES)
SDLMIXER_INCLUDE_DIR (same value as SDL_MIXER_INCLUDE_DIRS)
SDLMIXER_FOUND (same value as SDL_MIXER_FOUND)

$SDLDIR is an environment variable that would correspond to the ./configure –prefix=$SDLDIR used in building SDL.

Created by Eric Wing. This was influenced by the FindSDL.cmake module, but with modifications to recognize OS X frameworks and additional Unix paths (FreeBSD, etc).

  • cmake-modules(7) »


FindSDL_net — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSDL_net

Locate SDL_net library

This module defines:

SDL_NET_LIBRARIES, the name of the library to link against
SDL_NET_INCLUDE_DIRS, where to find the headers
SDL_NET_FOUND, if false, do not try to link against
SDL_NET_VERSION_STRING - human-readable string containing the version of SDL_net

For backward compatibility the following variables are also set:

SDLNET_LIBRARY (same value as SDL_NET_LIBRARIES)
SDLNET_INCLUDE_DIR (same value as SDL_NET_INCLUDE_DIRS)
SDLNET_FOUND (same value as SDL_NET_FOUND)

$SDLDIR is an environment variable that would correspond to the ./configure –prefix=$SDLDIR used in building SDL.

Created by Eric Wing. This was influenced by the FindSDL.cmake module, but with modifications to recognize OS X frameworks and additional Unix paths (FreeBSD, etc).

  • cmake-modules(7) »


FindSDL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSDL

Locate SDL library

This module defines

SDL_LIBRARY, the name of the library to link against
SDL_FOUND, if false, do not try to link to SDL
SDL_INCLUDE_DIR, where to find SDL.h
SDL_VERSION_STRING, human-readable string containing the version of SDL

This module responds to the flag:

SDL_BUILDING_LIBRARY
  If this is defined, then no SDL_main will be linked in because
  only applications need main().
  Otherwise, it is assumed you are building an application and this
  module will attempt to locate and set the proper link flags
  as part of the returned SDL_LIBRARY variable.

Don’t forget to include SDLmain.h and SDLmain.m your project for the OS X framework based version. (Other versions link to -lSDLmain which this module will try to find on your behalf.) Also for OS X, this module will automatically add the -framework Cocoa on your behalf.

Additional Note: If you see an empty SDL_LIBRARY_TEMP in your configuration and no SDL_LIBRARY, it means CMake did not find your SDL library (SDL.dll, libsdl.so, SDL.framework, etc). Set SDL_LIBRARY_TEMP to point to your SDL library, and configure again. Similarly, if you see an empty SDLMAIN_LIBRARY, you should set this value as appropriate. These values are used to generate the final SDL_LIBRARY variable, but when these values are unset, SDL_LIBRARY does not get created.

$SDLDIR is an environment variable that would correspond to the ./configure –prefix=$SDLDIR used in building SDL. l.e.galup 9-20-02

Modified by Eric Wing. Added code to assist with automated building by using environmental variables and providing a more controlled/consistent search behavior. Added new modifications to recognize OS X frameworks and additional Unix paths (FreeBSD, etc). Also corrected the header search path to follow “proper” SDL guidelines. Added a search for SDLmain which is needed by some platforms. Added a search for threads which is needed by some platforms. Added needed compile switches for MinGW.

On OSX, this will prefer the Framework version (if found) over others. People will have to manually change the cache values of SDL_LIBRARY to override this selection or set the CMake environment CMAKE_INCLUDE_PATH to modify the search paths.

Note that the header path has changed from SDL/SDL.h to just SDL.h This needed to change because “proper” SDL convention is #include “SDL.h”, not <SDL/SDL.h>. This is done for portability reasons because not all systems place things in SDL/ (see FreeBSD).

  • cmake-modules(7) »


FindSDL_sound — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSDL_sound

Locates the SDL_sound library

This module depends on SDL being found and must be called AFTER FindSDL.cmake is called.

This module defines

SDL_SOUND_INCLUDE_DIR, where to find SDL_sound.h
SDL_SOUND_FOUND, if false, do not try to link to SDL_sound
SDL_SOUND_LIBRARIES, this contains the list of libraries that you need
  to link against.
SDL_SOUND_EXTRAS, this is an optional variable for you to add your own
  flags to SDL_SOUND_LIBRARIES. This is prepended to SDL_SOUND_LIBRARIES.
  This is available mostly for cases this module failed to anticipate for
  and you must add additional flags. This is marked as ADVANCED.
SDL_SOUND_VERSION_STRING, human-readable string containing the
  version of SDL_sound

This module also defines (but you shouldn’t need to use directly)

SDL_SOUND_LIBRARY, the name of just the SDL_sound library you would link
against. Use SDL_SOUND_LIBRARIES for you link instructions and not this one.

And might define the following as needed

MIKMOD_LIBRARY
MODPLUG_LIBRARY
OGG_LIBRARY
VORBIS_LIBRARY
SMPEG_LIBRARY
FLAC_LIBRARY
SPEEX_LIBRARY

Typically, you should not use these variables directly, and you should use SDL_SOUND_LIBRARIES which contains SDL_SOUND_LIBRARY and the other audio libraries (if needed) to successfully compile on your system.

Created by Eric Wing. This module is a bit more complicated than the other FindSDL* family modules. The reason is that SDL_sound can be compiled in a large variety of different ways which are independent of platform. SDL_sound may dynamically link against other 3rd party libraries to get additional codec support, such as Ogg Vorbis, SMPEG, ModPlug, MikMod, FLAC, Speex, and potentially others. Under some circumstances which I don’t fully understand, there seems to be a requirement that dependent libraries of libraries you use must also be explicitly linked against in order to successfully compile. SDL_sound does not currently have any system in place to know how it was compiled. So this CMake module does the hard work in trying to discover which 3rd party libraries are required for building (if any). This module uses a brute force approach to create a test program that uses SDL_sound, and then tries to build it. If the build fails, it parses the error output for known symbol names to figure out which libraries are needed.

Responds to the $SDLDIR and $SDLSOUNDDIR environmental variable that would correspond to the ./configure –prefix=$SDLDIR used in building SDL.

On OSX, this will prefer the Framework version (if found) over others. People will have to manually change the cache values of SDL_LIBRARY to override this selectionor set the CMake environment CMAKE_INCLUDE_PATH to modify the search paths.

  • cmake-modules(7) »


FindSDL_ttf — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSDL_ttf

Locate SDL_ttf library

This module defines:

SDL_TTF_LIBRARIES, the name of the library to link against
SDL_TTF_INCLUDE_DIRS, where to find the headers
SDL_TTF_FOUND, if false, do not try to link against
SDL_TTF_VERSION_STRING - human-readable string containing the version of SDL_ttf

For backward compatibility the following variables are also set:

SDLTTF_LIBRARY (same value as SDL_TTF_LIBRARIES)
SDLTTF_INCLUDE_DIR (same value as SDL_TTF_INCLUDE_DIRS)
SDLTTF_FOUND (same value as SDL_TTF_FOUND)

$SDLDIR is an environment variable that would correspond to the ./configure –prefix=$SDLDIR used in building SDL.

Created by Eric Wing. This was influenced by the FindSDL.cmake module, but with modifications to recognize OS X frameworks and additional Unix paths (FreeBSD, etc).

  • cmake-modules(7) »


FindSelfPackers — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSelfPackers

Find upx

This module looks for some executable packers (i.e. software that compress executables or shared libs into on-the-fly self-extracting executables or shared libs. Examples:

UPX: http://wildsau.idv.uni-linz.ac.at/mfx/upx.html

  • cmake-modules(7) »


FindSquish — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSquish

– Typical Use

This module can be used to find Squish. Currently Squish versions 3 and 4 are supported.

SQUISH_FOUND                    If false, don't try to use Squish
SQUISH_VERSION                  The full version of Squish found
SQUISH_VERSION_MAJOR            The major version of Squish found
SQUISH_VERSION_MINOR            The minor version of Squish found
SQUISH_VERSION_PATCH            The patch version of Squish found

SQUISH_INSTALL_DIR              The Squish installation directory
                                (containing bin, lib, etc)
SQUISH_SERVER_EXECUTABLE        The squishserver executable
SQUISH_CLIENT_EXECUTABLE        The squishrunner executable

SQUISH_INSTALL_DIR_FOUND        Was the install directory found?
SQUISH_SERVER_EXECUTABLE_FOUND  Was the server executable found?
SQUISH_CLIENT_EXECUTABLE_FOUND  Was the client executable found?

It provides the function squish_v4_add_test() for adding a squish test to cmake using Squish 4.x:

squish_v4_add_test(cmakeTestName
  AUT targetName SUITE suiteName TEST squishTestName
  [SETTINGSGROUP group] [PRE_COMMAND command] [POST_COMMAND command] )

The arguments have the following meaning:

cmakeTestName
this will be used as the first argument for add_test()
AUT targetName
the name of the cmake target which will be used as AUT, i.e. the executable which will be tested.
SUITE suiteName
this is either the full path to the squish suite, or just the last directory of the suite, i.e. the suite name. In this case the CMakeLists.txt which calls squish_add_test() must be located in the parent directory of the suite directory.
TEST squishTestName
the name of the squish test, i.e. the name of the subdirectory of the test inside the suite directory.
SETTINGSGROUP group
if specified, the given settings group will be used for executing the test. If not specified, the groupname will be “CTest_<username>”
PRE_COMMAND command
if specified, the given command will be executed before starting the squish test.
POST_COMMAND command
same as PRE_COMMAND, but after the squish test has been executed.
enable_testing()
find_package(Squish 4.0)
if (SQUISH_FOUND)
   squish_v4_add_test(myTestName
     AUT myApp
     SUITE ${CMAKE_SOURCE_DIR}/tests/mySuite
     TEST someSquishTest
     SETTINGSGROUP myGroup
     )
endif ()

For users of Squish version 3.x the macro squish_v3_add_test() is provided:

squish_v3_add_test(testName applicationUnderTest testCase envVars testWrapper)
Use this macro to add a test using Squish 3.x.

enable_testing()
find_package(Squish)
if (SQUISH_FOUND)
  squish_v3_add_test(myTestName myApplication testCase envVars testWrapper)
endif ()

macro SQUISH_ADD_TEST(testName applicationUnderTest testCase envVars testWrapper)

This is deprecated. Use SQUISH_V3_ADD_TEST() if you are using Squish 3.x instead.

  • cmake-modules(7) »


FindSQLite3 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSQLite3

Find the SQLite libraries, v3

IMPORTED targets

This module defines the following IMPORTED target:

SQLite::SQLite3

Result variables

This module will set the following variables if found:

SQLite3_INCLUDE_DIRS
where to find sqlite3.h, etc.
SQLite3_LIBRARIES
the libraries to link against to use SQLite3.
SQLite3_VERSION
version of the SQLite3 library found
SQLite3_FOUND
TRUE if found

  • cmake-modules(7) »


FindSubversion — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSubversion

Extract information from a subversion working copy

The module defines the following variables:

Subversion_SVN_EXECUTABLE - path to svn command line client
Subversion_VERSION_SVN - version of svn command line client
Subversion_FOUND - true if the command line client was found
SUBVERSION_FOUND - same as Subversion_FOUND, set for compatibility reasons

The minimum required version of Subversion can be specified using the standard syntax, e.g. find_package(Subversion 1.4).

If the command line client executable is found two macros are defined:

Subversion_WC_INFO(<dir> <var-prefix> [IGNORE_SVN_FAILURE])
Subversion_WC_LOG(<dir> <var-prefix>)

Subversion_WC_INFO extracts information of a subversion working copy at a given location. This macro defines the following variables if running Subversion’s info command on <dir> succeeds; otherwise a SEND_ERROR message is generated. The error can be ignored by providing the IGNORE_SVN_FAILURE option, which causes these variables to remain undefined.

<var-prefix>_WC_URL - url of the repository (at <dir>)
<var-prefix>_WC_ROOT - root url of the repository
<var-prefix>_WC_REVISION - current revision
<var-prefix>_WC_LAST_CHANGED_AUTHOR - author of last commit
<var-prefix>_WC_LAST_CHANGED_DATE - date of last commit
<var-prefix>_WC_LAST_CHANGED_REV - revision of last commit
<var-prefix>_WC_INFO - output of command `svn info <dir>'

Subversion_WC_LOG retrieves the log message of the base revision of a subversion working copy at a given location. This macro defines the variable:

<var-prefix>_LAST_CHANGED_LOG - last log of base revision

Example usage:

find_package(Subversion)
if(SUBVERSION_FOUND)
  Subversion_WC_INFO(${PROJECT_SOURCE_DIR} Project)
  message("Current revision is ${Project_WC_REVISION}")
  Subversion_WC_LOG(${PROJECT_SOURCE_DIR} Project)
  message("Last changed log is ${Project_LAST_CHANGED_LOG}")
endif()

  • cmake-modules(7) »


FindSWIG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindSWIG

Find SWIG

This module finds an installed SWIG. It sets the following variables:

SWIG_FOUND - set to true if SWIG is found
SWIG_DIR - the directory where swig is installed
SWIG_EXECUTABLE - the path to the swig executable
SWIG_VERSION   - the version number of the swig executable

The minimum required version of SWIG can be specified using the standard syntax, e.g. find_package(SWIG 1.1)

All information is collected from the SWIG_EXECUTABLE so the version to be found can be changed from the command line by means of setting SWIG_EXECUTABLE

  • cmake-modules(7) »


FindTCL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindTCL

TK_INTERNAL_PATH was removed.

This module finds if Tcl is installed and determines where the include files and libraries are. It also determines what the name of the library is. This code sets the following variables:

TCL_FOUND              = Tcl was found
TK_FOUND               = Tk was found
TCLTK_FOUND            = Tcl and Tk were found
TCL_LIBRARY            = path to Tcl library (tcl tcl80)
TCL_INCLUDE_PATH       = path to where tcl.h can be found
TCL_TCLSH              = path to tclsh binary (tcl tcl80)
TK_LIBRARY             = path to Tk library (tk tk80 etc)
TK_INCLUDE_PATH        = path to where tk.h can be found
TK_WISH                = full path to the wish executable

In an effort to remove some clutter and clear up some issues for people who are not necessarily Tcl/Tk gurus/developers, some variables were moved or removed. Changes compared to CMake 2.4 are:

=> they were only useful for people writing Tcl/Tk extensions.
=> these libs are not packaged by default with Tcl/Tk distributions.
   Even when Tcl/Tk is built from source, several flavors of debug libs
   are created and there is no real reason to pick a single one
   specifically (say, amongst tcl84g, tcl84gs, or tcl84sgx).
   Let's leave that choice to the user by allowing him to assign
   TCL_LIBRARY to any Tcl library, debug or not.
=> this ended up being only a Win32 variable, and there is a lot of
   confusion regarding the location of this file in an installed Tcl/Tk
   tree anyway (see 8.5 for example). If you need the internal path at
   this point it is safer you ask directly where the *source* tree is
   and dig from there.

  • cmake-modules(7) »


FindTclsh — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindTclsh

Find tclsh

This module finds if TCL is installed and determines where the include files and libraries are. It also determines what the name of the library is. This code sets the following variables:

TCLSH_FOUND = TRUE if tclsh has been found
TCL_TCLSH = the path to the tclsh executable

In cygwin, look for the cygwin version first. Don’t look for it later to avoid finding the cygwin version on a Win32 build.

  • cmake-modules(7) »


FindTclStub — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindTclStub

TCL_STUB_LIBRARY_DEBUG and TK_STUB_LIBRARY_DEBUG were removed.

This module finds Tcl stub libraries. It first finds Tcl include files and libraries by calling FindTCL.cmake. How to Use the Tcl Stubs Library:

http://tcl.activestate.com/doc/howto/stubs.html

Using Stub Libraries:

http://safari.oreilly.com/0130385603/ch48lev1sec3

This code sets the following variables:

TCL_STUB_LIBRARY       = path to Tcl stub library
TK_STUB_LIBRARY        = path to Tk stub library
TTK_STUB_LIBRARY       = path to ttk stub library

In an effort to remove some clutter and clear up some issues for people who are not necessarily Tcl/Tk gurus/developers, some variables were moved or removed. Changes compared to CMake 2.4 are:

=> these libs are not packaged by default with Tcl/Tk distributions.
   Even when Tcl/Tk is built from source, several flavors of debug libs
   are created and there is no real reason to pick a single one
   specifically (say, amongst tclstub84g, tclstub84gs, or tclstub84sgx).
   Let's leave that choice to the user by allowing him to assign
   TCL_STUB_LIBRARY to any Tcl library, debug or not.

  • cmake-modules(7) »


FindThreads — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindThreads

This module determines the thread library of the system.

The following variables are set

CMAKE_THREAD_LIBS_INIT     - the thread library
CMAKE_USE_WIN32_THREADS_INIT - using WIN32 threads?
CMAKE_USE_PTHREADS_INIT    - are we using pthreads
CMAKE_HP_PTHREADS_INIT     - are we using hp pthreads

The following import target is created

Threads::Threads

If the use of the -pthread compiler and linker flag is preferred then the caller can set

THREADS_PREFER_PTHREAD_FLAG

The compiler flag can only be used with the imported target. Use of both the imported target as well as this switch is highly recommended for new code.

This module is not needed for C++11 and later if threading is done using std::thread from the standard library.

  • cmake-modules(7) »


FindTIFF — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindTIFF

Find the TIFF library (libtiff).

Imported targets

This module defines the following IMPORTED targets:

TIFF::TIFF
The TIFF library, if found.

Result variables

This module will set the following variables in your project:

TIFF_FOUND
true if the TIFF headers and libraries were found
TIFF_INCLUDE_DIR
the directory containing the TIFF headers
TIFF_INCLUDE_DIRS
the directory containing the TIFF headers
TIFF_LIBRARIES
TIFF libraries to be linked

Cache variables

The following cache variables may also be set:

TIFF_INCLUDE_DIR
the directory containing the TIFF headers
TIFF_LIBRARY
the path to the TIFF library

  • cmake-modules(7) »


FindUnixCommands — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindUnixCommands

Find Unix commands, including the ones from Cygwin

This module looks for the Unix commands bash, cp, gzip, mv, rm, and tar and stores the result in the variables BASH, CP, GZIP, MV, RM, and TAR.

  • cmake-modules(7) »


FindVTK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindVTK

This module no longer exists.

This module existed in versions of CMake prior to 3.1, but became only a thin wrapper around find_package(VTK NO_MODULE) to provide compatibility for projects using long-outdated conventions. Now find_package(VTK) will search for VTKConfig.cmake directly.

  • cmake-modules(7) »


FindVulkan — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindVulkan

Try to find Vulkan

IMPORTED Targets

This module defines IMPORTED target Vulkan::Vulkan, if Vulkan has been found.

Result Variables

This module defines the following variables:

Vulkan_FOUND          - True if Vulkan was found
Vulkan_INCLUDE_DIRS   - include directories for Vulkan
Vulkan_LIBRARIES      - link against this library to use Vulkan

The module will also define two cache variables:

Vulkan_INCLUDE_DIR    - the Vulkan include directory
Vulkan_LIBRARY        - the path to the Vulkan library

  • cmake-modules(7) »


FindWget — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindWget

Find wget

This module looks for wget. This module defines the following values:

WGET_EXECUTABLE: the full path to the wget tool.
WGET_FOUND: True if wget has been found.

  • cmake-modules(7) »


FindWish — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindWish

Find wish installation

This module finds if TCL is installed and determines where the include files and libraries are. It also determines what the name of the library is. This code sets the following variables:

TK_WISH = the path to the wish executable

if UNIX is defined, then it will look for the cygwin version first

  • cmake-modules(7) »


FindwxWidgets — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindwxWidgets

Find a wxWidgets (a.k.a., wxWindows) installation.

This module finds if wxWidgets is installed and selects a default configuration to use. wxWidgets is a modular library. To specify the modules that you will use, you need to name them as components to the package:

find_package(wxWidgets COMPONENTS core base … OPTIONAL_COMPONENTS net …)

There are two search branches: a windows style and a unix style. For windows, the following variables are searched for and set to defaults in case of multiple choices. Change them if the defaults are not desired (i.e., these are the only variables you should change to select a configuration):

wxWidgets_ROOT_DIR      - Base wxWidgets directory
                          (e.g., C:/wxWidgets-2.6.3).
wxWidgets_LIB_DIR       - Path to wxWidgets libraries
                          (e.g., C:/wxWidgets-2.6.3/lib/vc_lib).
wxWidgets_CONFIGURATION - Configuration to use
                          (e.g., msw, mswd, mswu, mswunivud, etc.)
wxWidgets_EXCLUDE_COMMON_LIBRARIES
                        - Set to TRUE to exclude linking of
                          commonly required libs (e.g., png tiff
                          jpeg zlib regex expat).

For unix style it uses the wx-config utility. You can select between debug/release, unicode/ansi, universal/non-universal, and static/shared in the QtDialog or ccmake interfaces by turning ON/OFF the following variables:

wxWidgets_USE_DEBUG
wxWidgets_USE_UNICODE
wxWidgets_USE_UNIVERSAL
wxWidgets_USE_STATIC

There is also a wxWidgets_CONFIG_OPTIONS variable for all other options that need to be passed to the wx-config utility. For example, to use the base toolkit found in the /usr/local path, set the variable (before calling the FIND_PACKAGE command) as such:

set(wxWidgets_CONFIG_OPTIONS --toolkit=base --prefix=/usr)

The following are set after the configuration is done for both windows and unix style:

wxWidgets_FOUND            - Set to TRUE if wxWidgets was found.
wxWidgets_INCLUDE_DIRS     - Include directories for WIN32
                             i.e., where to find "wx/wx.h" and
                             "wx/setup.h"; possibly empty for unices.
wxWidgets_LIBRARIES        - Path to the wxWidgets libraries.
wxWidgets_LIBRARY_DIRS     - compile time link dirs, useful for
                             rpath on UNIX. Typically an empty string
                             in WIN32 environment.
wxWidgets_DEFINITIONS      - Contains defines required to compile/link
                             against WX, e.g. WXUSINGDLL
wxWidgets_DEFINITIONS_DEBUG- Contains defines required to compile/link
                             against WX debug builds, e.g. __WXDEBUG__
wxWidgets_CXX_FLAGS        - Include dirs and compiler flags for
                             unices, empty on WIN32. Essentially
                             "`wx-config --cxxflags`".
wxWidgets_USE_FILE         - Convenience include file.

Sample usage:

# Note that for MinGW users the order of libs is important!
find_package(wxWidgets COMPONENTS gl core base OPTIONAL_COMPONENTS net)
if(wxWidgets_FOUND)
  include(${wxWidgets_USE_FILE})
  # and for each of your dependent executable/library targets:
  target_link_libraries(<YourTarget> ${wxWidgets_LIBRARIES})
endif()

If wxWidgets is required (i.e., not an optional part):

find_package(wxWidgets REQUIRED gl core base OPTIONAL_COMPONENTS net)
include(${wxWidgets_USE_FILE})
# and for each of your dependent executable/library targets:
target_link_libraries(<YourTarget> ${wxWidgets_LIBRARIES})

  • cmake-modules(7) »


FindXCTest — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindXCTest

Functions to help creating and executing XCTest bundles.

An XCTest bundle is a CFBundle with a special product-type and bundle extension. The Mac Developer Library provides more information in the Testing with Xcode document.

Module Functions

xctest_add_bundle

The xctest_add_bundle function creates a XCTest bundle named <target> which will test the target <testee>. Supported target types for testee are Frameworks and App Bundles:

xctest_add_bundle(
  <target>  # Name of the XCTest bundle
  <testee>  # Target name of the testee
  )
xctest_add_test

The xctest_add_test function adds an XCTest bundle to the project to be run by ctest(1). The test will be named <name> and tests <bundle>:

xctest_add_test(
  <name>    # Test name
  <bundle>  # Target name of XCTest bundle
  )

Module Variables

The following variables are set by including this module:

XCTest_FOUND

True if the XCTest Framework and executable were found.

XCTest_EXECUTABLE

The path to the xctest command line tool used to execute XCTest bundles.

XCTest_INCLUDE_DIRS

The directory containing the XCTest Framework headers.

XCTest_LIBRARIES

The location of the XCTest Framework.

  • cmake-modules(7) »


FindXalanC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindXalanC

Find the Apache Xalan-C++ XSL transform processor headers and libraries.

Imported targets

This module defines the following IMPORTED targets:

XalanC::XalanC
The Xalan-C++ xalan-c library, if found.

Result variables

This module will set the following variables in your project:

XalanC_FOUND
true if the Xalan headers and libraries were found
XalanC_VERSION
Xalan release version
XalanC_INCLUDE_DIRS
the directory containing the Xalan headers; note XercesC_INCLUDE_DIRS is also required
XalanC_LIBRARIES
Xalan libraries to be linked; note XercesC_LIBRARIES is also required

Cache variables

The following cache variables may also be set:

XalanC_INCLUDE_DIR
the directory containing the Xalan headers
XalanC_LIBRARY
the Xalan library

  • cmake-modules(7) »


FindXercesC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindXercesC

Find the Apache Xerces-C++ validating XML parser headers and libraries.

Imported targets

This module defines the following IMPORTED targets:

XercesC::XercesC
The Xerces-C++ xerces-c library, if found.

Result variables

This module will set the following variables in your project:

XercesC_FOUND
true if the Xerces headers and libraries were found
XercesC_VERSION
Xerces release version
XercesC_INCLUDE_DIRS
the directory containing the Xerces headers
XercesC_LIBRARIES
Xerces libraries to be linked

Cache variables

The following cache variables may also be set:

XercesC_INCLUDE_DIR
the directory containing the Xerces headers
XercesC_LIBRARY
the Xerces library

  • cmake-modules(7) »


FindX11 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindX11

Find X11 installation

Try to find X11 on UNIX systems. The following values are defined

X11_FOUND        - True if X11 is available
X11_INCLUDE_DIR  - include directories to use X11
X11_LIBRARIES    - link against these to use X11

and also the following more fine grained variables and targets:

X11_ICE_INCLUDE_PATH,          X11_ICE_LIB,        X11_ICE_FOUND,        X11::ICE
X11_SM_INCLUDE_PATH,           X11_SM_LIB,         X11_SM_FOUND,         X11::SM
X11_X11_INCLUDE_PATH,          X11_X11_LIB,                              X11::X11
X11_Xaccessrules_INCLUDE_PATH,
X11_Xaccessstr_INCLUDE_PATH,                       X11_Xaccess_FOUND
X11_Xau_INCLUDE_PATH,          X11_Xau_LIB,        X11_Xau_FOUND,        X11::Xau
X11_Xcomposite_INCLUDE_PATH,   X11_Xcomposite_LIB, X11_Xcomposite_FOUND, X11::Xcomposite
X11_Xcursor_INCLUDE_PATH,      X11_Xcursor_LIB,    X11_Xcursor_FOUND,    X11::Xcursor
X11_Xdamage_INCLUDE_PATH,      X11_Xdamage_LIB,    X11_Xdamage_FOUND,    X11::Xdamage
X11_Xdmcp_INCLUDE_PATH,        X11_Xdmcp_LIB,      X11_Xdmcp_FOUND,      X11::Xdmcp
X11_Xext_INCLUDE_PATH,         X11_Xext_LIB,       X11_Xext_FOUND,       X11::Xext
X11_Xxf86misc_INCLUDE_PATH,    X11_Xxf86misc_LIB,  X11_Xxf86misc_FOUND,  X11::Xxf86misc
X11_Xxf86vm_INCLUDE_PATH,      X11_Xxf86vm_LIB     X11_Xxf86vm_FOUND,    X11::Xxf86vm
X11_Xfixes_INCLUDE_PATH,       X11_Xfixes_LIB,     X11_Xfixes_FOUND,     X11::Xfixes
X11_Xft_INCLUDE_PATH,          X11_Xft_LIB,        X11_Xft_FOUND,        X11::Xft
X11_Xi_INCLUDE_PATH,           X11_Xi_LIB,         X11_Xi_FOUND,         X11::Xi
X11_Xinerama_INCLUDE_PATH,     X11_Xinerama_LIB,   X11_Xinerama_FOUND,   X11::Xinerama
X11_Xkb_INCLUDE_PATH,
X11_Xkblib_INCLUDE_PATH,                           X11_Xkb_FOUND,        X11::Xkb
X11_xkbfile_INCLUDE_PATH,      X11_xkbfile_LIB,    X11_xkbfile_FOUND,    X11::xkbfile
X11_Xmu_INCLUDE_PATH,          X11_Xmu_LIB,        X11_Xmu_FOUND,        X11::Xmu
X11_Xpm_INCLUDE_PATH,          X11_Xpm_LIB,        X11_Xpm_FOUND,        X11::Xpm
X11_Xtst_INCLUDE_PATH,         X11_Xtst_LIB,       X11_Xtst_FOUND,       X11::Xtst
X11_Xrandr_INCLUDE_PATH,       X11_Xrandr_LIB,     X11_Xrandr_FOUND,     X11::Xrandr
X11_Xrender_INCLUDE_PATH,      X11_Xrender_LIB,    X11_Xrender_FOUND,    X11::Xrender
X11_XRes_INCLUDE_PATH,         X11_XRes_LIB,       X11_XRes_FOUND,       X11::XRes
X11_Xss_INCLUDE_PATH,          X11_Xss_LIB,        X11_Xss_FOUND,        X11::Xss
X11_Xt_INCLUDE_PATH,           X11_Xt_LIB,         X11_Xt_FOUND,         X11::Xt
X11_Xutil_INCLUDE_PATH,                            X11_Xutil_FOUND,      X11::Xutil
X11_Xv_INCLUDE_PATH,           X11_Xv_LIB,         X11_Xv_FOUND,         X11::Xv
X11_dpms_INCLUDE_PATH,         (in X11_Xext_LIB),  X11_dpms_FOUND
X11_XShm_INCLUDE_PATH,         (in X11_Xext_LIB),  X11_XShm_FOUND
X11_Xshape_INCLUDE_PATH,       (in X11_Xext_LIB),  X11_Xshape_FOUND
X11_XSync_INCLUDE_PATH,        (in X11_Xext_LIB),  X11_XSync_FOUND

  • cmake-modules(7) »


FindXMLRPC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindXMLRPC

Find xmlrpc

Find the native XMLRPC headers and libraries.

XMLRPC_INCLUDE_DIRS      - where to find xmlrpc.h, etc.
XMLRPC_LIBRARIES         - List of libraries when using xmlrpc.
XMLRPC_FOUND             - True if xmlrpc found.

XMLRPC modules may be specified as components for this find module. Modules may be listed by running “xmlrpc-c-config”. Modules include:

c++            C++ wrapper code
libwww-client  libwww-based client
cgi-server     CGI-based server
abyss-server   ABYSS-based server

Typical usage:

find_package(XMLRPC REQUIRED libwww-client)

  • cmake-modules(7) »


FindZLIB — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindZLIB

Find the native ZLIB includes and library.

IMPORTED Targets

This module defines IMPORTED target ZLIB::ZLIB, if ZLIB has been found.

Result Variables

This module defines the following variables:

ZLIB_INCLUDE_DIRS   - where to find zlib.h, etc.
ZLIB_LIBRARIES      - List of libraries when using zlib.
ZLIB_FOUND          - True if zlib found.

ZLIB_VERSION_STRING - The version of zlib found (x.y.z)
ZLIB_VERSION_MAJOR  - The major version of zlib
ZLIB_VERSION_MINOR  - The minor version of zlib
ZLIB_VERSION_PATCH  - The patch version of zlib
ZLIB_VERSION_TWEAK  - The tweak version of zlib

Backward Compatibility

The following variable are provided for backward compatibility

ZLIB_MAJOR_VERSION  - The major version of zlib
ZLIB_MINOR_VERSION  - The minor version of zlib
ZLIB_PATCH_VERSION  - The patch version of zlib

Hints

A user may set ZLIB_ROOT to a zlib installation root to tell this module where to look.

  • cmake-modules(7) »


CMakeDetermineVSServicePack — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeDetermineVSServicePack

Deprecated since version 3.0: Do not use.

The functionality of this module has been superseded by the CMAKE_<LANG>_COMPILER_VERSION variable that contains the compiler version number.

Determine the Visual Studio service pack of the ‘cl’ in use.

Usage:

if(MSVC)
  include(CMakeDetermineVSServicePack)
  DetermineVSServicePack( my_service_pack )
  if( my_service_pack )
    message(STATUS "Detected: ${my_service_pack}")
  endif()
endif()

Function DetermineVSServicePack sets the given variable to one of the following values or an empty string if unknown:

vc80, vc80sp1
vc90, vc90sp1
vc100, vc100sp1
vc110, vc110sp1, vc110sp2, vc110sp3, vc110sp4

  • cmake-modules(7) »


CMakeExpandImportedTargets — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeExpandImportedTargets

Deprecated since version 3.4: Do not use.

This module was once needed to expand imported targets to the underlying libraries they reference on disk for use with the try_compile() and try_run() commands. These commands now support imported libraries in their LINK_LIBRARIES options (since CMake 2.8.11 for try_compile() and since CMake 3.2 for try_run()).

This module does not support the policy CMP0022 NEW behavior or use of the INTERFACE_LINK_LIBRARIES property because generator expressions cannot be evaluated during configuration.

CMAKE_EXPAND_IMPORTED_TARGETS(<var> LIBRARIES lib1 lib2...libN
                              [CONFIGURATION <config>])

CMAKE_EXPAND_IMPORTED_TARGETS() takes a list of libraries and replaces all imported targets contained in this list with their actual file paths of the referenced libraries on disk, including the libraries from their link interfaces. If a CONFIGURATION is given, it uses the respective configuration of the imported targets if it exists. If no CONFIGURATION is given, it uses the first configuration from ${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}.

cmake_expand_imported_targets(expandedLibs
  LIBRARIES ${CMAKE_REQUIRED_LIBRARIES}
  CONFIGURATION "${CMAKE_TRY_COMPILE_CONFIGURATION}" )

  • cmake-modules(7) »


CMakeForceCompiler — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeForceCompiler

Deprecated since version 3.6: Do not use.

The macros provided by this module were once intended for use by cross-compiling toolchain files when CMake was not able to automatically detect the compiler identification. Since the introduction of this module, CMake’s compiler identification capabilities have improved and can now be taught to recognize any compiler. Furthermore, the suite of information CMake detects from a compiler is now too extensive to be provided by toolchain files using these macros.

One common use case for this module was to skip CMake’s checks for a working compiler when using a cross-compiler that cannot link binaries without special flags or custom linker scripts. This case is now supported by setting the CMAKE_TRY_COMPILE_TARGET_TYPE variable in the toolchain file instead.

Macro CMAKE_FORCE_C_COMPILER has the following signature:

CMAKE_FORCE_C_COMPILER(<compiler> <compiler-id>)

It sets CMAKE_C_COMPILER to the given compiler and the cmake internal variable CMAKE_C_COMPILER_ID to the given compiler-id. It also bypasses the check for working compiler and basic compiler information tests.

Macro CMAKE_FORCE_CXX_COMPILER has the following signature:

CMAKE_FORCE_CXX_COMPILER(<compiler> <compiler-id>)

It sets CMAKE_CXX_COMPILER to the given compiler and the cmake internal variable CMAKE_CXX_COMPILER_ID to the given compiler-id. It also bypasses the check for working compiler and basic compiler information tests.

Macro CMAKE_FORCE_Fortran_COMPILER has the following signature:

CMAKE_FORCE_Fortran_COMPILER(<compiler> <compiler-id>)

It sets CMAKE_Fortran_COMPILER to the given compiler and the cmake internal variable CMAKE_Fortran_COMPILER_ID to the given compiler-id. It also bypasses the check for working compiler and basic compiler information tests.

So a simple toolchain file could look like this:

include (CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Generic)
CMAKE_FORCE_C_COMPILER   (chc12 MetrowerksHicross)
CMAKE_FORCE_CXX_COMPILER (chc12 MetrowerksHicross)

  • cmake-modules(7) »


CMakeParseArguments — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CMakeParseArguments

This module once implemented the cmake_parse_arguments() command that is now implemented natively by CMake. It is now an empty placeholder for compatibility with projects that include it to get the command from CMake 3.4 and lower.

  • cmake-modules(7) »


MacroAddFileDependencies — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

MacroAddFileDependencies

MACRO_ADD_FILE_DEPENDENCIES(<_file> depend_files…)

Using the macro MACRO_ADD_FILE_DEPENDENCIES() is discouraged. There are usually better ways to specify the correct dependencies.

MACRO_ADD_FILE_DEPENDENCIES(<_file> depend_files…) is just a convenience wrapper around the OBJECT_DEPENDS source file property. You can just use set_property(SOURCE <file> APPEND PROPERTY OBJECT_DEPENDS depend_files) instead.

  • cmake-modules(7) »


TestCXXAcceptsFlag — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

TestCXXAcceptsFlag

Deprecated since version 3.0: See CheckCXXCompilerFlag.

Check if the CXX compiler accepts a flag.

CHECK_CXX_ACCEPTS_FLAG(<flags> <variable>)
<flags>
the flags to try
<variable>
variable to store the result

  • cmake-modules(7) »


UsePkgConfig — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

UsePkgConfig

Obsolete pkg-config module for CMake, use FindPkgConfig instead.

This module defines the following macro:

PKGCONFIG(package includedir libdir linkflags cflags)

Calling PKGCONFIG will fill the desired information into the 4 given arguments, e.g. PKGCONFIG(libart-2.0 LIBART_INCLUDE_DIR LIBART_LINK_DIR LIBART_LINK_FLAGS LIBART_CFLAGS) if pkg-config was NOT found or the specified software package doesn’t exist, the variable will be empty when the function returns, otherwise they will contain the respective information

  • cmake-modules(7) »


Use_wxWindows — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

Use_wxWindows

Deprecated since version 2.8.10: Use find_package(wxWidgets) and include(${wxWidgets_USE_FILE}) instead.

This convenience include finds if wxWindows is installed and set the appropriate libs, incdirs, flags etc. author Jan Woetzel <jw -at- mip.informatik.uni-kiel.de> (07/2003)

USAGE:

just include Use_wxWindows.cmake
in your projects CMakeLists.txt

include( ${CMAKE_MODULE_PATH}/Use_wxWindows.cmake)

if you are sure you need GL then

set(WXWINDOWS_USE_GL 1)

*before* you include this file.

  • cmake-modules(7) »


WriteBasicConfigVersionFile — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

WriteBasicConfigVersionFile

Deprecated since version 3.0: Use the identical command write_basic_package_version_file() from module CMakePackageConfigHelpers.

WRITE_BASIC_CONFIG_VERSION_FILE( filename
  [VERSION major.minor.patch]
  COMPATIBILITY (AnyNewerVersion|SameMajorVersion|SameMinorVersion|ExactVersion)
  [ARCH_INDEPENDENT]
  )

  • cmake-modules(7) »


FindCUDA — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindCUDA

Deprecated since version 3.10: Superseded by first-class support for the CUDA language in CMake.

Replacement

It is no longer necessary to use this module or call find_package(CUDA). Instead, list CUDA among the languages named in the top-level call to the project() command, or call the enable_language() command with CUDA. Then one can add CUDA (.cu) sources to programs directly in calls to add_library() and add_executable().

Documentation of Deprecated Usage

Tools for building CUDA C files: libraries and build dependencies.

This script locates the NVIDIA CUDA C tools. It should work on Linux, Windows, and macOS and should be reasonably up to date with CUDA C releases.

This script makes use of the standard find_package() arguments of <VERSION>, REQUIRED and QUIET. CUDA_FOUND will report if an acceptable version of CUDA was found.

The script will prompt the user to specify CUDA_TOOLKIT_ROOT_DIR if the prefix cannot be determined by the location of nvcc in the system path and REQUIRED is specified to find_package(). To use a different installed version of the toolkit set the environment variable CUDA_BIN_PATH before running cmake (e.g. CUDA_BIN_PATH=/usr/local/cuda1.0 instead of the default /usr/local/cuda) or set CUDA_TOOLKIT_ROOT_DIR after configuring. If you change the value of CUDA_TOOLKIT_ROOT_DIR, various components that depend on the path will be relocated.

It might be necessary to set CUDA_TOOLKIT_ROOT_DIR manually on certain platforms, or to use a CUDA runtime not installed in the default location. In newer versions of the toolkit the CUDA library is included with the graphics driver – be sure that the driver version matches what is needed by the CUDA runtime version.

The following variables affect the behavior of the macros in the script (in alphabetical order). Note that any of these flags can be changed multiple times in the same directory before calling CUDA_ADD_EXECUTABLE, CUDA_ADD_LIBRARY, CUDA_COMPILE, CUDA_COMPILE_PTX, CUDA_COMPILE_FATBIN, CUDA_COMPILE_CUBIN or CUDA_WRAP_SRCS:

CUDA_64_BIT_DEVICE_CODE (Default matches host bit size)
-- Set to ON to compile for 64 bit device code, OFF for 32 bit device code.
   Note that making this different from the host code when generating object
   or C files from CUDA code just won't work, because size_t gets defined by
   nvcc in the generated source.  If you compile to PTX and then load the
   file yourself, you can mix bit sizes between device and host.

CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE (Default ON)
-- Set to ON if you want the custom build rule to be attached to the source
   file in Visual Studio.  Turn OFF if you add the same cuda file to multiple
   targets.

   This allows the user to build the target from the CUDA file; however, bad
   things can happen if the CUDA source file is added to multiple targets.
   When performing parallel builds it is possible for the custom build
   command to be run more than once and in parallel causing cryptic build
   errors.  VS runs the rules for every source file in the target, and a
   source can have only one rule no matter how many projects it is added to.
   When the rule is run from multiple targets race conditions can occur on
   the generated file.  Eventually everything will get built, but if the user
   is unaware of this behavior, there may be confusion.  It would be nice if
   this script could detect the reuse of source files across multiple targets
   and turn the option off for the user, but no good solution could be found.

CUDA_BUILD_CUBIN (Default OFF)
-- Set to ON to enable and extra compilation pass with the -cubin option in
   Device mode. The output is parsed and register, shared memory usage is
   printed during build.

CUDA_BUILD_EMULATION (Default OFF for device mode)
-- Set to ON for Emulation mode. -D_DEVICEEMU is defined for CUDA C files
   when CUDA_BUILD_EMULATION is TRUE.

CUDA_LINK_LIBRARIES_KEYWORD (Default "")
 -- The <PRIVATE|PUBLIC|INTERFACE> keyword to use for internal
    target_link_libraries calls. The default is to use no keyword which
    uses the old "plain" form of target_link_libraries. Note that is matters
    because whatever is used inside the FindCUDA module must also be used
    outside - the two forms of target_link_libraries cannot be mixed.

CUDA_GENERATED_OUTPUT_DIR (Default CMAKE_CURRENT_BINARY_DIR)
-- Set to the path you wish to have the generated files placed.  If it is
   blank output files will be placed in CMAKE_CURRENT_BINARY_DIR.
   Intermediate files will always be placed in
   CMAKE_CURRENT_BINARY_DIR/CMakeFiles.

CUDA_HOST_COMPILATION_CPP (Default ON)
-- Set to OFF for C compilation of host code.

CUDA_HOST_COMPILER (Default CMAKE_C_COMPILER)
-- Set the host compiler to be used by nvcc.  Ignored if -ccbin or
   --compiler-bindir is already present in the CUDA_NVCC_FLAGS or
   CUDA_NVCC_FLAGS_<CONFIG> variables.  For Visual Studio targets,
   the host compiler is constructed with one or more visual studio macros
   such as $(VCInstallDir), that expands out to the path when
   the command is run from within VS.
   If the CUDAHOSTCXX environment variable is set it will
   be used as the default.

CUDA_NVCC_FLAGS
CUDA_NVCC_FLAGS_<CONFIG>
-- Additional NVCC command line arguments.  NOTE: multiple arguments must be
   semi-colon delimited (e.g. --compiler-options;-Wall)

CUDA_PROPAGATE_HOST_FLAGS (Default ON)
-- Set to ON to propagate CMAKE_{C,CXX}_FLAGS and their configuration
   dependent counterparts (e.g. CMAKE_C_FLAGS_DEBUG) automatically to the
   host compiler through nvcc's -Xcompiler flag.  This helps make the
   generated host code match the rest of the system better.  Sometimes
   certain flags give nvcc problems, and this will help you turn the flag
   propagation off.  This does not affect the flags supplied directly to nvcc
   via CUDA_NVCC_FLAGS or through the OPTION flags specified through
   CUDA_ADD_LIBRARY, CUDA_ADD_EXECUTABLE, or CUDA_WRAP_SRCS.  Flags used for
   shared library compilation are not affected by this flag.

CUDA_SEPARABLE_COMPILATION (Default OFF)
-- If set this will enable separable compilation for all CUDA runtime object
   files.  If used outside of CUDA_ADD_EXECUTABLE and CUDA_ADD_LIBRARY
   (e.g. calling CUDA_WRAP_SRCS directly),
   CUDA_COMPUTE_SEPARABLE_COMPILATION_OBJECT_FILE_NAME and
   CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS should be called.

CUDA_SOURCE_PROPERTY_FORMAT
-- If this source file property is set, it can override the format specified
   to CUDA_WRAP_SRCS (OBJ, PTX, CUBIN, or FATBIN).  If an input source file
   is not a .cu file, setting this file will cause it to be treated as a .cu
   file. See documentation for set_source_files_properties on how to set
   this property.

CUDA_USE_STATIC_CUDA_RUNTIME (Default ON)
-- When enabled the static version of the CUDA runtime library will be used
   in CUDA_LIBRARIES.  If the version of CUDA configured doesn't support
   this option, then it will be silently disabled.

CUDA_VERBOSE_BUILD (Default OFF)
-- Set to ON to see all the commands used when building the CUDA file.  When
   using a Makefile generator the value defaults to VERBOSE (run make
   VERBOSE=1 to see output), although setting CUDA_VERBOSE_BUILD to ON will
   always print the output.

The script creates the following macros (in alphabetical order):

CUDA_ADD_CUFFT_TO_TARGET( cuda_target )
-- Adds the cufft library to the target (can be any target).  Handles whether
   you are in emulation mode or not.

CUDA_ADD_CUBLAS_TO_TARGET( cuda_target )
-- Adds the cublas library to the target (can be any target).  Handles
   whether you are in emulation mode or not.

CUDA_ADD_EXECUTABLE( cuda_target file0 file1 ...
                     [WIN32] [MACOSX_BUNDLE] [EXCLUDE_FROM_ALL] [OPTIONS ...] )
-- Creates an executable "cuda_target" which is made up of the files
   specified.  All of the non CUDA C files are compiled using the standard
   build rules specified by CMAKE and the cuda files are compiled to object
   files using nvcc and the host compiler.  In addition CUDA_INCLUDE_DIRS is
   added automatically to include_directories().  Some standard CMake target
   calls can be used on the target after calling this macro
   (e.g. set_target_properties and target_link_libraries), but setting
   properties that adjust compilation flags will not affect code compiled by
   nvcc.  Such flags should be modified before calling CUDA_ADD_EXECUTABLE,
   CUDA_ADD_LIBRARY or CUDA_WRAP_SRCS.

CUDA_ADD_LIBRARY( cuda_target file0 file1 ...
                  [STATIC | SHARED | MODULE] [EXCLUDE_FROM_ALL] [OPTIONS ...] )
-- Same as CUDA_ADD_EXECUTABLE except that a library is created.

CUDA_BUILD_CLEAN_TARGET()
-- Creates a convenience target that deletes all the dependency files
   generated.  You should make clean after running this target to ensure the
   dependency files get regenerated.

CUDA_COMPILE( generated_files file0 file1 ... [STATIC | SHARED | MODULE]
              [OPTIONS ...] )
-- Returns a list of generated files from the input source files to be used
   with ADD_LIBRARY or ADD_EXECUTABLE.

CUDA_COMPILE_PTX( generated_files file0 file1 ... [OPTIONS ...] )
-- Returns a list of PTX files generated from the input source files.

CUDA_COMPILE_FATBIN( generated_files file0 file1 ... [OPTIONS ...] )
-- Returns a list of FATBIN files generated from the input source files.

CUDA_COMPILE_CUBIN( generated_files file0 file1 ... [OPTIONS ...] )
-- Returns a list of CUBIN files generated from the input source files.

CUDA_COMPUTE_SEPARABLE_COMPILATION_OBJECT_FILE_NAME( output_file_var
                                                     cuda_target
                                                     object_files )
-- Compute the name of the intermediate link file used for separable
   compilation.  This file name is typically passed into
   CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS.  output_file_var is produced
   based on cuda_target the list of objects files that need separable
   compilation as specified by object_files.  If the object_files list is
   empty, then output_file_var will be empty.  This function is called
   automatically for CUDA_ADD_LIBRARY and CUDA_ADD_EXECUTABLE.  Note that
   this is a function and not a macro.

CUDA_INCLUDE_DIRECTORIES( path0 path1 ... )
-- Sets the directories that should be passed to nvcc
   (e.g. nvcc -Ipath0 -Ipath1 ... ). These paths usually contain other .cu
   files.

CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS( output_file_var cuda_target
                                         nvcc_flags object_files)
-- Generates the link object required by separable compilation from the given
   object files.  This is called automatically for CUDA_ADD_EXECUTABLE and
   CUDA_ADD_LIBRARY, but can be called manually when using CUDA_WRAP_SRCS
   directly.  When called from CUDA_ADD_LIBRARY or CUDA_ADD_EXECUTABLE the
   nvcc_flags passed in are the same as the flags passed in via the OPTIONS
   argument.  The only nvcc flag added automatically is the bitness flag as
   specified by CUDA_64_BIT_DEVICE_CODE.  Note that this is a function
   instead of a macro.

CUDA_SELECT_NVCC_ARCH_FLAGS(out_variable [target_CUDA_architectures])
-- Selects GPU arch flags for nvcc based on target_CUDA_architectures
   target_CUDA_architectures : Auto | Common | All | LIST(ARCH_AND_PTX ...)
    - "Auto" detects local machine GPU compute arch at runtime.
    - "Common" and "All" cover common and entire subsets of architectures
   ARCH_AND_PTX : NAME | NUM.NUM | NUM.NUM(NUM.NUM) | NUM.NUM+PTX
   NAME: Fermi Kepler Maxwell Kepler+Tegra Kepler+Tesla Maxwell+Tegra Pascal
   NUM: Any number. Only those pairs are currently accepted by NVCC though:
         2.0 2.1 3.0 3.2 3.5 3.7 5.0 5.2 5.3 6.0 6.2
   Returns LIST of flags to be added to CUDA_NVCC_FLAGS in ${out_variable}
   Additionally, sets ${out_variable}_readable to the resulting numeric list
   Example:
    CUDA_SELECT_NVCC_ARCH_FLAGS(ARCH_FLAGS 3.0 3.5+PTX 5.2(5.0) Maxwell)
     LIST(APPEND CUDA_NVCC_FLAGS ${ARCH_FLAGS})

   More info on CUDA architectures: https://en.wikipedia.org/wiki/CUDA
   Note that this is a function instead of a macro.

CUDA_WRAP_SRCS ( cuda_target format generated_files file0 file1 ...
                 [STATIC | SHARED | MODULE] [OPTIONS ...] )
-- This is where all the magic happens.  CUDA_ADD_EXECUTABLE,
   CUDA_ADD_LIBRARY, CUDA_COMPILE, and CUDA_COMPILE_PTX all call this
   function under the hood.

   Given the list of files (file0 file1 ... fileN) this macro generates
   custom commands that generate either PTX or linkable objects (use "PTX" or
   "OBJ" for the format argument to switch).  Files that don't end with .cu
   or have the HEADER_FILE_ONLY property are ignored.

   The arguments passed in after OPTIONS are extra command line options to
   give to nvcc.  You can also specify per configuration options by
   specifying the name of the configuration followed by the options.  General
   options must precede configuration specific options.  Not all
   configurations need to be specified, only the ones provided will be used.

      OPTIONS -DFLAG=2 "-DFLAG_OTHER=space in flag"
      DEBUG -g
      RELEASE --use_fast_math
      RELWITHDEBINFO --use_fast_math;-g
      MINSIZEREL --use_fast_math

   For certain configurations (namely VS generating object files with
   CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE set to ON), no generated file will
   be produced for the given cuda file.  This is because when you add the
   cuda file to Visual Studio it knows that this file produces an object file
   and will link in the resulting object file automatically.

   This script will also generate a separate cmake script that is used at
   build time to invoke nvcc.  This is for several reasons.

     1. nvcc can return negative numbers as return values which confuses
     Visual Studio into thinking that the command succeeded.  The script now
     checks the error codes and produces errors when there was a problem.

     2. nvcc has been known to not delete incomplete results when it
     encounters problems.  This confuses build systems into thinking the
     target was generated when in fact an unusable file exists.  The script
     now deletes the output files if there was an error.

     3. By putting all the options that affect the build into a file and then
     make the build rule dependent on the file, the output files will be
     regenerated when the options change.

   This script also looks at optional arguments STATIC, SHARED, or MODULE to
   determine when to target the object compilation for a shared library.
   BUILD_SHARED_LIBS is ignored in CUDA_WRAP_SRCS, but it is respected in
   CUDA_ADD_LIBRARY.  On some systems special flags are added for building
   objects intended for shared libraries.  A preprocessor macro,
   <target_name>_EXPORTS is defined when a shared library compilation is
   detected.

   Flags passed into add_definitions with -D or /D are passed along to nvcc.

The script defines the following variables:

CUDA_VERSION_MAJOR    -- The major version of cuda as reported by nvcc.
CUDA_VERSION_MINOR    -- The minor version.
CUDA_VERSION
CUDA_VERSION_STRING   -- CUDA_VERSION_MAJOR.CUDA_VERSION_MINOR
CUDA_HAS_FP16         -- Whether a short float (float16,fp16) is supported.

CUDA_TOOLKIT_ROOT_DIR -- Path to the CUDA Toolkit (defined if not set).
CUDA_SDK_ROOT_DIR     -- Path to the CUDA SDK.  Use this to find files in the
                         SDK.  This script will not directly support finding
                         specific libraries or headers, as that isn't
                         supported by NVIDIA.  If you want to change
                         libraries when the path changes see the
                         FindCUDA.cmake script for an example of how to clear
                         these variables.  There are also examples of how to
                         use the CUDA_SDK_ROOT_DIR to locate headers or
                         libraries, if you so choose (at your own risk).
CUDA_INCLUDE_DIRS     -- Include directory for cuda headers.  Added automatically
                         for CUDA_ADD_EXECUTABLE and CUDA_ADD_LIBRARY.
CUDA_LIBRARIES        -- Cuda RT library.
CUDA_CUFFT_LIBRARIES  -- Device or emulation library for the Cuda FFT
                         implementation (alternative to:
                         CUDA_ADD_CUFFT_TO_TARGET macro)
CUDA_CUBLAS_LIBRARIES -- Device or emulation library for the Cuda BLAS
                         implementation (alternative to:
                         CUDA_ADD_CUBLAS_TO_TARGET macro).
CUDA_cudart_static_LIBRARY -- Statically linkable cuda runtime library.
                              Only available for CUDA version 5.5+
CUDA_cudadevrt_LIBRARY -- Device runtime library.
                          Required for separable compilation.
CUDA_cupti_LIBRARY    -- CUDA Profiling Tools Interface library.
                         Only available for CUDA version 4.0+.
CUDA_curand_LIBRARY   -- CUDA Random Number Generation library.
                         Only available for CUDA version 3.2+.
CUDA_cusolver_LIBRARY -- CUDA Direct Solver library.
                         Only available for CUDA version 7.0+.
CUDA_cusparse_LIBRARY -- CUDA Sparse Matrix library.
                         Only available for CUDA version 3.2+.
CUDA_npp_LIBRARY      -- NVIDIA Performance Primitives lib.
                         Only available for CUDA version 4.0+.
CUDA_nppc_LIBRARY     -- NVIDIA Performance Primitives lib (core).
                         Only available for CUDA version 5.5+.
CUDA_nppi_LIBRARY     -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 5.5 - 8.0.
CUDA_nppial_LIBRARY   -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_nppicc_LIBRARY   -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_nppicom_LIBRARY  -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_nppidei_LIBRARY  -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_nppif_LIBRARY    -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_nppig_LIBRARY    -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_nppim_LIBRARY    -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_nppist_LIBRARY   -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_nppisu_LIBRARY   -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_nppitc_LIBRARY   -- NVIDIA Performance Primitives lib (image processing).
                         Only available for CUDA version 9.0.
CUDA_npps_LIBRARY     -- NVIDIA Performance Primitives lib (signal processing).
                         Only available for CUDA version 5.5+.
CUDA_nvcuvenc_LIBRARY -- CUDA Video Encoder library.
                         Only available for CUDA version 3.2+.
                         Windows only.
CUDA_nvcuvid_LIBRARY  -- CUDA Video Decoder library.
                         Only available for CUDA version 3.2+.
                         Windows only.

  • cmake-modules(7) »


FindPythonInterp — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPythonInterp

Deprecated since version 3.12: Use FindPython3, FindPython2 or FindPython instead.

Find python interpreter

This module finds if Python interpreter is installed and determines where the executables are. This code sets the following variables:

PYTHONINTERP_FOUND         - Was the Python executable found
PYTHON_EXECUTABLE          - path to the Python interpreter

PYTHON_VERSION_STRING      - Python version found e.g. 2.5.2
PYTHON_VERSION_MAJOR       - Python major version found e.g. 2
PYTHON_VERSION_MINOR       - Python minor version found e.g. 5
PYTHON_VERSION_PATCH       - Python patch version found e.g. 2

The Python_ADDITIONAL_VERSIONS variable can be used to specify a list of version numbers that should be taken into account when searching for Python. You need to set this variable before calling find_package(PythonInterp).

If calling both find_package(PythonInterp) and find_package(PythonLibs), call find_package(PythonInterp) first to get the currently active Python version by default with a consistent version of PYTHON_LIBRARIES.

  • cmake-modules(7) »


FindPythonLibs — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindPythonLibs

Deprecated since version 3.12: Use FindPython3, FindPython2 or FindPython instead.

Find python libraries

This module finds if Python is installed and determines where the include files and libraries are. It also determines what the name of the library is. This code sets the following variables:

PYTHONLIBS_FOUND           - have the Python libs been found
PYTHON_LIBRARIES           - path to the python library
PYTHON_INCLUDE_PATH        - path to where Python.h is found (deprecated)
PYTHON_INCLUDE_DIRS        - path to where Python.h is found
PYTHON_DEBUG_LIBRARIES     - path to the debug library (deprecated)
PYTHONLIBS_VERSION_STRING  - version of the Python libs found (since CMake 2.8.8)

The Python_ADDITIONAL_VERSIONS variable can be used to specify a list of version numbers that should be taken into account when searching for Python. You need to set this variable before calling find_package(PythonLibs).

If you’d like to specify the installation of Python to use, you should modify the following cache variables:

PYTHON_LIBRARY             - path to the python library
PYTHON_INCLUDE_DIR         - path to where Python.h is found

If calling both find_package(PythonInterp) and find_package(PythonLibs), call find_package(PythonInterp) first to get the currently active Python version by default with a consistent version of PYTHON_LIBRARIES.

  • cmake-modules(7) »


FindQt — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindQt

Searches for all installed versions of Qt3 or Qt4.

This module cannot handle Qt5 or any later versions. For those, see cmake-qt(7).

This module exists for the find_package() command only if policy CMP0084 is not set to NEW.

This module should only be used if your project can work with multiple versions of Qt. If not, you should just directly use FindQt4 or FindQt3. If multiple versions of Qt are found on the machine, then The user must set the option DESIRED_QT_VERSION to the version they want to use. If only one version of qt is found on the machine, then the DESIRED_QT_VERSION is set to that version and the matching FindQt3 or FindQt4 module is included. Once the user sets DESIRED_QT_VERSION, then the FindQt3 or FindQt4 module is included.

QT_REQUIRED if this is set to TRUE then if CMake can
            not find Qt4 or Qt3 an error is raised
            and a message is sent to the user.

DESIRED_QT_VERSION OPTION is created
QT4_INSTALLED is set to TRUE if qt4 is found.
QT3_INSTALLED is set to TRUE if qt3 is found.

  • cmake-modules(7) »


FindwxWindows — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

FindwxWindows

Deprecated since version 3.0: Replaced by FindwxWidgets.

Find wxWindows (wxWidgets) installation

This module finds if wxWindows/wxWidgets is installed and determines where the include files and libraries are. It also determines what the name of the library is. This code sets the following variables:

WXWINDOWS_FOUND     = system has WxWindows
WXWINDOWS_LIBRARIES = path to the wxWindows libraries
                      on Unix/Linux with additional
                      linker flags from
                      "wx-config --libs"
CMAKE_WXWINDOWS_CXX_FLAGS  = Compiler flags for wxWindows,
                             essentially "`wx-config --cxxflags`"
                             on Linux
WXWINDOWS_INCLUDE_DIR      = where to find "wx/wx.h" and "wx/setup.h"
WXWINDOWS_LINK_DIRECTORIES = link directories, useful for rpath on
                              Unix
WXWINDOWS_DEFINITIONS      = extra defines

OPTIONS If you need OpenGL support please

set(WXWINDOWS_USE_GL 1)

in your CMakeLists.txt before you include this file.

HAVE_ISYSTEM      - true required to replace -I by -isystem on g++

For convenience include Use_wxWindows.cmake in your project’s CMakeLists.txt using include(${CMAKE_CURRENT_LIST_DIR}/Use_wxWindows.cmake).

USAGE

set(WXWINDOWS_USE_GL 1)
find_package(wxWindows)

NOTES wxWidgets 2.6.x is supported for monolithic builds e.g. compiled in wx/build/msw dir as:

nmake -f makefile.vc BUILD=debug SHARED=0 USE_OPENGL=1 MONOLITHIC=1

DEPRECATED

CMAKE_WX_CAN_COMPILE
WXWINDOWS_LIBRARY
CMAKE_WX_CXX_FLAGS
WXWINDOWS_INCLUDE_PATH

AUTHOR Jan Woetzel <http://www.mip.informatik.uni-kiel.de/~jw> (07/2003-01/2006)

  • cmake-modules(7) »


CPackArchive — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackArchive

The documentation for the CPack Archive generator has moved here: CPack Archive Generator

  • cmake-modules(7) »


CPackBundle — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackBundle

The documentation for the CPack Bundle generator has moved here: CPack Bundle Generator

  • cmake-modules(7) »


CPackCygwin — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackCygwin

The documentation for the CPack Cygwin generator has moved here: CPack Cygwin Generator

  • cmake-modules(7) »


CPackDeb — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackDeb

The documentation for the CPack DEB generator has moved here: CPack DEB Generator

  • cmake-modules(7) »


CPackDMG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackDMG

The documentation for the CPack DragNDrop generator has moved here: CPack DragNDrop Generator

  • cmake-modules(7) »


CPackFreeBSD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackFreeBSD

The documentation for the CPack FreeBSD generator has moved here: CPack FreeBSD Generator

  • cmake-modules(7) »


CPackNSIS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackNSIS

The documentation for the CPack NSIS generator has moved here: CPack NSIS Generator

  • cmake-modules(7) »


CPackNuGet — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackNuGet

The documentation for the CPack NuGet generator has moved here: CPack NuGet Generator

  • cmake-modules(7) »


CPackPackageMaker — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackPackageMaker

The documentation for the CPack PackageMaker generator has moved here: CPack PackageMaker Generator

  • cmake-modules(7) »


CPackProductBuild — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackProductBuild

The documentation for the CPack productbuild generator has moved here: CPack productbuild Generator

  • cmake-modules(7) »


CPackRPM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackRPM

The documentation for the CPack RPM generator has moved here: CPack RPM Generator

  • cmake-modules(7) »


CPackWIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-modules(7) »

CPackWIX

The documentation for the CPack WIX generator has moved here: CPack WIX Generator

  • cmake-modules(7) »


cmake-packages(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-packages(7)

Contents

  • cmake-packages(7)
    • Introduction
    • Using Packages
      • Config-file Packages
      • Find-module Packages
    • Package Layout
      • Package Configuration File
      • Package Version File
    • Creating Packages
      • Creating a Package Configuration File
        • Creating a Package Configuration File for the Build Tree
      • Creating Relocatable Packages
    • Package Registry
      • User Package Registry
      • System Package Registry
      • Disabling the Package Registry
      • Package Registry Example
      • Package Registry Ownership

Introduction

Packages provide dependency information to CMake based buildsystems. Packages are found with the find_package() command. The result of using find_package is either a set of IMPORTED targets, or a set of variables corresponding to build-relevant information.

Using Packages

CMake provides direct support for two forms of packages, Config-file Packages and Find-module Packages. Indirect support for pkg-config packages is also provided via the FindPkgConfig module. In all cases, the basic form of find_package() calls is the same:

find_package(Qt4 4.7.0 REQUIRED) # CMake provides a Qt4 find-module
find_package(Qt5Core 5.1.0 REQUIRED) # Qt provides a Qt5 package config file.
find_package(LibXml2 REQUIRED) # Use pkg-config via the LibXml2 find-module

In cases where it is known that a package configuration file is provided by upstream, and only that should be used, the CONFIG keyword may be passed to find_package():

find_package(Qt5Core 5.1.0 CONFIG REQUIRED)
find_package(Qt5Gui 5.1.0 CONFIG)

Similarly, the MODULE keyword says to use only a find-module:

find_package(Qt4 4.7.0 MODULE REQUIRED)

Specifying the type of package explicitly improves the error message shown to the user if it is not found.

Both types of packages also support specifying components of a package, either after the REQUIRED keyword:

find_package(Qt5 5.1.0 CONFIG REQUIRED Widgets Xml Sql)

or as a separate COMPONENTS list:

find_package(Qt5 5.1.0 COMPONENTS Widgets Xml Sql)

or as a separate OPTIONAL_COMPONENTS list:

find_package(Qt5 5.1.0 COMPONENTS Widgets
                       OPTIONAL_COMPONENTS Xml Sql
)

Handling of COMPONENTS and OPTIONAL_COMPONENTS is defined by the package.

By setting the CMAKE_DISABLE_FIND_PACKAGE_<PackageName> variable to TRUE, the <PackageName> package will not be searched, and will always be NOTFOUND.

Config-file Packages

A config-file package is a set of files provided by upstreams for downstreams to use. CMake searches in a number of locations for package configuration files, as described in the find_package() documentation. The most simple way for a CMake user to tell cmake(1) to search in a non-standard prefix for a package is to set the CMAKE_PREFIX_PATH cache variable.

Config-file packages are provided by upstream vendors as part of development packages, that is, they belong with the header files and any other files provided to assist downstreams in using the package.

A set of variables which provide package status information are also set automatically when using a config-file package. The <PackageName>_FOUND variable is set to true or false, depending on whether the package was found. The <PackageName>_DIR cache variable is set to the location of the package configuration file.

Find-module Packages

A find module is a file with a set of rules for finding the required pieces of a dependency, primarily header files and libraries. Typically, a find module is needed when the upstream is not built with CMake, or is not CMake-aware enough to otherwise provide a package configuration file. Unlike a package configuration file, it is not shipped with upstream, but is used by downstream to find the files by guessing locations of files with platform-specific hints.

Unlike the case of an upstream-provided package configuration file, no single point of reference identifies the package as being found, so the <PackageName>_FOUND variable is not automatically set by the find_package() command. It can still be expected to be set by convention however and should be set by the author of the Find-module. Similarly there is no <PackageName>_DIR variable, but each of the artifacts such as library locations and header file locations provide a separate cache variable.

See the cmake-developer(7) manual for more information about creating Find-module files.

Package Layout

A config-file package consists of a Package Configuration File and optionally a Package Version File provided with the project distribution.

Package Configuration File

Consider a project Foo that installs the following files:

<prefix>/include/foo-1.2/foo.h
<prefix>/lib/foo-1.2/libfoo.a

It may also provide a CMake package configuration file:

<prefix>/lib/cmake/foo-1.2/FooConfig.cmake

with content defining IMPORTED targets, or defining variables, such as:

# ...
# (compute PREFIX relative to file location)
# ...
set(Foo_INCLUDE_DIRS ${PREFIX}/include/foo-1.2)
set(Foo_LIBRARIES ${PREFIX}/lib/foo-1.2/libfoo.a)

If another project wishes to use Foo it need only to locate the FooConfig.cmake file and load it to get all the information it needs about package content locations. Since the package configuration file is provided by the package installation it already knows all the file locations.

The find_package() command may be used to search for the package configuration file. This command constructs a set of installation prefixes and searches under each prefix in several locations. Given the name Foo, it looks for a file called FooConfig.cmake or foo-config.cmake. The full set of locations is specified in the find_package() command documentation. One place it looks is:

<prefix>/lib/cmake/Foo*/

where Foo* is a case-insensitive globbing expression. In our example the globbing expression will match <prefix>/lib/cmake/foo-1.2 and the package configuration file will be found.

Once found, a package configuration file is immediately loaded. It, together with a package version file, contains all the information the project needs to use the package.

Package Version File

When the find_package() command finds a candidate package configuration file it looks next to it for a version file. The version file is loaded to test whether the package version is an acceptable match for the version requested. If the version file claims compatibility the configuration file is accepted. Otherwise it is ignored.

The name of the package version file must match that of the package configuration file but has either -version or Version appended to the name before the .cmake extension. For example, the files:

<prefix>/lib/cmake/foo-1.3/foo-config.cmake
<prefix>/lib/cmake/foo-1.3/foo-config-version.cmake

and:

<prefix>/lib/cmake/bar-4.2/BarConfig.cmake
<prefix>/lib/cmake/bar-4.2/BarConfigVersion.cmake

are each pairs of package configuration files and corresponding package version files.

When the find_package() command loads a version file it first sets the following variables:

PACKAGE_FIND_NAME
The <PackageName>
PACKAGE_FIND_VERSION
Full requested version string
PACKAGE_FIND_VERSION_MAJOR
Major version if requested, else 0
PACKAGE_FIND_VERSION_MINOR
Minor version if requested, else 0
PACKAGE_FIND_VERSION_PATCH
Patch version if requested, else 0
PACKAGE_FIND_VERSION_TWEAK
Tweak version if requested, else 0
PACKAGE_FIND_VERSION_COUNT
Number of version components, 0 to 4

The version file must use these variables to check whether it is compatible or an exact match for the requested version and set the following variables with results:

PACKAGE_VERSION
Full provided version string
PACKAGE_VERSION_EXACT
True if version is exact match
PACKAGE_VERSION_COMPATIBLE
True if version is compatible
PACKAGE_VERSION_UNSUITABLE
True if unsuitable as any version

Version files are loaded in a nested scope so they are free to set any variables they wish as part of their computation. The find_package command wipes out the scope when the version file has completed and it has checked the output variables. When the version file claims to be an acceptable match for the requested version the find_package command sets the following variables for use by the project:

<PackageName>_VERSION
Full provided version string
<PackageName>_VERSION_MAJOR
Major version if provided, else 0
<PackageName>_VERSION_MINOR
Minor version if provided, else 0
<PackageName>_VERSION_PATCH
Patch version if provided, else 0
<PackageName>_VERSION_TWEAK
Tweak version if provided, else 0
<PackageName>_VERSION_COUNT
Number of version components, 0 to 4

The variables report the version of the package that was actually found. The <PackageName> part of their name matches the argument given to the find_package() command.

Creating Packages

Usually, the upstream depends on CMake itself and can use some CMake facilities for creating the package files. Consider an upstream which provides a single shared library:

project(UpstreamLib)

set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE ON)

set(Upstream_VERSION 3.4.1)

include(GenerateExportHeader)

add_library(ClimbingStats SHARED climbingstats.cpp)
generate_export_header(ClimbingStats)
set_property(TARGET ClimbingStats PROPERTY VERSION ${Upstream_VERSION})
set_property(TARGET ClimbingStats PROPERTY SOVERSION 3)
set_property(TARGET ClimbingStats PROPERTY
  INTERFACE_ClimbingStats_MAJOR_VERSION 3)
set_property(TARGET ClimbingStats APPEND PROPERTY
  COMPATIBLE_INTERFACE_STRING ClimbingStats_MAJOR_VERSION
)

install(TARGETS ClimbingStats EXPORT ClimbingStatsTargets
  LIBRARY DESTINATION lib
  ARCHIVE DESTINATION lib
  RUNTIME DESTINATION bin
  INCLUDES DESTINATION include
)
install(
  FILES
    climbingstats.h
    "${CMAKE_CURRENT_BINARY_DIR}/climbingstats_export.h"
  DESTINATION
    include
  COMPONENT
    Devel
)

include(CMakePackageConfigHelpers)
write_basic_package_version_file(
  "${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfigVersion.cmake"
  VERSION ${Upstream_VERSION}
  COMPATIBILITY AnyNewerVersion
)

export(EXPORT ClimbingStatsTargets
  FILE "${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsTargets.cmake"
  NAMESPACE Upstream::
)
configure_file(cmake/ClimbingStatsConfig.cmake
  "${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfig.cmake"
  COPYONLY
)

set(ConfigPackageLocation lib/cmake/ClimbingStats)
install(EXPORT ClimbingStatsTargets
  FILE
    ClimbingStatsTargets.cmake
  NAMESPACE
    Upstream::
  DESTINATION
    ${ConfigPackageLocation}
)
install(
  FILES
    cmake/ClimbingStatsConfig.cmake
    "${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfigVersion.cmake"
  DESTINATION
    ${ConfigPackageLocation}
  COMPONENT
    Devel
)

The CMakePackageConfigHelpers module provides a macro for creating a simple ConfigVersion.cmake file. This file sets the version of the package. It is read by CMake when find_package() is called to determine the compatibility with the requested version, and to set some version-specific variables <PackageName>_VERSION, <PackageName>_VERSION_MAJOR, <PackageName>_VERSION_MINOR etc. The install(EXPORT) command is used to export the targets in the ClimbingStatsTargets export-set, defined previously by the install(TARGETS) command. This command generates the ClimbingStatsTargets.cmake file to contain IMPORTED targets, suitable for use by downstreams and arranges to install it to lib/cmake/ClimbingStats. The generated ClimbingStatsConfigVersion.cmake and a cmake/ClimbingStatsConfig.cmake are installed to the same location, completing the package.

The generated IMPORTED targets have appropriate properties set to define their usage requirements, such as INTERFACE_INCLUDE_DIRECTORIES, INTERFACE_COMPILE_DEFINITIONS and other relevant built-in INTERFACE_ properties. The INTERFACE variant of user-defined properties listed in COMPATIBLE_INTERFACE_STRING and other Compatible Interface Properties are also propagated to the generated IMPORTED targets. In the above case, ClimbingStats_MAJOR_VERSION is defined as a string which must be compatible among the dependencies of any depender. By setting this custom defined user property in this version and in the next version of ClimbingStats, cmake(1) will issue a diagnostic if there is an attempt to use version 3 together with version 4. Packages can choose to employ such a pattern if different major versions of the package are designed to be incompatible.

A NAMESPACE with double-colons is specified when exporting the targets for installation. This convention of double-colons gives CMake a hint that the name is an IMPORTED target when it is used by downstreams with the target_link_libraries() command. This way, CMake can issue a diagnostic if the package providing it has not yet been found.

In this case, when using install(TARGETS) the INCLUDES DESTINATION was specified. This causes the IMPORTED targets to have their INTERFACE_INCLUDE_DIRECTORIES populated with the include directory in the CMAKE_INSTALL_PREFIX. When the IMPORTED target is used by downstream, it automatically consumes the entries from that property.

Creating a Package Configuration File

In this case, the ClimbingStatsConfig.cmake file could be as simple as:

include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")

As this allows downstreams to use the IMPORTED targets. If any macros should be provided by the ClimbingStats package, they should be in a separate file which is installed to the same location as the ClimbingStatsConfig.cmake file, and included from there.

This can also be extended to cover dependencies:

# ...
add_library(ClimbingStats SHARED climbingstats.cpp)
generate_export_header(ClimbingStats)

find_package(Stats 2.6.4 REQUIRED)
target_link_libraries(ClimbingStats PUBLIC Stats::Types)

As the Stats::Types target is a PUBLIC dependency of ClimbingStats, downstreams must also find the Stats package and link to the Stats::Types library. The Stats package should be found in the ClimbingStatsConfig.cmake file to ensure this. The find_dependency macro from the CMakeFindDependencyMacro helps with this by propagating whether the package is REQUIRED, or QUIET etc. All REQUIRED dependencies of a package should be found in the Config.cmake file:

include(CMakeFindDependencyMacro)
find_dependency(Stats 2.6.4)

include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake")

The find_dependency macro also sets ClimbingStats_FOUND to False if the dependency is not found, along with a diagnostic that the ClimbingStats package can not be used without the Stats package.

If COMPONENTS are specified when the downstream uses find_package(), they are listed in the <PackageName>_FIND_COMPONENTS variable. If a particular component is non-optional, then the <PackageName>_FIND_REQUIRED_<comp> will be true. This can be tested with logic in the package configuration file:

include(CMakeFindDependencyMacro)
find_dependency(Stats 2.6.4)

include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake")

set(_supported_components Plot Table)

foreach(_comp ${ClimbingStats_FIND_COMPONENTS})
  if (NOT ";${_supported_components};" MATCHES _comp)
    set(ClimbingStats_FOUND False)
    set(ClimbingStats_NOT_FOUND_MESSAGE "Unsupported component: ${_comp}")
  endif()
  include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStats${_comp}Targets.cmake")
endforeach()

Here, the ClimbingStats_NOT_FOUND_MESSAGE is set to a diagnosis that the package could not be found because an invalid component was specified. This message variable can be set for any case where the _FOUND variable is set to False, and will be displayed to the user.

Creating a Package Configuration File for the Build Tree

The export(EXPORT) command creates an IMPORTED targets definition file which is specific to the build-tree, and is not relocatable. This can similarly be used with a suitable package configuration file and package version file to define a package for the build tree which may be used without installation. Consumers of the build tree can simply ensure that the CMAKE_PREFIX_PATH contains the build directory, or set the ClimbingStats_DIR to <build_dir>/ClimbingStats in the cache.

Creating Relocatable Packages

A relocatable package must not reference absolute paths of files on the machine where the package is built that will not exist on the machines where the package may be installed.

Packages created by install(EXPORT) are designed to be relocatable, using paths relative to the location of the package itself. When defining the interface of a target for EXPORT, keep in mind that the include directories should be specified as relative paths which are relative to the CMAKE_INSTALL_PREFIX:

target_include_directories(tgt INTERFACE
  # Wrong, not relocatable:
  $<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include/TgtName>
)

target_include_directories(tgt INTERFACE
  # Ok, relocatable:
  $<INSTALL_INTERFACE:include/TgtName>
)

The $<INSTALL_PREFIX> generator expression may be used as a placeholder for the install prefix without resulting in a non-relocatable package. This is necessary if complex generator expressions are used:

target_include_directories(tgt INTERFACE
  # Ok, relocatable:
  $<INSTALL_INTERFACE:$<$<CONFIG:Debug>:$<INSTALL_PREFIX>/include/TgtName>>
)

This also applies to paths referencing external dependencies. It is not advisable to populate any properties which may contain paths, such as INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_LINK_LIBRARIES, with paths relevant to dependencies. For example, this code may not work well for a relocatable package:

target_link_libraries(ClimbingStats INTERFACE
  ${Foo_LIBRARIES} ${Bar_LIBRARIES}
  )
target_include_directories(ClimbingStats INTERFACE
  "$<INSTALL_INTERFACE:${Foo_INCLUDE_DIRS};${Bar_INCLUDE_DIRS}>"
  )

The referenced variables may contain the absolute paths to libraries and include directories as found on the machine the package was made on. This would create a package with hard-coded paths to dependencies and not suitable for relocation.

Ideally such dependencies should be used through their own IMPORTED targets that have their own IMPORTED_LOCATION and usage requirement properties such as INTERFACE_INCLUDE_DIRECTORIES populated appropriately. Those imported targets may then be used with the target_link_libraries() command for ClimbingStats:

target_link_libraries(ClimbingStats INTERFACE Foo::Foo Bar::Bar)

With this approach the package references its external dependencies only through the names of IMPORTED targets. When a consumer uses the installed package, the consumer will run the appropriate find_package() commands (via the find_dependency macro described above) to find the dependencies and populate the imported targets with appropriate paths on their own machine.

Unfortunately many modules shipped with CMake do not yet provide IMPORTED targets because their development pre-dated this approach. This may improve incrementally over time. Workarounds to create relocatable packages using such modules include:

  • When building the package, specify each Foo_LIBRARY cache entry as just a library name, e.g. -DFoo_LIBRARY=foo. This tells the corresponding find module to populate the Foo_LIBRARIES with just foo to ask the linker to search for the library instead of hard-coding a path.
  • Or, after installing the package content but before creating the package installation binary for redistribution, manually replace the absolute paths with placeholders for substitution by the installation tool when the package is installed.

Package Registry

CMake provides two central locations to register packages that have been built or installed anywhere on a system:

  • User Package Registry
  • System Package Registry

The registries are especially useful to help projects find packages in non-standard install locations or directly in their own build trees. A project may populate either the user or system registry (using its own means, see below) to refer to its location. In either case the package should store at the registered location a Package Configuration File (<PackageName>Config.cmake) and optionally a Package Version File (<PackageName>ConfigVersion.cmake).

The find_package() command searches the two package registries as two of the search steps specified in its documentation. If it has sufficient permissions it also removes stale package registry entries that refer to directories that do not exist or do not contain a matching package configuration file.

User Package Registry

The User Package Registry is stored in a per-user location. The export(PACKAGE) command may be used to register a project build tree in the user package registry. CMake currently provides no interface to add install trees to the user package registry. Installers must be manually taught to register their packages if desired.

On Windows the user package registry is stored in the Windows registry under a key in HKEY_CURRENT_USER.

A <PackageName> may appear under registry key:

HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\<PackageName>

as a REG_SZ value, with arbitrary name, that specifies the directory containing the package configuration file.

On UNIX platforms the user package registry is stored in the user home directory under ~/.cmake/packages. A <PackageName> may appear under the directory:

~/.cmake/packages/<PackageName>

as a file, with arbitrary name, whose content specifies the directory containing the package configuration file.

System Package Registry

The System Package Registry is stored in a system-wide location. CMake currently provides no interface to add to the system package registry. Installers must be manually taught to register their packages if desired.

On Windows the system package registry is stored in the Windows registry under a key in HKEY_LOCAL_MACHINE. A <PackageName> may appear under registry key:

HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\<PackageName>

as a REG_SZ value, with arbitrary name, that specifies the directory containing the package configuration file.

There is no system package registry on non-Windows platforms.

Disabling the Package Registry

In some cases using the Package Registries is not desirable. CMake allows one to disable them using the following variables:

  • CMAKE_EXPORT_NO_PACKAGE_REGISTRY disables the export(PACKAGE) command.
  • CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY disables the User Package Registry in all the find_package() calls.
  • CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY disables the System Package Registry in all the find_package() calls.

Package Registry Example

A simple convention for naming package registry entries is to use content hashes. They are deterministic and unlikely to collide ( export(PACKAGE) uses this approach). The name of an entry referencing a specific directory is simply the content hash of the directory path itself.

If a project arranges for package registry entries to exist, such as:

> reg query HKCU\Software\Kitware\CMake\Packages\MyPackage
HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\MyPackage
 45e7d55f13b87179bb12f907c8de6fc4 REG_SZ c:/Users/Me/Work/lib/cmake/MyPackage
 7b4a9844f681c80ce93190d4e3185db9 REG_SZ c:/Users/Me/Work/MyPackage-build

or:

$ cat ~/.cmake/packages/MyPackage/7d1fb77e07ce59a81bed093bbee945bd
/home/me/work/lib/cmake/MyPackage
$ cat ~/.cmake/packages/MyPackage/f92c1db873a1937f3100706657c63e07
/home/me/work/MyPackage-build

then the CMakeLists.txt code:

find_package(MyPackage)

will search the registered locations for package configuration files (MyPackageConfig.cmake). The search order among package registry entries for a single package is unspecified and the entry names (hashes in this example) have no meaning. Registered locations may contain package version files (MyPackageConfigVersion.cmake) to tell find_package() whether a specific location is suitable for the version requested.

Package Registry Ownership

Package registry entries are individually owned by the project installations that they reference. A package installer is responsible for adding its own entry and the corresponding uninstaller is responsible for removing it.

The export(PACKAGE) command populates the user package registry with the location of a project build tree. Build trees tend to be deleted by developers and have no “uninstall” event that could trigger removal of their entries. In order to keep the registries clean the find_package() command automatically removes stale entries it encounters if it has sufficient permissions. CMake provides no interface to remove an entry referencing an existing build tree once export(PACKAGE) has been invoked. However, if the project removes its package configuration file from the build tree then the entry referencing the location will be considered stale.


cmake-policies(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-policies(7)

Contents

  • cmake-policies(7)
    • Introduction
    • Policies Introduced by CMake 3.14
    • Policies Introduced by CMake 3.13
    • Policies Introduced by CMake 3.12
    • Policies Introduced by CMake 3.11
    • Policies Introduced by CMake 3.10
    • Policies Introduced by CMake 3.9
    • Policies Introduced by CMake 3.8
    • Policies Introduced by CMake 3.7
    • Policies Introduced by CMake 3.4
    • Policies Introduced by CMake 3.3
    • Policies Introduced by CMake 3.2
    • Policies Introduced by CMake 3.1
    • Policies Introduced by CMake 3.0
    • Policies Introduced by CMake 2.8
    • Policies Introduced by CMake 2.6

Introduction

Policies in CMake are used to preserve backward compatible behavior across multiple releases. When a new policy is introduced, newer CMake versions will begin to warn about the backward compatible behavior. It is possible to disable the warning by explicitly requesting the OLD, or backward compatible behavior using the cmake_policy() command. It is also possible to request NEW, or non-backward compatible behavior for a policy, also avoiding the warning. Each policy can also be set to either NEW or OLD behavior explicitly on the command line with the CMAKE_POLICY_DEFAULT_CMP<NNNN> variable.

A policy is a deprecation mechanism and not a reliable feature toggle. A policy should almost never be set to OLD, except to silence warnings in an otherwise frozen or stable codebase, or temporarily as part of a larger migration path. The OLD behavior of each policy is undesirable and will be replaced with an error condition in a future release.

The cmake_minimum_required() command does more than report an error if a too-old version of CMake is used to build a project. It also sets all policies introduced in that CMake version or earlier to NEW behavior. To manage policies without increasing the minimum required CMake version, the if(POLICY) command may be used:

if(POLICY CMP0990)
  cmake_policy(SET CMP0990 NEW)
endif()

This has the effect of using the NEW behavior with newer CMake releases which users may be using and not issuing a compatibility warning.

The setting of a policy is confined in some cases to not propagate to the parent scope. For example, if the files read by the include() command or the find_package() command contain a use of cmake_policy(), that policy setting will not affect the caller by default. Both commands accept an optional NO_POLICY_SCOPE keyword to control this behavior.

The CMAKE_MINIMUM_REQUIRED_VERSION variable may also be used to determine whether to report an error on use of deprecated macros or functions.

Policies Introduced by CMake 3.14

  • CMP0088: FindBISON runs bison in CMAKE_CURRENT_BINARY_DIR when executing.
  • CMP0087: install(SCRIPT | CODE) supports generator expressions.
  • CMP0086: UseSWIG honors SWIG_MODULE_NAME via -module flag.
  • CMP0085: IN_LIST generator expression handles empty list items.
  • CMP0084: The FindQt module does not exist for find_package().
  • CMP0083: Add PIE options when linking executable.
  • CMP0082: Install rules from add_subdirectory() are interleaved with those in caller.

Policies Introduced by CMake 3.13

  • CMP0081: Relative paths not allowed in LINK_DIRECTORIES target property.
  • CMP0080: BundleUtilities cannot be included at configure time.
  • CMP0079: target_link_libraries allows use with targets in other directories.
  • CMP0078: UseSWIG generates standard target names.
  • CMP0077: option() honors normal variables.
  • CMP0076: target_sources() command converts relative paths to absolute.

Policies Introduced by CMake 3.12

  • CMP0075: Include file check macros honor CMAKE_REQUIRED_LIBRARIES.
  • CMP0074: find_package uses PackageName_ROOT variables.
  • CMP0073: Do not produce legacy _LIB_DEPENDS cache entries.

Policies Introduced by CMake 3.11

  • CMP0072: FindOpenGL prefers GLVND by default when available.

Policies Introduced by CMake 3.10

  • CMP0071: Let AUTOMOC and AUTOUIC process GENERATED files.
  • CMP0070: Define file(GENERATE) behavior for relative paths.

Policies Introduced by CMake 3.9

  • CMP0069: INTERPROCEDURAL_OPTIMIZATION is enforced when enabled.
  • CMP0068: RPATH settings on macOS do not affect install_name.

Policies Introduced by CMake 3.8

  • CMP0067: Honor language standard in try_compile() source-file signature.

Policies Introduced by CMake 3.7

  • CMP0066: Honor per-config flags in try_compile() source-file signature.

Policies Introduced by CMake 3.4

  • CMP0065: Do not add flags to export symbols from executables without the ENABLE_EXPORTS target property.
  • CMP0064: Support new TEST if() operator.

Policies Introduced by CMake 3.3

  • CMP0063: Honor visibility properties for all target types.
  • CMP0062: Disallow install() of export() result.
  • CMP0061: CTest does not by default tell make to ignore errors (-i).
  • CMP0060: Link libraries by full path even in implicit directories.
  • CMP0059: Do not treat DEFINITIONS as a built-in directory property.
  • CMP0058: Ninja requires custom command byproducts to be explicit.
  • CMP0057: Support new IN_LIST if() operator.

Policies Introduced by CMake 3.2

  • CMP0056: Honor link flags in try_compile() source-file signature.
  • CMP0055: Strict checking for break() command.

Policies Introduced by CMake 3.1

  • CMP0054: Only interpret if() arguments as variables or keywords when unquoted.
  • CMP0053: Simplify variable reference and escape sequence evaluation.
  • CMP0052: Reject source and build dirs in installed INTERFACE_INCLUDE_DIRECTORIES.
  • CMP0051: List TARGET_OBJECTS in SOURCES target property.

Policies Introduced by CMake 3.0

  • CMP0050: Disallow add_custom_command SOURCE signatures.
  • CMP0049: Do not expand variables in target source entries.
  • CMP0048: project() command manages VERSION variables.
  • CMP0047: Use QCC compiler id for the qcc drivers on QNX.
  • CMP0046: Error on non-existent dependency in add_dependencies.
  • CMP0045: Error on non-existent target in get_target_property.
  • CMP0044: Case sensitive Lang_COMPILER_ID generator expressions.
  • CMP0043: Ignore COMPILE_DEFINITIONS_Config properties.
  • CMP0042: MACOSX_RPATH is enabled by default.
  • CMP0041: Error on relative include with generator expression.
  • CMP0040: The target in the TARGET signature of add_custom_command() must exist.
  • CMP0039: Utility targets may not have link dependencies.
  • CMP0038: Targets may not link directly to themselves.
  • CMP0037: Target names should not be reserved and should match a validity pattern.
  • CMP0036: The build_name command should not be called.
  • CMP0035: The variable_requires command should not be called.
  • CMP0034: The utility_source command should not be called.
  • CMP0033: The export_library_dependencies command should not be called.
  • CMP0032: The output_required_files command should not be called.
  • CMP0031: The load_command command should not be called.
  • CMP0030: The use_mangled_mesa command should not be called.
  • CMP0029: The subdir_depends command should not be called.
  • CMP0028: Double colon in target name means ALIAS or IMPORTED target.
  • CMP0027: Conditionally linked imported targets with missing include directories.
  • CMP0026: Disallow use of the LOCATION target property.
  • CMP0025: Compiler id for Apple Clang is now AppleClang.
  • CMP0024: Disallow include export result.

Policies Introduced by CMake 2.8

  • CMP0023: Plain and keyword target_link_libraries signatures cannot be mixed.
  • CMP0022: INTERFACE_LINK_LIBRARIES defines the link interface.
  • CMP0021: Fatal error on relative paths in INCLUDE_DIRECTORIES target property.
  • CMP0020: Automatically link Qt executables to qtmain target on Windows.
  • CMP0019: Do not re-expand variables in include and link information.
  • CMP0018: Ignore CMAKE_SHARED_LIBRARY_Lang_FLAGS variable.
  • CMP0017: Prefer files from the CMake module directory when including from there.
  • CMP0016: target_link_libraries() reports error if its only argument is not a target.
  • CMP0015: link_directories() treats paths relative to the source dir.
  • CMP0014: Input directories must have CMakeLists.txt.
  • CMP0013: Duplicate binary directories are not allowed.
  • CMP0012: if() recognizes numbers and boolean constants.

Policies Introduced by CMake 2.6

  • CMP0011: Included scripts do automatic cmake_policy PUSH and POP.
  • CMP0010: Bad variable reference syntax is an error.
  • CMP0009: FILE GLOB_RECURSE calls should not follow symlinks by default.
  • CMP0008: Libraries linked by full-path must have a valid library file name.
  • CMP0007: list command no longer ignores empty elements.
  • CMP0006: Installing MACOSX_BUNDLE targets requires a BUNDLE DESTINATION.
  • CMP0005: Preprocessor definition values are now escaped automatically.
  • CMP0004: Libraries linked may not have leading or trailing whitespace.
  • CMP0003: Libraries linked via full path no longer produce linker search paths.
  • CMP0002: Logical target names must be globally unique.
  • CMP0001: CMAKE_BACKWARDS_COMPATIBILITY should no longer be used.
  • CMP0000: A minimum required CMake version must be specified.


CMP0088 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0088

FindBISON runs bison in CMAKE_CURRENT_BINARY_DIR when executing.

The module provides a BISON_TARGET macro which generates BISON output. In CMake 3.13 and below the macro would generate a custom command that runs bison in the source directory. CMake 3.14 and later prefer to run it in the build directory and use CMAKE_CURRENT_BINARY_DIR as the WORKING_DIRECTORY of its add_custom_command() invocation. This ensures that any implicitly generated file is written to the build tree rather than the source.

This policy provides compatibility for projects that have not been updated to expect the new behavior.

The OLD behavior for this policy is for BISON_TARGET to use the current source directory for the WORKING_DIRECTORY and where to generate implicit files. The NEW behavior of this policy is to use the current binary directory for the WORKING_DIRECTORY and where to generate implicit files.

This policy was introduced in CMake version 3.14. Use the cmake_policy() command to set it to OLD or NEW explicitly. Unlike most policies, CMake version 3.14.0-rc4 does not warn when this policy is not set and simply uses OLD behavior.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0087 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0087

install(CODE) and install(SCRIPT) support generator expressions.

In CMake 3.13 and earlier, install(CODE) and install(SCRIPT) did not evaluate generator expressions. CMake 3.14 and later will evaluate generator expressions for install(CODE) and install(SCRIPT).

The OLD behavior of this policy is for install(CODE) and install(SCRIPT) to not evaluate generator expressions. The NEW behavior is to evaluate generator expressions for install(CODE) and install(SCRIPT).

Note that it is the value of this policy setting at the end of the directory scope that is important, not its setting at the time of the call to install(CODE) or install(SCRIPT). This has implications for calling these commands from places that have their own policy scope but not their own directory scope (e.g. from files brought in via include() rather than add_subdirectory()).

This policy was introduced in CMake version 3.14. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0086 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0086

UseSWIG honors SWIG_MODULE_NAME via -module flag.

Starting with CMake 3.14, UseSWIG passes option -module <module_name> to SWIG compiler if the file property SWIG_MODULE_NAME is specified. This policy provides compatibility with projects that expect the legacy behavior.

The OLD behavior for this policy is to never pass -module option. The NEW behavior is to pass -module option to SWIG compiler if SWIG_MODULE_NAME is specified.

This policy was introduced in CMake version 3.14. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0085 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0085

$<IN_LIST:...> handles empty list items.

In CMake 3.13 and lower, the $<IN_LIST:...> generator expression always returned 0 if the first argument was empty, even if the list contained an empty item. This behavior is inconsistent with the IN_LIST behavior of if(), which this generator expression is meant to emulate. CMake 3.14 and later handles this case correctly.

The OLD behavior of this policy is for $<IN_LIST:...> to always return 0 if the first argument is empty. The NEW behavior is to return 1 if the first argument is empty and the list contains an empty item.

This policy was introduced in CMake version 3.14. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0084 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0084

The FindQt module does not exist for find_package().

The existence of FindQt means that for Qt upstream to provide package config files that can be found by find_package(Qt), the consuming project has to explicitly specify find_package(Qt CONFIG). Removing this module gives Qt a path forward for exporting its own config files which can easily be found by consuming projects.

This policy pretends that CMake’s internal FindQt module does not exist for find_package(). If a project really wants to use Qt 3 or 4, it can call find_package(Qt[34]), include(FindQt), or add FindQt to their CMAKE_MODULE_PATH.

The OLD behavior of this policy is for FindQt to exist for find_package(). The NEW behavior is to pretend that it doesn’t exist for find_package().

This policy was introduced in CMake version 3.14. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0083 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0083

To control generation of Position Independent Executable (PIE) or not, some flags are required at link time.

CMake 3.13 and lower did not add these link flags when POSITION_INDEPENDENT_CODE is set.

The OLD behavior for this policy is to not manage PIE link flags. The NEW behavior is to add link flags if POSITION_INDEPENDENT_CODE is set:

  • Set to TRUE: flags to produce a position independent executable are passed to the linker step. For example -pie for GCC.
  • Set to FALSE: flags not to produce a position independent executable are passed to the linker step. For example -no-pie for GCC.
  • Not set: no flags are passed to the linker step.

Since a given linker may not support PIE flags in all environments in which it is used, it is the project’s responsibility to use the CheckPIESupported module to check for support to ensure that the POSITION_INDEPENDENT_CODE target property for executables will be honored at link time.

This policy was introduced in CMake version 3.14. Use the cmake_policy() command to set it to OLD or NEW explicitly. Unlike most policies, CMake version 3.14.0-rc4 does not warn when this policy is not set and simply uses OLD behavior.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

Examples

Behave like CMake 3.13 and do not apply any PIE flags at link stage.

cmake_minimum_required(VERSION 3.13)
project(foo)

# ...

add_executable(foo ...)
set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)

Use the CheckPIESupported module to detect whether PIE is supported by the current linker and environment. Apply PIE flags only if the linker supports them.

cmake_minimum_required(VERSION 3.14) # CMP0083 NEW
project(foo)

include(CheckPIESupported)
check_pie_supported()

# ...

add_executable(foo ...)
set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)

  • cmake-policies(7) »


CMP0082 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0082

Install rules from add_subdirectory() calls are interleaved with those in caller.

CMake 3.13 and lower ran the install rules from add_subdirectory() after all other install rules, even if add_subdirectory() was called before the other install rules. CMake 3.14 and later interleaves these add_subdirectory() install rules with the others so that they are run in the order they are declared.

The OLD behavior for this policy is to run the install rules from add_subdirectory() after the other install rules. The NEW behavior for this policy is to run all install rules in the order they are declared.

This policy was introduced in CMake version 3.14. Unlike most policies, CMake version 3.14.0-rc4 does not warn by default when this policy is not set and simply uses OLD behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0082 variable to control the warning.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0081 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0081

Relative paths not allowed in LINK_DIRECTORIES target property.

CMake 3.12 and lower allowed the LINK_DIRECTORIES directory property to contain relative paths. The base path for such relative entries is not well defined. CMake 3.13 and later will issue a FATAL_ERROR if the LINK_DIRECTORIES target property (which is initialized by the LINK_DIRECTORIES directory property) contains a relative path.

The OLD behavior for this policy is not to warn about relative paths in the LINK_DIRECTORIES target property. The NEW behavior for this policy is to issue a FATAL_ERROR if LINK_DIRECTORIES contains a relative path.

This policy was introduced in CMake version 3.13. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0080 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0080

BundleUtilities cannot be included at configure time.

The macros provided by BundleUtilities are intended to be invoked at install time rather than at configure time, because they depend on the listed targets already existing at the time they are invoked. If they are invoked at configure time, the targets haven’t been built yet, and the commands will fail.

This policy restricts the inclusion of BundleUtilities to cmake -P style scripts and install rules. Specifically, it looks for the presence of CMAKE_GENERATOR and throws a fatal error if it exists.

The OLD behavior of this policy is to allow BundleUtilities to be included at configure time. The NEW behavior of this policy is to disallow such inclusion.

This policy was introduced in CMake version 3.13. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0079 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0079

target_link_libraries() allows use with targets in other directories.

Prior to CMake 3.13 the target_link_libraries() command did not accept targets not created in the calling directory as its first argument for calls that update the LINK_LIBRARIES of the target itself. It did accidentally accept targets from other directories on calls that only update the INTERFACE_LINK_LIBRARIES, but would simply add entries to the property as if the call were made in the original directory. Thus link interface libraries specified this way were always looked up by generators in the scope of the original target rather than in the scope that called target_link_libraries().

CMake 3.13 now allows the target_link_libraries() command to be called from any directory to add link dependencies and link interface libraries to targets created in other directories. The entries are added to LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES using a special (internal) suffix to tell the generators to look up the names in the calling scope rather than the scope that created the target.

This policy provides compatibility with projects that already use target_link_libraries() with the INTERFACE keyword on a target in another directory to add INTERFACE_LINK_LIBRARIES entries to be looked up in the target’s directory. Such projects should be updated to be aware of the new scoping rules in that case.

The OLD behavior of this policy is to disallow target_link_libraries() calls naming targets from another directory except in the previously accidentally allowed case of using the INTERFACE keyword only. The NEW behavior of this policy is to allow all such calls but use the new scoping rules.

This policy was introduced in CMake version 3.13. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0078 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0078

UseSWIG generates standard target names.

Starting with CMake 3.13, UseSWIG generates now standard target names. This policy provides compatibility with projects that expect the legacy behavior.

The OLD behavior for this policy relies on UseSWIG_TARGET_NAME_PREFERENCE variable that can be used to specify an explicit preference. The value may be one of:

  • LEGACY: legacy strategy is applied. Variable SWIG_MODULE_<name>_REAL_NAME must be used to get real target name. This is the default if not specified.
  • STANDARD: target name matches specified name.

This policy was introduced in CMake version 3.13. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0077 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0077

option() honors normal variables.

The option() command is typically used to create a cache entry to allow users to set the option. However, there are cases in which a normal (non-cached) variable of the same name as the option may be defined by the project prior to calling the option() command. For example, a project that embeds another project as a subdirectory may want to hard-code options of the subproject to build the way it needs.

For historical reasons in CMake 3.12 and below the option() command removes a normal (non-cached) variable of the same name when:

  • a cache entry of the specified name does not exist at all, or
  • a cache entry of the specified name exists but has not been given a type (e.g. via -D<name>=ON on the command line).

In both of these cases (typically on the first run in a new build tree), the option() command gives the cache entry type BOOL and removes any normal (non-cached) variable of the same name. In the remaining case that the cache entry of the specified name already exists and has a type (typically on later runs in a build tree), the option() command changes nothing and any normal variable of the same name remains set.

In CMake 3.13 and above the option() command prefers to do nothing when a normal variable of the given name already exists. It does not create or update a cache entry or remove the normal variable. The new behavior is consistent between the first and later runs in a build tree. This policy provides compatibility with projects that have not been updated to expect the new behavior.

When the option() command sees a normal variable of the given name:

  • The OLD behavior for this policy is to proceed even when a normal variable of the same name exists. If the cache entry does not already exist and have a type then it is created and/or given a type and the normal variable is removed.
  • The NEW behavior for this policy is to do nothing when a normal variable of the same name exists. The normal variable is not removed. The cache entry is not created or updated and is ignored if it exists.

This policy was introduced in CMake version 3.13. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0076 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0076

The target_sources() command converts relative paths to absolute.

In CMake 3.13 and above, the target_sources() command now converts relative source file paths to absolute paths in the following cases:

  • Source files are added to the target’s INTERFACE_SOURCES property.
  • The target’s SOURCE_DIR property differs from CMAKE_CURRENT_SOURCE_DIR.

A path that begins with a generator expression is always left unmodified.

This policy provides compatibility with projects that have not been updated to expect this behavior. The OLD behavior for this policy is to leave all relative source file paths unmodified. The NEW behavior of this policy is to convert relative paths to absolute according to above rules.

This policy was introduced in CMake version 3.13. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0075 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0075

Include file check macros honor CMAKE_REQUIRED_LIBRARIES.

In CMake 3.12 and above, the

  • check_include_file macro in the CheckIncludeFile module, the
  • check_include_file_cxx macro in the CheckIncludeFileCXX module, and the
  • check_include_files macro in the CheckIncludeFiles module

now prefer to link the check executable to the libraries listed in the CMAKE_REQUIRED_LIBRARIES variable. This policy provides compatibility with projects that have not been updated to expect this behavior.

The OLD behavior for this policy is to ignore CMAKE_REQUIRED_LIBRARIES in the include file check macros. The NEW behavior of this policy is to honor CMAKE_REQUIRED_LIBRARIES in the include file check macros.

This policy was introduced in CMake version 3.12. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0074 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0074

find_package() uses <PackageName>_ROOT variables.

In CMake 3.12 and above the find_package(<PackageName>) command now searches prefixes specified by the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable. Package roots are maintained as a stack so nested calls to all find_* commands inside find modules also search the roots as prefixes. This policy provides compatibility with projects that have not been updated to avoid using <PackageName>_ROOT variables for other purposes.

The OLD behavior for this policy is to ignore <PackageName>_ROOT variables. The NEW behavior for this policy is to use <PackageName>_ROOT variables.

This policy was introduced in CMake version 3.12. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0073 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0073

Do not produce legacy _LIB_DEPENDS cache entries.

Ancient CMake versions once used <tgt>_LIB_DEPENDS cache entries to propagate library link dependencies. This has long been done by other means, leaving the export_library_dependencies() command as the only user of these values. That command has long been disallowed by policy CMP0033, but the <tgt>_LIB_DEPENDS cache entries were left for compatibility with possible non-standard uses by projects.

CMake 3.12 and above now prefer to not produce these cache entries at all. This policy provides compatibility with projects that have not been updated to avoid using them.

The OLD behavior for this policy is to set <tgt>_LIB_DEPENDS cache entries. The NEW behavior for this policy is to not set them.

This policy was introduced in CMake version 3.12. Use the cmake_policy() command to set it to OLD or NEW explicitly. Unlike most policies, CMake version 3.14.0-rc4 does not warn when this policy is not set and simply uses OLD behavior.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0072 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0072

FindOpenGL prefers GLVND by default when available.

The FindOpenGL module provides an OpenGL::GL target and an OPENGL_LIBRARIES variable for projects to use for legacy GL interfaces. When both a legacy GL library (e.g. libGL.so) and GLVND libraries for OpenGL and GLX (e.g. libOpenGL.so and libGLX.so) are available, the module must choose between them. It documents an OpenGL_GL_PREFERENCE variable that can be used to specify an explicit preference. When no such preference is set, the module must choose a default preference.

CMake 3.11 and above prefer to choose GLVND libraries. This policy provides compatibility with projects that expect the legacy GL library to be used.

The OLD behavior for this policy is to set OpenGL_GL_PREFERENCE to LEGACY. The NEW behavior for this policy is to set OpenGL_GL_PREFERENCE to GLVND.

This policy was introduced in CMake version 3.11. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0071 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0071

Let AUTOMOC and AUTOUIC process GENERATED files.

Since version 3.10, CMake processes regular and GENERATED source files in AUTOMOC and AUTOUIC. In earlier CMake versions, only regular source files were processed. GENERATED source files were ignored silently.

This policy affects how source files that are GENERATED get treated in AUTOMOC and AUTOUIC.

The OLD behavior for this policy is to ignore GENERATED source files in AUTOMOC and AUTOUIC.

The NEW behavior for this policy is to process GENERATED source files in AUTOMOC and AUTOUIC just like regular source files.

Note

To silence the CMP0071 warning source files can be excluded from AUTOMOC and AUTOUIC processing by setting the source file properties SKIP_AUTOMOC, SKIP_AUTOUIC or SKIP_AUTOGEN.

Source skip example:

# ...
set_property(SOURCE /path/to/file1.h PROPERTY SKIP_AUTOMOC ON)
set_property(SOURCE /path/to/file2.h PROPERTY SKIP_AUTOUIC ON)
set_property(SOURCE /path/to/file3.h PROPERTY SKIP_AUTOGEN ON)
# ...

This policy was introduced in CMake version 3.10. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0070 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0070

Define file(GENERATE) behavior for relative paths.

CMake 3.10 and newer define that relative paths given to INPUT and OUTPUT arguments of file(GENERATE) are interpreted relative to the current source and binary directories, respectively. CMake 3.9 and lower did not define any behavior for relative paths but did not diagnose them either and accidentally treated them relative to the process working directory. Policy CMP0070 provides compatibility with projects that used the old undefined behavior.

This policy affects behavior of relative paths given to file(GENERATE). The OLD behavior for this policy is to treat the paths relative to the working directory of CMake. The NEW behavior for this policy is to interpret relative paths with respect to the current source or binary directory of the caller.

This policy was introduced in CMake version 3.10. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0069 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0069

INTERPROCEDURAL_OPTIMIZATION is enforced when enabled.

CMake 3.9 and newer prefer to add IPO flags whenever the INTERPROCEDURAL_OPTIMIZATION target property is enabled and produce an error if flags are not known to CMake for the current compiler. Since a given compiler may not support IPO flags in all environments in which it is used, it is now the project’s responsibility to use the CheckIPOSupported module to check for support before enabling the INTERPROCEDURAL_OPTIMIZATION target property. This approach allows a project to conditionally activate IPO when supported. It also allows an end user to set the CMAKE_INTERPROCEDURAL_OPTIMIZATION variable in an environment known to support IPO even if the project does not enable the property.

Since CMake 3.8 and lower only honored INTERPROCEDURAL_OPTIMIZATION for the Intel compiler on Linux, some projects may unconditionally enable the target property. Policy CMP0069 provides compatibility with such projects.

This policy takes effect whenever the IPO property is enabled. The OLD behavior for this policy is to add IPO flags only for Intel compiler on Linux. The NEW behavior for this policy is to add IPO flags for the current compiler or produce an error if CMake does not know the flags.

This policy was introduced in CMake version 3.9. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

Examples

Behave like CMake 3.8 and do not apply any IPO flags except for Intel compiler on Linux:

cmake_minimum_required(VERSION 3.8)
project(foo)

# ...

set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

Use the CheckIPOSupported module to detect whether IPO is supported by the current compiler, environment, and CMake version. Produce a fatal error if support is not available:

cmake_minimum_required(VERSION 3.9) # CMP0069 NEW
project(foo)

include(CheckIPOSupported)
check_ipo_supported()

# ...

set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

Apply IPO flags only if compiler supports it:

cmake_minimum_required(VERSION 3.9) # CMP0069 NEW
project(foo)

include(CheckIPOSupported)

# ...

check_ipo_supported(RESULT result)
if(result)
  set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
endif()

Apply IPO flags without any checks. This may lead to build errors if IPO is not supported by the compiler in the current environment. Produce an error if CMake does not know IPO flags for the current compiler:

cmake_minimum_required(VERSION 3.9) # CMP0069 NEW
project(foo)

# ...

set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

  • cmake-policies(7) »


CMP0068 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0068

RPATH settings on macOS do not affect install_name.

CMake 3.9 and newer remove any effect the following settings may have on the install_name of a target on macOS:

  • BUILD_WITH_INSTALL_RPATH target property
  • SKIP_BUILD_RPATH target property
  • CMAKE_SKIP_RPATH variable
  • CMAKE_SKIP_INSTALL_RPATH variable

Previously, setting BUILD_WITH_INSTALL_RPATH had the effect of setting both the install_name of a target to INSTALL_NAME_DIR and the RPATH to INSTALL_RPATH. In CMake 3.9, it only affects setting of RPATH. However, if one wants INSTALL_NAME_DIR to apply to the target in the build tree, one may set BUILD_WITH_INSTALL_NAME_DIR.

If SKIP_BUILD_RPATH, CMAKE_SKIP_RPATH or CMAKE_SKIP_INSTALL_RPATH were used to strip the directory portion of the install_name of a target, one may set INSTALL_NAME_DIR="" instead.

The OLD behavior of this policy is to use the RPATH settings for install_name on macOS. The NEW behavior of this policy is to ignore the RPATH settings for install_name on macOS.

This policy was introduced in CMake version 3.9. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0067 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0067

Honor language standard in try_compile() source-file signature.

The try_compile() source file signature is intended to allow callers to check whether they will be able to compile a given source file with the current toolchain. In order to match compiler behavior, any language standard mode should match. However, CMake 3.7 and below did not do this. CMake 3.8 and above prefer to honor the language standard settings for C, CXX (C++), and CUDA using the values of the variables:

  • CMAKE_C_STANDARD
  • CMAKE_C_STANDARD_REQUIRED
  • CMAKE_C_EXTENSIONS
  • CMAKE_CXX_STANDARD
  • CMAKE_CXX_STANDARD_REQUIRED
  • CMAKE_CXX_EXTENSIONS
  • CMAKE_CUDA_STANDARD
  • CMAKE_CUDA_STANDARD_REQUIRED
  • CMAKE_CUDA_EXTENSIONS

This policy provides compatibility for projects that do not expect the language standard settings to be used automatically.

The OLD behavior of this policy is to ignore language standard setting variables when generating the try_compile test project. The NEW behavior of this policy is to honor language standard setting variables.

This policy was introduced in CMake version 3.8. Unlike most policies, CMake version 3.14.0-rc4 does not warn by default when this policy is not set and simply uses OLD behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0067 variable to control the warning.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0066 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0066

Honor per-config flags in try_compile() source-file signature.

The source file signature of the try_compile() command uses the value of the CMAKE_<LANG>_FLAGS variable in the test project so that the test compilation works as it would in the main project. However, CMake 3.6 and below do not also honor config-specific compiler flags such as those in the CMAKE_<LANG>_FLAGS_DEBUG variable. CMake 3.7 and above prefer to honor config-specific compiler flags too. This policy provides compatibility for projects that do not expect config-specific compiler flags to be used.

The OLD behavior of this policy is to ignore config-specific flag variables like CMAKE_<LANG>_FLAGS_DEBUG and only use CMake’s built-in defaults for the current compiler and platform.

The NEW behavior of this policy is to honor config-specific flag variabldes like CMAKE_<LANG>_FLAGS_DEBUG.

This policy was introduced in CMake version 3.7. Unlike most policies, CMake version 3.14.0-rc4 does not warn by default when this policy is not set and simply uses OLD behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0066 variable to control the warning.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0065 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0065

Do not add flags to export symbols from executables without the ENABLE_EXPORTS target property.

CMake 3.3 and below, for historical reasons, always linked executables on some platforms with flags like -rdynamic to export symbols from the executables for use by any plugins they may load via dlopen. CMake 3.4 and above prefer to do this only for executables that are explicitly marked with the ENABLE_EXPORTS target property.

The OLD behavior of this policy is to always use the additional link flags when linking executables regardless of the value of the ENABLE_EXPORTS target property.

The NEW behavior of this policy is to only use the additional link flags when linking executables if the ENABLE_EXPORTS target property is set to True.

This policy was introduced in CMake version 3.4. Unlike most policies, CMake version 3.14.0-rc4 does not warn by default when this policy is not set and simply uses OLD behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0065 variable to control the warning.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0064 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0064

Recognize TEST as a operator for the if() command.

The TEST operator was added to the if() command to determine if a given test name was created by the add_test() command.

The OLD behavior for this policy is to ignore the TEST operator. The NEW behavior is to interpret the TEST operator.

This policy was introduced in CMake version 3.4. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0063 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0063

Honor visibility properties for all target types.

The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target properties affect visibility of symbols during dynamic linking. When first introduced these properties affected compilation of sources only in shared libraries, module libraries, and executables with the ENABLE_EXPORTS property set. This was sufficient for the basic use cases of shared libraries and executables with plugins. However, some sources may be compiled as part of static libraries or object libraries and then linked into a shared library later. CMake 3.3 and above prefer to honor these properties for sources compiled in all target types. This policy preserves compatibility for projects expecting the properties to work only for some target types.

The OLD behavior for this policy is to ignore the visibility properties for static libraries, object libraries, and executables without exports. The NEW behavior for this policy is to honor the visibility properties for all target types.

This policy was introduced in CMake version 3.3. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0062 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0062

Disallow install() of export() result.

The export() command generates a file containing Imported Targets, which is suitable for use from the build directory. It is not suitable for installation because it contains absolute paths to buildsystem locations, and is particular to a single build configuration.

The install(EXPORT) generates and installs files which contain Imported Targets. These files are generated with relative paths (unless the user specifies absolute paths), and are designed for multi-configuration use. See Creating Packages for more.

CMake 3.3 no longer allows the use of the install(FILES) command with the result of the export() command.

The OLD behavior for this policy is to allow installing the result of an export() command. The NEW behavior for this policy is not to allow installing the result of an export() command.

This policy was introduced in CMake version 3.3. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0061 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0061

CTest does not by default tell make to ignore errors (-i).

The ctest_build() and build_command() commands no longer generate build commands for Makefile Generators with the -i option. Previously this was done to help build as much of tested projects as possible. However, this behavior is not consistent with other generators and also causes the return code of the make tool to be meaningless.

Of course users may still add this option manually by setting CTEST_BUILD_COMMAND or the MAKECOMMAND cache entry. See the CTest Build Step MakeCommand setting documentation for their effects.

The OLD behavior for this policy is to add -i to make calls in CTest. The NEW behavior for this policy is to not add -i.

This policy was introduced in CMake version 3.3. Unlike most policies, CMake version 3.14.0-rc4 does not warn when this policy is not set and simply uses OLD behavior.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0060 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0060

Link libraries by full path even in implicit directories.

Policy CMP0003 was introduced with the intention of always linking library files by full path when a full path is given to the target_link_libraries() command. However, on some platforms (e.g. HP-UX) the compiler front-end adds alternative library search paths for the current architecture (e.g. /usr/lib/<arch> has alternatives to libraries in /usr/lib for the current architecture). On such platforms the find_library() may find a library such as /usr/lib/libfoo.so that does not belong to the current architecture.

Prior to policy CMP0003 projects would still build in such cases because the incorrect library path would be converted to -lfoo on the link line and the linker would find the proper library in the arch-specific search path provided by the compiler front-end implicitly. At the time we chose to remain compatible with such projects by always converting library files found in implicit link directories to -lfoo flags to ask the linker to search for them. This approach allowed existing projects to continue to build while still linking to libraries outside implicit link directories via full path (such as those in the build tree).

CMake does allow projects to override this behavior by using an IMPORTED library target with its IMPORTED_LOCATION property set to the desired full path to a library file. In fact, many Find Modules are learning to provide Imported Targets instead of just the traditional Foo_LIBRARIES variable listing library files. However, this makes the link line generated for a library found by a Find Module depend on whether it is linked through an imported target or not, which is inconsistent. Furthermore, this behavior has been a source of confusion because the generated link line for a library file depends on its location. It is also problematic for projects trying to link statically because flags like -Wl,-Bstatic -lfoo -Wl,-Bdynamic may be used to help the linker select libfoo.a instead of libfoo.so but then leak dynamic linking to following libraries. (See the LINK_SEARCH_END_STATIC target property for a solution typically used for that problem.)

When the special case for libraries in implicit link directories was first introduced the list of implicit link directories was simply hard-coded (e.g. /lib, /usr/lib, and a few others). Since that time, CMake has learned to detect the implicit link directories used by the compiler front-end. If necessary, the find_library() command could be taught to use this information to help find libraries of the proper architecture.

For these reasons, CMake 3.3 and above prefer to drop the special case and link libraries by full path even when they are in implicit link directories. Policy CMP0060 provides compatibility for existing projects.

The OLD behavior for this policy is to ask the linker to search for libraries whose full paths are known to be in implicit link directories. The NEW behavior for this policy is to link libraries by full path even if they are in implicit link directories.

This policy was introduced in CMake version 3.3. Unlike most policies, CMake version 3.14.0-rc4 does not warn by default when this policy is not set and simply uses OLD behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0060 variable to control the warning.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0059 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0059

Do not treat DEFINITIONS as a built-in directory property.

CMake 3.3 and above no longer make a list of definitions available through the DEFINITIONS directory property. The COMPILE_DEFINITIONS directory property may be used instead.

The OLD behavior for this policy is to provide the list of flags given so far to the add_definitions() command. The NEW behavior is to behave as a normal user-defined directory property.

This policy was introduced in CMake version 3.3. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0058 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0058

Ninja requires custom command byproducts to be explicit.

When an intermediate file generated during the build is consumed by an expensive operation or a large tree of dependents, one may reduce the work needed for an incremental rebuild by updating the file timestamp only when its content changes. With this approach the generation rule must have a separate output file that is always updated with a new timestamp that is newer than any dependencies of the rule so that the build tool re-runs the rule only when the input changes. We refer to the separate output file as a rule’s witness and the generated file as a rule’s byproduct.

Byproducts may not be listed as outputs because their timestamps are allowed to be older than the inputs. No build tools (like make) that existed when CMake was designed have a way to express byproducts. Therefore CMake versions prior to 3.2 had no way to specify them. Projects typically left byproducts undeclared in the rules that generate them. For example:

add_custom_command(
  OUTPUT witness.txt
  COMMAND ${CMAKE_COMMAND} -E copy_if_different
          ${CMAKE_CURRENT_SOURCE_DIR}/input.txt
          byproduct.txt # timestamp may not change
  COMMAND ${CMAKE_COMMAND} -E touch witness.txt
  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/input.txt
  )
add_custom_target(Provider DEPENDS witness.txt)
add_custom_command(
  OUTPUT generated.c
  COMMAND expensive-task -i byproduct.txt -o generated.c
  DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/byproduct.txt
  )
add_library(Consumer generated.c)
add_dependencies(Consumer Provider)

This works well for all generators except Ninja. The Ninja build tool sees a rule listing byproduct.txt as a dependency and no rule listing it as an output. Ninja then complains that there is no way to satisfy the dependency and stops building even though there are order-only dependencies that ensure byproduct.txt will exist before its consumers need it. See discussion of this problem in Ninja Issue 760 for further details on why Ninja works this way.

Instead of leaving byproducts undeclared in the rules that generate them, Ninja expects byproducts to be listed along with other outputs. Such rules may be marked with a restat option that tells Ninja to check the timestamps of outputs after the rules run. This prevents byproducts whose timestamps do not change from causing their dependents to re-build unnecessarily.

Since the above approach does not tell CMake what custom command generates byproduct.txt, the Ninja generator does not have enough information to add the byproduct as an output of any rule. CMake 2.8.12 and above work around this problem and allow projects using the above approach to build by generating phony build rules to tell Ninja to tolerate such missing files. However, this workaround prevents Ninja from diagnosing a dependency that is really missing. It also works poorly in in-source builds where every custom command dependency, even on source files, needs to be treated this way because CMake does not have enough information to know which files are generated as byproducts of custom commands.

CMake 3.2 introduced the BYPRODUCTS option to the add_custom_command() and add_custom_target() commands. This option allows byproducts to be specified explicitly:

add_custom_command(
  OUTPUT witness.txt
  BYPRODUCTS byproduct.txt # explicit byproduct specification
  COMMAND ${CMAKE_COMMAND} -E copy_if_different
          ${CMAKE_CURRENT_SOURCE_DIR}/input.txt
          byproduct.txt # timestamp may not change
...

The BYPRODUCTS option is used by the Ninja generator to list byproducts among the outputs of the custom commands that generate them, and is ignored by other generators.

CMake 3.3 and above prefer to require projects to specify custom command byproducts explicitly so that it can avoid using the phony rule workaround altogether. Policy CMP0058 was introduced to provide compatibility with existing projects that still need the workaround.

This policy has no effect on generators other than Ninja. The OLD behavior for this policy is to generate Ninja phony rules for unknown dependencies in the build tree. The NEW behavior for this policy is to not generate these and instead require projects to specify custom command BYPRODUCTS explicitly.

This policy was introduced in CMake version 3.3. CMake version 3.14.0-rc4 warns when it sees unknown dependencies in out-of-source build trees if the policy is not set and then uses OLD behavior. Use the cmake_policy() command to set the policy to OLD or NEW explicitly. The policy setting must be in scope at the end of the top-level CMakeLists.txt file of the project and has global effect.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0057 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0057

Support new if() IN_LIST operator.

CMake 3.3 adds support for the new IN_LIST operator.

The OLD behavior for this policy is to ignore the IN_LIST operator. The NEW behavior is to interpret the IN_LIST operator.

This policy was introduced in CMake version 3.3. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0056 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0056

Honor link flags in try_compile() source-file signature.

The try_compile() command source-file signature generates a CMakeLists.txt file to build the source file into an executable. In order to compile the source the same way as it might be compiled by the calling project, the generated project sets the value of the CMAKE_<LANG>_FLAGS variable to that in the calling project. The value of the CMAKE_EXE_LINKER_FLAGS variable may be needed in some cases too, but CMake 3.1 and lower did not set it in the generated project. CMake 3.2 and above prefer to set it so that linker flags are honored as well as compiler flags. This policy provides compatibility with the pre-3.2 behavior.

The OLD behavior for this policy is to not set the value of the CMAKE_EXE_LINKER_FLAGS variable in the generated test project. The NEW behavior for this policy is to set the value of the CMAKE_EXE_LINKER_FLAGS variable in the test project to the same as it is in the calling project.

If the project code does not set the policy explicitly, users may set it on the command line by defining the CMAKE_POLICY_DEFAULT_CMP0056 variable in the cache.

This policy was introduced in CMake version 3.2. Unlike most policies, CMake version 3.14.0-rc4 does not warn by default when this policy is not set and simply uses OLD behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0056 variable to control the warning.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0055 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0055

Strict checking for the break() command.

CMake 3.1 and lower allowed calls to the break() command outside of a loop context and also ignored any given arguments. This was undefined behavior.

The OLD behavior for this policy is to allow break() to be placed outside of loop contexts and ignores any arguments. The NEW behavior for this policy is to issue an error if a misplaced break or any arguments are found.

This policy was introduced in CMake version 3.2. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0054 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0054

Only interpret if() arguments as variables or keywords when unquoted.

CMake 3.1 and above no longer implicitly dereference variables or interpret keywords in an if() command argument when it is a Quoted Argument or a Bracket Argument.

The OLD behavior for this policy is to dereference variables and interpret keywords even if they are quoted or bracketed. The NEW behavior is to not dereference variables or interpret keywords that have been quoted or bracketed.

Given the following partial example:

set(A E)
set(E "")

if("${A}" STREQUAL "")
  message("Result is TRUE before CMake 3.1 or when CMP0054 is OLD")
else()
  message("Result is FALSE in CMake 3.1 and above if CMP0054 is NEW")
endif()

After explicit expansion of variables this gives:

if("E" STREQUAL "")

With the policy set to OLD implicit expansion reduces this semantically to:

if("" STREQUAL "")

With the policy set to NEW the quoted arguments will not be further dereferenced:

if("E" STREQUAL "")

This policy was introduced in CMake version 3.1. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0053 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0053

Simplify variable reference and escape sequence evaluation.

CMake 3.1 introduced a much faster implementation of evaluation of the Variable References and Escape Sequences documented in the cmake-language(7) manual. While the behavior is identical to the legacy implementation in most cases, some corner cases were cleaned up to simplify the behavior. Specifically:

  • Expansion of @VAR@ reference syntax defined by the configure_file() and string(CONFIGURE) commands is no longer performed in other contexts.

  • Literal ${VAR} reference syntax may contain only alphanumeric characters (A-Z, a-z, 0-9) and the characters _, ., /, -, and +. Note that $ is technically allowed in the NEW behavior, but is invalid for OLD behavior. This is due to an oversight during the implementation of CMP0053 and its use as a literal variable reference is discouraged for this reason. Variables with other characters in their name may still be referenced indirectly, e.g.

    set(varname "otherwise & disallowed $ characters")
message("${${varname}}")

  • The setting of policy CMP0010 is not considered, so improper variable reference syntax is always an error.

  • More characters are allowed to be escaped in variable names. Previously, only ()#" \@^ were valid characters to escape. Now any non-alphanumeric, non-semicolon, non-NUL character may be escaped following the escape_identity production in the Escape Sequences section of the cmake-language(7) manual.

The OLD behavior for this policy is to honor the legacy behavior for variable references and escape sequences. The NEW behavior is to use the simpler variable expansion and escape sequence evaluation rules.

This policy was introduced in CMake version 3.1. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0052 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0052

Reject source and build dirs in installed INTERFACE_INCLUDE_DIRECTORIES.

CMake 3.0 and lower allowed subdirectories of the source directory or build directory to be in the INTERFACE_INCLUDE_DIRECTORIES of installed and exported targets, if the directory was also a subdirectory of the installation prefix. This makes the installation depend on the existence of the source dir or binary dir, and the installation will be broken if either are removed after installation.

See Include Directories and Usage Requirements for more on specifying include directories for targets.

The OLD behavior for this policy is to export the content of the INTERFACE_INCLUDE_DIRECTORIES with the source or binary directory. The NEW behavior for this policy is to issue an error if such a directory is used.

This policy was introduced in CMake version 3.1. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0051 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0051

List TARGET_OBJECTS in SOURCES target property.

CMake 3.0 and lower did not include the TARGET_OBJECTS generator expression when returning the SOURCES target property.

Configure-time CMake code is not able to handle generator expressions. If using the SOURCES target property at configure time, it may be necessary to first remove generator expressions using the string(GENEX_STRIP) command. Generate-time CMake code such as file(GENERATE) can handle the content without stripping.

The OLD behavior for this policy is to omit TARGET_OBJECTS expressions from the SOURCES target property. The NEW behavior for this policy is to include TARGET_OBJECTS expressions in the output.

This policy was introduced in CMake version 3.1. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0050 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0050

Disallow add_custom_command SOURCE signatures.

CMake 2.8.12 and lower allowed a signature for add_custom_command() which specified an input to a command. This was undocumented behavior. Modern use of CMake associates custom commands with their output, rather than their input.

The OLD behavior for this policy is to allow the use of add_custom_command() SOURCE signatures. The NEW behavior for this policy is to issue an error if such a signature is used.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0049 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0049

Do not expand variables in target source entries.

CMake 2.8.12 and lower performed an extra layer of variable expansion when evaluating source file names:

set(a_source foo.c)
add_executable(foo \${a_source})

This was undocumented behavior.

The OLD behavior for this policy is to expand such variables when processing the target sources. The NEW behavior for this policy is to issue an error if such variables need to be expanded.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0048 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0048

The project() command manages VERSION variables.

CMake version 3.0 introduced the VERSION option of the project() command to specify a project version as well as the name. In order to keep PROJECT_VERSION and related variables consistent with variable PROJECT_NAME it is necessary to set the VERSION variables to the empty string when no VERSION is given to project(). However, this can change behavior for existing projects that set VERSION variables themselves since project() may now clear them. This policy controls the behavior for compatibility with such projects.

The OLD behavior for this policy is to leave VERSION variables untouched. The NEW behavior for this policy is to set VERSION as documented by the project() command.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0047 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0047

Use QCC compiler id for the qcc drivers on QNX.

CMake 3.0 and above recognize that the QNX qcc compiler driver is different from the GNU compiler. CMake now prefers to present this to projects by setting the CMAKE_<LANG>_COMPILER_ID variable to QCC instead of GNU. However, existing projects may assume the compiler id for QNX qcc is just GNU as it was in CMake versions prior to 3.0. Therefore this policy determines for QNX qcc which compiler id to report in the CMAKE_<LANG>_COMPILER_ID variable after language <LANG> is enabled by the project() or enable_language() command. The policy must be set prior to the invocation of either command.

The OLD behavior for this policy is to use the GNU compiler id for the qcc and QCC compiler drivers. The NEW behavior for this policy is to use the QCC compiler id for those drivers.

This policy was introduced in CMake version 3.0. Use the cmake_policy() command to set this policy to OLD or NEW explicitly. Unlike most policies, CMake version 3.14.0-rc4 does not warn by default when this policy is not set and simply uses OLD behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0047 variable to control the warning.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0046 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0046

Error on non-existent dependency in add_dependencies.

CMake 2.8.12 and lower silently ignored non-existent dependencies listed in the add_dependencies() command.

The OLD behavior for this policy is to silently ignore non-existent dependencies. The NEW behavior for this policy is to report an error if non-existent dependencies are listed in the add_dependencies() command.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0045 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0045

Error on non-existent target in get_target_property.

In CMake 2.8.12 and lower, the get_target_property() command accepted a non-existent target argument without issuing any error or warning. The result variable is set to a -NOTFOUND value.

The OLD behavior for this policy is to issue no warning and set the result variable to a -NOTFOUND value. The NEW behavior for this policy is to issue a FATAL_ERROR if the command is called with a non-existent target.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0044 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0044

Case sensitive <LANG>_COMPILER_ID generator expressions

CMake 2.8.12 introduced the <LANG>_COMPILER_ID generator expressions to allow comparison of the CMAKE_<LANG>_COMPILER_ID with a test value. The possible valid values are lowercase, but the comparison with the test value was performed case-insensitively.

The OLD behavior for this policy is to perform a case-insensitive comparison with the value in the <LANG>_COMPILER_ID expression. The NEW behavior for this policy is to perform a case-sensitive comparison with the value in the <LANG>_COMPILER_ID expression.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0043 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0043

Ignore COMPILE_DEFINITIONS_<Config> properties

CMake 2.8.12 and lower allowed setting the COMPILE_DEFINITIONS_<CONFIG> target property and COMPILE_DEFINITIONS_<CONFIG> directory property to apply configuration-specific compile definitions.

Since CMake 2.8.10, the COMPILE_DEFINITIONS property has supported generator expressions for setting configuration-dependent content. The continued existence of the suffixed variables is redundant, and causes a maintenance burden. Population of the COMPILE_DEFINITIONS_DEBUG property may be replaced with a population of COMPILE_DEFINITIONS directly or via target_compile_definitions():

# Old Interfaces:
set_property(TARGET tgt APPEND PROPERTY
  COMPILE_DEFINITIONS_DEBUG DEBUG_MODE
)
set_property(DIRECTORY APPEND PROPERTY
  COMPILE_DEFINITIONS_DEBUG DIR_DEBUG_MODE
)

# New Interfaces:
set_property(TARGET tgt APPEND PROPERTY
  COMPILE_DEFINITIONS $<$<CONFIG:Debug>:DEBUG_MODE>
)
target_compile_definitions(tgt PRIVATE $<$<CONFIG:Debug>:DEBUG_MODE>)
set_property(DIRECTORY APPEND PROPERTY
  COMPILE_DEFINITIONS $<$<CONFIG:Debug>:DIR_DEBUG_MODE>
)

The OLD behavior for this policy is to consume the content of the suffixed COMPILE_DEFINITIONS_<CONFIG> target property when generating the compilation command. The NEW behavior for this policy is to ignore the content of the COMPILE_DEFINITIONS_<CONFIG> target property .

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0042 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0042

MACOSX_RPATH is enabled by default.

CMake 2.8.12 and newer has support for using @rpath in a target’s install name. This was enabled by setting the target property MACOSX_RPATH. The @rpath in an install name is a more flexible and powerful mechanism than @executable_path or @loader_path for locating shared libraries.

CMake 3.0 and later prefer this property to be ON by default. Projects wanting @rpath in a target’s install name may remove any setting of the INSTALL_NAME_DIR and CMAKE_INSTALL_NAME_DIR variables.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0041 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0041

Error on relative include with generator expression.

Diagnostics in CMake 2.8.12 and lower silently ignored an entry in the INTERFACE_INCLUDE_DIRECTORIES of a target if it contained a generator expression at any position.

The path entries in that target property should not be relative. High-level API should ensure that by adding either a source directory or a install directory prefix, as appropriate.

As an additional diagnostic, the INTERFACE_INCLUDE_DIRECTORIES generated on an IMPORTED target for the install location should not contain paths in the source directory or the build directory.

The OLD behavior for this policy is to ignore relative path entries if they contain a generator expression. The NEW behavior for this policy is to report an error if a generator expression appears in another location and the path is relative.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0040 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0040

The target in the TARGET signature of add_custom_command() must exist and must be defined in the current directory.

CMake 2.8.12 and lower silently ignored a custom command created with the TARGET signature of add_custom_command() if the target is unknown or was defined outside the current directory.

The OLD behavior for this policy is to ignore custom commands for unknown targets. The NEW behavior for this policy is to report an error if the target referenced in add_custom_command() is unknown or was defined outside the current directory.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0039 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0039

Utility targets may not have link dependencies.

CMake 2.8.12 and lower allowed using utility targets in the left hand side position of the target_link_libraries() command. This is an indicator of a bug in user code.

The OLD behavior for this policy is to ignore attempts to set the link libraries of utility targets. The NEW behavior for this policy is to report an error if an attempt is made to set the link libraries of a utility target.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0038 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0038

Targets may not link directly to themselves.

CMake 2.8.12 and lower allowed a build target to link to itself directly with a target_link_libraries() call. This is an indicator of a bug in user code.

The OLD behavior for this policy is to ignore targets which list themselves in their own link implementation. The NEW behavior for this policy is to report an error if a target attempts to link to itself.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0037 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0037

Target names should not be reserved and should match a validity pattern.

CMake 2.8.12 and lower allowed creating targets using add_library(), add_executable() and add_custom_target() with unrestricted choice for the target name. Newer cmake features such as cmake-generator-expressions(7) and some diagnostics expect target names to match a restricted pattern.

Target names may contain upper and lower case letters, numbers, the underscore character (_), dot(.), plus(+) and minus(-). As a special case, ALIAS targets and IMPORTED targets may contain two consecutive colons.

Target names reserved by one or more CMake generators are not allowed. Among others these include “all”, “clean”, “help”, and “install”.

Target names associated with optional features, such as “test” and “package”, may also be reserved. CMake 3.10 and below always reserve them. CMake 3.11 and above reserve them only when the corresponding feature is enabled (e.g. by including the CTest or CPack modules).

The OLD behavior for this policy is to allow creating targets with reserved names or which do not match the validity pattern. The NEW behavior for this policy is to report an error if an add_* command is used with an invalid target name.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0036 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0036

The build_name() command should not be called.

This command was added in May 2001 to compute a name for the current operating system and compiler combination. The command has long been documented as discouraged and replaced by the CMAKE_SYSTEM and CMAKE_<LANG>_COMPILER variables.

CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy is to allow the command to be called. The NEW behavior for this policy is to issue a FATAL_ERROR when the command is called.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0035 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0035

The variable_requires() command should not be called.

This command was introduced in November 2001 to perform some conditional logic. It has long been replaced by the if() command.

CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy is to allow the command to be called. The NEW behavior for this policy is to issue a FATAL_ERROR when the command is called.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0034 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0034

The utility_source() command should not be called.

This command was introduced in March 2001 to help build executables used to generate other files. This approach has long been replaced by add_executable() combined with add_custom_command().

CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy is to allow the command to be called. The NEW behavior for this policy is to issue a FATAL_ERROR when the command is called.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0033 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0033

The export_library_dependencies() command should not be called.

This command was added in January 2003 to export <tgt>_LIB_DEPENDS internal CMake cache entries to a file for installation with a project. This was used at the time to allow transitive link dependencies to work for applications outside of the original build tree of a project. The functionality has been superseded by the export() and install(EXPORT) commands.

CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy is to allow the command to be called. The NEW behavior for this policy is to issue a FATAL_ERROR when the command is called.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0032 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0032

The output_required_files() command should not be called.

This command was added in June 2001 to expose the then-current CMake implicit dependency scanner. CMake’s real implicit dependency scanner has evolved since then but is not exposed through this command. The scanning capabilities of this command are very limited and this functionality is better achieved through dedicated outside tools.

CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy is to allow the command to be called. The NEW behavior for this policy is to issue a FATAL_ERROR when the command is called.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0031 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0031

The load_command() command should not be called.

This command was added in August 2002 to allow projects to add arbitrary commands implemented in C or C++. However, it does not work when the toolchain in use does not match the ABI of the CMake process. It has been mostly superseded by the macro() and function() commands.

CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy is to allow the command to be called. The NEW behavior for this policy is to issue a FATAL_ERROR when the command is called.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0030 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0030

The use_mangled_mesa() command should not be called.

This command was created in September 2001 to support VTK before modern CMake language and custom command capabilities. VTK has not used it in years.

CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy is to allow the command to be called. The NEW behavior for this policy is to issue a FATAL_ERROR when the command is called.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0029 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0029

The subdir_depends() command should not be called.

The implementation of this command has been empty since December 2001 but was kept in CMake for compatibility for a long time.

CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy is to allow the command to be called. The NEW behavior for this policy is to issue a FATAL_ERROR when the command is called.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0028 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0028

Double colon in target name means ALIAS or IMPORTED target.

CMake 2.8.12 and lower allowed the use of targets and files with double colons in target_link_libraries, with some buildsystem generators.

The use of double-colons is a common pattern used to namespace IMPORTED targets and ALIAS targets. When computing the link dependencies of a target, the name of each dependency could either be a target, or a file on disk. Previously, if a target was not found with a matching name, the name was considered to refer to a file on disk. This can lead to confusing error messages if there is a typo in what should be a target name.

The OLD behavior for this policy is to search for targets, then files on disk, even if the search term contains double-colons. The NEW behavior for this policy is to issue a FATAL_ERROR if a link dependency contains double-colons but is not an IMPORTED target or an ALIAS target.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0027 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0027

Conditionally linked imported targets with missing include directories.

CMake 2.8.11 introduced introduced the concept of INTERFACE_INCLUDE_DIRECTORIES, and a check at cmake time that the entries in the INTERFACE_INCLUDE_DIRECTORIES of an IMPORTED target actually exist. CMake 2.8.11 also introduced generator expression support in the target_link_libraries command. However, if an imported target is linked as a result of a generator expression evaluation, the entries in the INTERFACE_INCLUDE_DIRECTORIES of that target were not checked for existence as they should be.

The OLD behavior of this policy is to report a warning if an entry in the INTERFACE_INCLUDE_DIRECTORIES of a generator-expression conditionally linked IMPORTED target does not exist.

The NEW behavior of this policy is to report an error if an entry in the INTERFACE_INCLUDE_DIRECTORIES of a generator-expression conditionally linked IMPORTED target does not exist.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0026 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0026

Disallow use of the LOCATION property for build targets.

CMake 2.8.12 and lower allowed reading the LOCATION target property (and configuration-specific variants) to determine the eventual location of build targets. This relies on the assumption that all necessary information is available at configure-time to determine the final location and filename of the target. However, this property is not fully determined until later at generate-time. At generate time, the $<TARGET_FILE> generator expression can be used to determine the eventual LOCATION of a target output.

Code which reads the LOCATION target property can be ported to use the $<TARGET_FILE> generator expression together with the file(GENERATE) subcommand to generate a file containing the target location.

The OLD behavior for this policy is to allow reading the LOCATION properties from build-targets. The NEW behavior for this policy is to not to allow reading the LOCATION properties from build-targets.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0025 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0025

Compiler id for Apple Clang is now AppleClang.

CMake 3.0 and above recognize that Apple Clang is a different compiler than upstream Clang and that they have different version numbers. CMake now prefers to present this to projects by setting the CMAKE_<LANG>_COMPILER_ID variable to AppleClang instead of Clang. However, existing projects may assume the compiler id for Apple Clang is just Clang as it was in CMake versions prior to 3.0. Therefore this policy determines for Apple Clang which compiler id to report in the CMAKE_<LANG>_COMPILER_ID variable after language <LANG> is enabled by the project() or enable_language() command. The policy must be set prior to the invocation of either command.

The OLD behavior for this policy is to use compiler id Clang. The NEW behavior for this policy is to use compiler id AppleClang.

This policy was introduced in CMake version 3.0. Use the cmake_policy() command to set this policy to OLD or NEW explicitly. Unlike most policies, CMake version 3.14.0-rc4 does not warn by default when this policy is not set and simply uses OLD behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0025 variable to control the warning.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0024 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0024

Disallow include export result.

CMake 2.8.12 and lower allowed use of the include() command with the result of the export() command. This relies on the assumption that the export() command has an immediate effect at configure-time during a cmake run. Certain properties of targets are not fully determined until later at generate-time, such as the link language and complete list of link libraries. Future refactoring will change the effect of the export() command to be executed at generate-time. Use ALIAS targets instead in cases where the goal is to refer to targets by another name.

The OLD behavior for this policy is to allow including the result of an export() command. The NEW behavior for this policy is not to allow including the result of an export() command.

This policy was introduced in CMake version 3.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0023 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0023

Plain and keyword target_link_libraries signatures cannot be mixed.

CMake 2.8.12 introduced the target_link_libraries signature using the PUBLIC, PRIVATE, and INTERFACE keywords to generalize the LINK_PUBLIC and LINK_PRIVATE keywords introduced in CMake 2.8.7. Use of signatures with any of these keywords sets the link interface of a target explicitly, even if empty. This produces confusing behavior when used in combination with the historical behavior of the plain target_link_libraries signature. For example, consider the code:

target_link_libraries(mylib A)
target_link_libraries(mylib PRIVATE B)

After the first line the link interface has not been set explicitly so CMake would use the link implementation, A, as the link interface. However, the second line sets the link interface to empty. In order to avoid this subtle behavior CMake now prefers to disallow mixing the plain and keyword signatures of target_link_libraries for a single target.

The OLD behavior for this policy is to allow keyword and plain target_link_libraries signatures to be mixed. The NEW behavior for this policy is to not to allow mixing of the keyword and plain signatures.

This policy was introduced in CMake version 2.8.12. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0022 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0022

INTERFACE_LINK_LIBRARIES defines the link interface.

CMake 2.8.11 constructed the ‘link interface’ of a target from properties matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?. The modern way to specify config-sensitive content is to use generator expressions and the IMPORTED_ prefix makes uniform processing of the link interface with generator expressions impossible. The INTERFACE_LINK_LIBRARIES target property was introduced as a replacement in CMake 2.8.12. This new property is named consistently with the INTERFACE_COMPILE_DEFINITIONS, INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_OPTIONS properties. For in-build targets, CMake will use the INTERFACE_LINK_LIBRARIES property as the source of the link interface only if policy CMP0022 is NEW. When exporting a target which has this policy set to NEW, only the INTERFACE_LINK_LIBRARIES property will be processed and generated for the IMPORTED target by default. A new option to the install(EXPORT) and export commands allows export of the old-style properties for compatibility with downstream users of CMake versions older than 2.8.12. The target_link_libraries command will no longer populate the properties matching LINK_INTERFACE_LIBRARIES(_<CONFIG>)? if this policy is NEW.

Warning-free future-compatible code which works with CMake 2.8.7 onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC keywords of target_link_libraries().

The OLD behavior for this policy is to ignore the INTERFACE_LINK_LIBRARIES property for in-build targets. The NEW behavior for this policy is to use the INTERFACE_LINK_LIBRARIES property for in-build targets, and ignore the old properties matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?.

This policy was introduced in CMake version 2.8.12. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0021 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0021

Fatal error on relative paths in INCLUDE_DIRECTORIES target property.

CMake 2.8.10.2 and lower allowed the INCLUDE_DIRECTORIES target property to contain relative paths. The base path for such relative entries is not well defined. CMake 2.8.12 issues a FATAL_ERROR if the INCLUDE_DIRECTORIES property contains a relative path.

The OLD behavior for this policy is not to warn about relative paths in the INCLUDE_DIRECTORIES target property. The NEW behavior for this policy is to issue a FATAL_ERROR if INCLUDE_DIRECTORIES contains a relative path.

This policy was introduced in CMake version 2.8.12. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0020 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0020

Automatically link Qt executables to qtmain target on Windows.

CMake 2.8.10 and lower required users of Qt to always specify a link dependency to the qtmain.lib static library manually on Windows. CMake 2.8.11 gained the ability to evaluate generator expressions while determining the link dependencies from IMPORTED targets. This allows CMake itself to automatically link executables which link to Qt to the qtmain.lib library when using IMPORTED Qt targets. For applications already linking to qtmain.lib, this should have little impact. For applications which supply their own alternative WinMain implementation and for applications which use the QAxServer library, this automatic linking will need to be disabled as per the documentation.

The OLD behavior for this policy is not to link executables to qtmain.lib automatically when they link to the QtCore IMPORTED target. The NEW behavior for this policy is to link executables to qtmain.lib automatically when they link to QtCore IMPORTED target.

This policy was introduced in CMake version 2.8.11. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0019 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0019

Do not re-expand variables in include and link information.

CMake 2.8.10 and lower re-evaluated values given to the include_directories, link_directories, and link_libraries commands to expand any leftover variable references at the end of the configuration step. This was for strict compatibility with VERY early CMake versions because all variable references are now normally evaluated during CMake language processing. CMake 2.8.11 and higher prefer to skip the extra evaluation.

The OLD behavior for this policy is to re-evaluate the values for strict compatibility. The NEW behavior for this policy is to leave the values untouched.

This policy was introduced in CMake version 2.8.11. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0018 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0018

Ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS variable.

CMake 2.8.8 and lower compiled sources in SHARED and MODULE libraries using the value of the undocumented CMAKE_SHARED_LIBRARY_<Lang>_FLAGS platform variable. The variable contained platform-specific flags needed to compile objects for shared libraries. Typically it included a flag such as -fPIC for position independent code but also included other flags needed on certain platforms. CMake 2.8.9 and higher prefer instead to use the POSITION_INDEPENDENT_CODE target property to determine what targets should be position independent, and new undocumented platform variables to select flags while ignoring CMAKE_SHARED_LIBRARY_<Lang>_FLAGS completely.

The default for either approach produces identical compilation flags, but if a project modifies CMAKE_SHARED_LIBRARY_<Lang>_FLAGS from its original value this policy determines which approach to use.

The OLD behavior for this policy is to ignore the POSITION_INDEPENDENT_CODE property for all targets and use the modified value of CMAKE_SHARED_LIBRARY_<Lang>_FLAGS for SHARED and MODULE libraries.

The NEW behavior for this policy is to ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS whether it is modified or not and honor the POSITION_INDEPENDENT_CODE target property.

This policy was introduced in CMake version 2.8.9. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0017 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0017

Prefer files from the CMake module directory when including from there.

Starting with CMake 2.8.4, if a cmake-module shipped with CMake (i.e. located in the CMake module directory) calls include() or find_package(), the files located in the CMake module directory are preferred over the files in CMAKE_MODULE_PATH. This makes sure that the modules belonging to CMake always get those files included which they expect, and against which they were developed and tested. In all other cases, the files found in CMAKE_MODULE_PATH still take precedence over the ones in the CMake module directory. The OLD behavior is to always prefer files from CMAKE_MODULE_PATH over files from the CMake modules directory.

This policy was introduced in CMake version 2.8.4. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0016 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0016

target_link_libraries() reports error if its only argument is not a target.

In CMake 2.8.2 and lower the target_link_libraries() command silently ignored if it was called with only one argument, and this argument wasn’t a valid target. In CMake 2.8.3 and above it reports an error in this case.

This policy was introduced in CMake version 2.8.3. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0015 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0015

link_directories() treats paths relative to the source dir.

In CMake 2.8.0 and lower the link_directories() command passed relative paths unchanged to the linker. In CMake 2.8.1 and above the link_directories() command prefers to interpret relative paths with respect to CMAKE_CURRENT_SOURCE_DIR, which is consistent with include_directories() and other commands. The OLD behavior for this policy is to use relative paths verbatim in the linker command. The NEW behavior for this policy is to convert relative paths to absolute paths by appending the relative path to CMAKE_CURRENT_SOURCE_DIR.

This policy was introduced in CMake version 2.8.1. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0014 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0014

Input directories must have CMakeLists.txt.

CMake versions before 2.8 silently ignored missing CMakeLists.txt files in directories referenced by add_subdirectory() or subdirs(), treating them as if present but empty. In CMake 2.8.0 and above this policy determines whether or not the case is an error. The OLD behavior for this policy is to silently ignore the problem. The NEW behavior for this policy is to report an error.

This policy was introduced in CMake version 2.8.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0013 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0013

Duplicate binary directories are not allowed.

CMake 2.6.3 and below silently permitted add_subdirectory() calls to create the same binary directory multiple times. During build system generation files would be written and then overwritten in the build tree and could lead to strange behavior. CMake 2.6.4 and above explicitly detect duplicate binary directories. CMake 2.6.4 always considers this case an error. In CMake 2.8.0 and above this policy determines whether or not the case is an error. The OLD behavior for this policy is to allow duplicate binary directories. The NEW behavior for this policy is to disallow duplicate binary directories with an error.

This policy was introduced in CMake version 2.8.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0012 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0012

if() recognizes numbers and boolean constants.

In CMake versions 2.6.4 and lower the if() command implicitly dereferenced arguments corresponding to variables, even those named like numbers or boolean constants, except for 0 and 1. Numbers and boolean constants such as true, false, yes, no, on, off, y, n, notfound, ignore (all case insensitive) were recognized in some cases but not all. For example, the code “if(TRUE)” might have evaluated as false. Numbers such as 2 were recognized only in boolean expressions like “if(NOT 2)” (leading to false) but not as a single-argument like “if(2)” (also leading to false). Later versions of CMake prefer to treat numbers and boolean constants literally, so they should not be used as variable names.

The OLD behavior for this policy is to implicitly dereference variables named like numbers and boolean constants. The NEW behavior for this policy is to recognize numbers and boolean constants without dereferencing variables with such names.

This policy was introduced in CMake version 2.8.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0011 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0011

Included scripts do automatic cmake_policy PUSH and POP.

In CMake 2.6.2 and below, CMake Policy settings in scripts loaded by the include() and find_package() commands would affect the includer. Explicit invocations of cmake_policy(PUSH) and cmake_policy(POP) were required to isolate policy changes and protect the includer. While some scripts intend to affect the policies of their includer, most do not. In CMake 2.6.3 and above, include() and find_package() by default PUSH and POP an entry on the policy stack around an included script, but provide a NO_POLICY_SCOPE option to disable it. This policy determines whether or not to imply NO_POLICY_SCOPE for compatibility. The OLD behavior for this policy is to imply NO_POLICY_SCOPE for include() and find_package() commands. The NEW behavior for this policy is to allow the commands to do their default cmake_policy PUSH and POP.

This policy was introduced in CMake version 2.6.3. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0010 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0010

Bad variable reference syntax is an error.

In CMake 2.6.2 and below, incorrect variable reference syntax such as a missing close-brace (“${FOO”) was reported but did not stop processing of CMake code. This policy determines whether a bad variable reference is an error. The OLD behavior for this policy is to warn about the error, leave the string untouched, and continue. The NEW behavior for this policy is to report an error.

If CMP0053 is set to NEW, this policy has no effect and is treated as always being NEW.

This policy was introduced in CMake version 2.6.3. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0009 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0009

FILE GLOB_RECURSE calls should not follow symlinks by default.

In CMake 2.6.1 and below, FILE GLOB_RECURSE calls would follow through symlinks, sometimes coming up with unexpectedly large result sets because of symlinks to top level directories that contain hundreds of thousands of files.

This policy determines whether or not to follow symlinks encountered during a FILE GLOB_RECURSE call. The OLD behavior for this policy is to follow the symlinks. The NEW behavior for this policy is not to follow the symlinks by default, but only if FOLLOW_SYMLINKS is given as an additional argument to the FILE command.

This policy was introduced in CMake version 2.6.2. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0008 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0008

Libraries linked by full-path must have a valid library file name.

In CMake 2.4 and below it is possible to write code like

target_link_libraries(myexe /full/path/to/somelib)

where “somelib” is supposed to be a valid library file name such as “libsomelib.a” or “somelib.lib”. For Makefile generators this produces an error at build time because the dependency on the full path cannot be found. For VS IDE and Xcode generators this used to work by accident because CMake would always split off the library directory and ask the linker to search for the library by name (-lsomelib or somelib.lib). Despite the failure with Makefiles, some projects have code like this and build only with VS and/or Xcode. This version of CMake prefers to pass the full path directly to the native build tool, which will fail in this case because it does not name a valid library file.

This policy determines what to do with full paths that do not appear to name a valid library file. The OLD behavior for this policy is to split the library name from the path and ask the linker to search for it. The NEW behavior for this policy is to trust the given path and pass it directly to the native build tool unchanged.

This policy was introduced in CMake version 2.6.1. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0007 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0007

list command no longer ignores empty elements.

This policy determines whether the list command will ignore empty elements in the list. CMake 2.4 and below list commands ignored all empty elements in the list. For example, a;b;;c would have length 3 and not 4. The OLD behavior for this policy is to ignore empty list elements. The NEW behavior for this policy is to correctly count empty elements in a list.

This policy was introduced in CMake version 2.6.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0006 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0006

Installing MACOSX_BUNDLE targets requires a BUNDLE DESTINATION.

This policy determines whether the install(TARGETS) command must be given a BUNDLE DESTINATION when asked to install a target with the MACOSX_BUNDLE property set. CMake 2.4 and below did not distinguish application bundles from normal executables when installing targets. CMake 2.6 provides a BUNDLE option to the install(TARGETS) command that specifies rules specific to application bundles on the Mac. Projects should use this option when installing a target with the MACOSX_BUNDLE property set.

The OLD behavior for this policy is to fall back to the RUNTIME DESTINATION if a BUNDLE DESTINATION is not given. The NEW behavior for this policy is to produce an error if a bundle target is installed without a BUNDLE DESTINATION.

This policy was introduced in CMake version 2.6.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0005 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0005

Preprocessor definition values are now escaped automatically.

This policy determines whether or not CMake should generate escaped preprocessor definition values added via add_definitions. CMake versions 2.4 and below assumed that only trivial values would be given for macros in add_definitions calls. It did not attempt to escape non-trivial values such as string literals in generated build rules. CMake versions 2.6 and above support escaping of most values, but cannot assume the user has not added escapes already in an attempt to work around limitations in earlier versions.

The OLD behavior for this policy is to place definition values given to add_definitions directly in the generated build rules without attempting to escape anything. The NEW behavior for this policy is to generate correct escapes for all native build tools automatically. See documentation of the COMPILE_DEFINITIONS target property for limitations of the escaping implementation.

This policy was introduced in CMake version 2.6.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0004 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0004

Libraries linked may not have leading or trailing whitespace.

CMake versions 2.4 and below silently removed leading and trailing whitespace from libraries linked with code like

target_link_libraries(myexe " A ")

This could lead to subtle errors in user projects.

The OLD behavior for this policy is to silently remove leading and trailing whitespace. The NEW behavior for this policy is to diagnose the existence of such whitespace as an error. The setting for this policy used when checking the library names is that in effect when the target is created by an add_executable or add_library command.

This policy was introduced in CMake version 2.6.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0003 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0003

Libraries linked via full path no longer produce linker search paths.

This policy affects how libraries whose full paths are NOT known are found at link time, but was created due to a change in how CMake deals with libraries whose full paths are known. Consider the code

target_link_libraries(myexe /path/to/libA.so)

CMake 2.4 and below implemented linking to libraries whose full paths are known by splitting them on the link line into separate components consisting of the linker search path and the library name. The example code might have produced something like

... -L/path/to -lA ...

in order to link to library A. An analysis was performed to order multiple link directories such that the linker would find library A in the desired location, but there are cases in which this does not work. CMake versions 2.6 and above use the more reliable approach of passing the full path to libraries directly to the linker in most cases. The example code now produces something like

... /path/to/libA.so ....

Unfortunately this change can break code like

target_link_libraries(myexe /path/to/libA.so B)

where “B” is meant to find “/path/to/libB.so”. This code is wrong because the user is asking the linker to find library B but has not provided a linker search path (which may be added with the link_directories command). However, with the old linking implementation the code would work accidentally because the linker search path added for library A allowed library B to be found.

In order to support projects depending on linker search paths added by linking to libraries with known full paths, the OLD behavior for this policy will add the linker search paths even though they are not needed for their own libraries. When this policy is set to OLD, CMake will produce a link line such as

... -L/path/to /path/to/libA.so -lB ...

which will allow library B to be found as it was previously. When this policy is set to NEW, CMake will produce a link line such as

... /path/to/libA.so -lB ...

which more accurately matches what the project specified.

The setting for this policy used when generating the link line is that in effect when the target is created by an add_executable or add_library command. For the example described above, the code

cmake_policy(SET CMP0003 OLD) # or cmake_policy(VERSION 2.4)
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so B)

will work and suppress the warning for this policy. It may also be updated to work with the corrected linking approach:

cmake_policy(SET CMP0003 NEW) # or cmake_policy(VERSION 2.6)
link_directories(/path/to) # needed to find library B
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so B)

Even better, library B may be specified with a full path:

add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so /path/to/libB.so)

When all items on the link line have known paths CMake does not check this policy so it has no effect.

Note that the warning for this policy will be issued for at most one target. This avoids flooding users with messages for every target when setting the policy once will probably fix all targets.

This policy was introduced in CMake version 2.6.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0002 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0002

Logical target names must be globally unique.

Targets names created with add_executable, add_library, or add_custom_target are logical build target names. Logical target names must be globally unique because:

- Unique names may be referenced unambiguously both in CMake
  code and on make tool command lines.
- Logical names are used by Xcode and VS IDE generators
  to produce meaningful project names for the targets.

The logical name of executable and library targets does not have to correspond to the physical file names built. Consider using the OUTPUT_NAME target property to create two targets with the same physical name while keeping logical names distinct. Custom targets must simply have globally unique names (unless one uses the global property ALLOW_DUPLICATE_CUSTOM_TARGETS with a Makefiles generator).

This policy was introduced in CMake version 2.6.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0001 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0001

CMAKE_BACKWARDS_COMPATIBILITY should no longer be used.

The OLD behavior is to check CMAKE_BACKWARDS_COMPATIBILITY and present it to the user. The NEW behavior is to ignore CMAKE_BACKWARDS_COMPATIBILITY completely.

In CMake 2.4 and below the variable CMAKE_BACKWARDS_COMPATIBILITY was used to request compatibility with earlier versions of CMake. In CMake 2.6 and above all compatibility issues are handled by policies and the cmake_policy command. However, CMake must still check CMAKE_BACKWARDS_COMPATIBILITY for projects written for CMake 2.4 and below.

This policy was introduced in CMake version 2.6.0. CMake version 3.14.0-rc4 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


CMP0000 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-policies(7) »

CMP0000

A minimum required CMake version must be specified.

CMake requires that projects specify the version of CMake to which they have been written. This policy has been put in place so users trying to build the project may be told when they need to update their CMake. Specifying a version also helps the project build with CMake versions newer than that specified. Use the cmake_minimum_required command at the top of your main CMakeLists.txt file:

cmake_minimum_required(VERSION <major>.<minor>)

where “<major>.<minor>” is the version of CMake you want to support (such as “2.6”). The command will ensure that at least the given version of CMake is running and help newer versions be compatible with the project. See documentation of cmake_minimum_required for details.

Note that the command invocation must appear in the CMakeLists.txt file itself; a call in an included file is not sufficient. However, the cmake_policy command may be called to set policy CMP0000 to OLD or NEW behavior explicitly. The OLD behavior is to silently ignore the missing invocation. The NEW behavior is to issue an error instead of a warning. An included file may set CMP0000 explicitly to affect how this policy is enforced for the main CMakeLists.txt file.

This policy was introduced in CMake version 2.6.0.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

  • cmake-policies(7) »


cmake-properties(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-properties(7)

Contents

  • cmake-properties(7)
    • Properties of Global Scope
    • Properties on Directories
    • Properties on Targets
    • Properties on Tests
    • Properties on Source Files
    • Properties on Cache Entries
    • Properties on Installed Files
    • Deprecated Properties on Directories
    • Deprecated Properties on Targets
    • Deprecated Properties on Source Files

Properties of Global Scope

  • ALLOW_DUPLICATE_CUSTOM_TARGETS
  • AUTOGEN_SOURCE_GROUP
  • AUTOGEN_TARGETS_FOLDER
  • AUTOMOC_SOURCE_GROUP
  • AUTOMOC_TARGETS_FOLDER
  • AUTORCC_SOURCE_GROUP
  • CMAKE_C_KNOWN_FEATURES
  • CMAKE_CXX_KNOWN_FEATURES
  • CMAKE_ROLE
  • DEBUG_CONFIGURATIONS
  • DISABLED_FEATURES
  • ENABLED_FEATURES
  • ENABLED_LANGUAGES
  • FIND_LIBRARY_USE_LIB32_PATHS
  • FIND_LIBRARY_USE_LIB64_PATHS
  • FIND_LIBRARY_USE_LIBX32_PATHS
  • FIND_LIBRARY_USE_OPENBSD_VERSIONING
  • GENERATOR_IS_MULTI_CONFIG
  • GLOBAL_DEPENDS_DEBUG_MODE
  • GLOBAL_DEPENDS_NO_CYCLES
  • IN_TRY_COMPILE
  • PACKAGES_FOUND
  • PACKAGES_NOT_FOUND
  • JOB_POOLS
  • PREDEFINED_TARGETS_FOLDER
  • ECLIPSE_EXTRA_NATURES
  • ECLIPSE_EXTRA_CPROJECT_CONTENTS
  • REPORT_UNDEFINED_PROPERTIES
  • RULE_LAUNCH_COMPILE
  • RULE_LAUNCH_CUSTOM
  • RULE_LAUNCH_LINK
  • RULE_MESSAGES
  • TARGET_ARCHIVES_MAY_BE_SHARED_LIBS
  • TARGET_MESSAGES
  • TARGET_SUPPORTS_SHARED_LIBS
  • USE_FOLDERS
  • XCODE_EMIT_EFFECTIVE_PLATFORM_NAME

Properties on Directories

  • ADDITIONAL_MAKE_CLEAN_FILES
  • BINARY_DIR
  • BUILDSYSTEM_TARGETS
  • CACHE_VARIABLES
  • CLEAN_NO_CUSTOM
  • CMAKE_CONFIGURE_DEPENDS
  • COMPILE_DEFINITIONS
  • COMPILE_OPTIONS
  • DEFINITIONS
  • EXCLUDE_FROM_ALL
  • IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
  • INCLUDE_DIRECTORIES
  • INCLUDE_REGULAR_EXPRESSION
  • INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
  • INTERPROCEDURAL_OPTIMIZATION
  • LABELS
  • LINK_DIRECTORIES
  • LINK_OPTIONS
  • LISTFILE_STACK
  • MACROS
  • PARENT_DIRECTORY
  • RULE_LAUNCH_COMPILE
  • RULE_LAUNCH_CUSTOM
  • RULE_LAUNCH_LINK
  • SOURCE_DIR
  • SUBDIRECTORIES
  • TESTS
  • TEST_INCLUDE_FILES
  • VARIABLES
  • VS_GLOBAL_SECTION_POST_<section>
  • VS_GLOBAL_SECTION_PRE_<section>
  • VS_STARTUP_PROJECT

Properties on Targets

  • ALIASED_TARGET
  • ANDROID_ANT_ADDITIONAL_OPTIONS
  • ANDROID_API
  • ANDROID_API_MIN
  • ANDROID_ARCH
  • ANDROID_ASSETS_DIRECTORIES
  • ANDROID_GUI
  • ANDROID_JAR_DEPENDENCIES
  • ANDROID_JAR_DIRECTORIES
  • ANDROID_JAVA_SOURCE_DIR
  • ANDROID_NATIVE_LIB_DEPENDENCIES
  • ANDROID_NATIVE_LIB_DIRECTORIES
  • ANDROID_PROCESS_MAX
  • ANDROID_PROGUARD
  • ANDROID_PROGUARD_CONFIG_PATH
  • ANDROID_SECURE_PROPS_PATH
  • ANDROID_SKIP_ANT_STEP
  • ANDROID_STL_TYPE
  • ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>
  • ARCHIVE_OUTPUT_DIRECTORY
  • ARCHIVE_OUTPUT_NAME_<CONFIG>
  • ARCHIVE_OUTPUT_NAME
  • AUTOGEN_BUILD_DIR
  • AUTOGEN_ORIGIN_DEPENDS
  • AUTOGEN_PARALLEL
  • AUTOGEN_TARGET_DEPENDS
  • AUTOMOC_COMPILER_PREDEFINES
  • AUTOMOC_DEPEND_FILTERS
  • AUTOMOC_EXECUTABLE
  • AUTOMOC_MACRO_NAMES
  • AUTOMOC_MOC_OPTIONS
  • AUTOMOC
  • AUTOUIC
  • AUTOUIC_EXECUTABLE
  • AUTOUIC_OPTIONS
  • AUTOUIC_SEARCH_PATHS
  • AUTORCC
  • AUTORCC_EXECUTABLE
  • AUTORCC_OPTIONS
  • BINARY_DIR
  • BUILD_RPATH
  • BUILD_RPATH_USE_ORIGIN
  • BUILD_WITH_INSTALL_NAME_DIR
  • BUILD_WITH_INSTALL_RPATH
  • BUNDLE_EXTENSION
  • BUNDLE
  • C_EXTENSIONS
  • C_STANDARD
  • C_STANDARD_REQUIRED
  • COMMON_LANGUAGE_RUNTIME
  • COMPATIBLE_INTERFACE_BOOL
  • COMPATIBLE_INTERFACE_NUMBER_MAX
  • COMPATIBLE_INTERFACE_NUMBER_MIN
  • COMPATIBLE_INTERFACE_STRING
  • COMPILE_DEFINITIONS
  • COMPILE_FEATURES
  • COMPILE_FLAGS
  • COMPILE_OPTIONS
  • COMPILE_PDB_NAME
  • COMPILE_PDB_NAME_<CONFIG>
  • COMPILE_PDB_OUTPUT_DIRECTORY
  • COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>
  • <CONFIG>_OUTPUT_NAME
  • <CONFIG>_POSTFIX
  • CROSSCOMPILING_EMULATOR
  • CUDA_PTX_COMPILATION
  • CUDA_SEPARABLE_COMPILATION
  • CUDA_RESOLVE_DEVICE_SYMBOLS
  • CUDA_EXTENSIONS
  • CUDA_STANDARD
  • CUDA_STANDARD_REQUIRED
  • CXX_EXTENSIONS
  • CXX_STANDARD
  • CXX_STANDARD_REQUIRED
  • DEBUG_POSTFIX
  • DEFINE_SYMBOL
  • DEPLOYMENT_REMOTE_DIRECTORY
  • DEPLOYMENT_ADDITIONAL_FILES
  • DOTNET_TARGET_FRAMEWORK_VERSION
  • EchoString
  • ENABLE_EXPORTS
  • EXCLUDE_FROM_ALL
  • EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>
  • EXCLUDE_FROM_DEFAULT_BUILD
  • EXPORT_NAME
  • EXPORT_PROPERTIES
  • FOLDER
  • Fortran_FORMAT
  • Fortran_MODULE_DIRECTORY
  • FRAMEWORK
  • FRAMEWORK_VERSION
  • GENERATOR_FILE_NAME
  • GHS_INTEGRITY_APP
  • GHS_NO_SOURCE_GROUP_FILE
  • GNUtoMS
  • HAS_CXX
  • IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
  • IMPORTED_COMMON_LANGUAGE_RUNTIME
  • IMPORTED_CONFIGURATIONS
  • IMPORTED_GLOBAL
  • IMPORTED_IMPLIB_<CONFIG>
  • IMPORTED_IMPLIB
  • IMPORTED_LIBNAME_<CONFIG>
  • IMPORTED_LIBNAME
  • IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG>
  • IMPORTED_LINK_DEPENDENT_LIBRARIES
  • IMPORTED_LINK_INTERFACE_LANGUAGES_<CONFIG>
  • IMPORTED_LINK_INTERFACE_LANGUAGES
  • IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG>
  • IMPORTED_LINK_INTERFACE_LIBRARIES
  • IMPORTED_LINK_INTERFACE_MULTIPLICITY_<CONFIG>
  • IMPORTED_LINK_INTERFACE_MULTIPLICITY
  • IMPORTED_LOCATION_<CONFIG>
  • IMPORTED_LOCATION
  • IMPORTED_NO_SONAME_<CONFIG>
  • IMPORTED_NO_SONAME
  • IMPORTED_OBJECTS_<CONFIG>
  • IMPORTED_OBJECTS
  • IMPORTED
  • IMPORTED_SONAME_<CONFIG>
  • IMPORTED_SONAME
  • IMPORT_PREFIX
  • IMPORT_SUFFIX
  • INCLUDE_DIRECTORIES
  • INSTALL_NAME_DIR
  • INSTALL_RPATH
  • INSTALL_RPATH_USE_LINK_PATH
  • INTERFACE_AUTOUIC_OPTIONS
  • INTERFACE_COMPILE_DEFINITIONS
  • INTERFACE_COMPILE_FEATURES
  • INTERFACE_COMPILE_OPTIONS
  • INTERFACE_INCLUDE_DIRECTORIES
  • INTERFACE_LINK_DEPENDS
  • INTERFACE_LINK_DIRECTORIES
  • INTERFACE_LINK_LIBRARIES
  • INTERFACE_LINK_OPTIONS
  • INTERFACE_POSITION_INDEPENDENT_CODE
  • INTERFACE_SOURCES
  • INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
  • INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
  • INTERPROCEDURAL_OPTIMIZATION
  • IOS_INSTALL_COMBINED
  • JOB_POOL_COMPILE
  • JOB_POOL_LINK
  • LABELS
  • <LANG>_CLANG_TIDY
  • <LANG>_COMPILER_LAUNCHER
  • <LANG>_CPPCHECK
  • <LANG>_CPPLINT
  • <LANG>_INCLUDE_WHAT_YOU_USE
  • <LANG>_VISIBILITY_PRESET
  • LIBRARY_OUTPUT_DIRECTORY_<CONFIG>
  • LIBRARY_OUTPUT_DIRECTORY
  • LIBRARY_OUTPUT_NAME_<CONFIG>
  • LIBRARY_OUTPUT_NAME
  • LINK_DEPENDS_NO_SHARED
  • LINK_DEPENDS
  • LINKER_LANGUAGE
  • LINK_DIRECTORIES
  • LINK_FLAGS_<CONFIG>
  • LINK_FLAGS
  • LINK_INTERFACE_LIBRARIES_<CONFIG>
  • LINK_INTERFACE_LIBRARIES
  • LINK_INTERFACE_MULTIPLICITY_<CONFIG>
  • LINK_INTERFACE_MULTIPLICITY
  • LINK_LIBRARIES
  • LINK_OPTIONS
  • LINK_SEARCH_END_STATIC
  • LINK_SEARCH_START_STATIC
  • LINK_WHAT_YOU_USE
  • LOCATION_<CONFIG>
  • LOCATION
  • MACOSX_BUNDLE_INFO_PLIST
  • MACOSX_BUNDLE
  • MACOSX_FRAMEWORK_INFO_PLIST
  • MACOSX_RPATH
  • MANUALLY_ADDED_DEPENDENCIES
  • MAP_IMPORTED_CONFIG_<CONFIG>
  • NAME
  • NO_SONAME
  • NO_SYSTEM_FROM_IMPORTED
  • OSX_ARCHITECTURES_<CONFIG>
  • OSX_ARCHITECTURES
  • OUTPUT_NAME_<CONFIG>
  • OUTPUT_NAME
  • PDB_NAME_<CONFIG>
  • PDB_NAME
  • PDB_OUTPUT_DIRECTORY_<CONFIG>
  • PDB_OUTPUT_DIRECTORY
  • POSITION_INDEPENDENT_CODE
  • PREFIX
  • PRIVATE_HEADER
  • PROJECT_LABEL
  • PUBLIC_HEADER
  • RESOURCE
  • RULE_LAUNCH_COMPILE
  • RULE_LAUNCH_CUSTOM
  • RULE_LAUNCH_LINK
  • RUNTIME_OUTPUT_DIRECTORY_<CONFIG>
  • RUNTIME_OUTPUT_DIRECTORY
  • RUNTIME_OUTPUT_NAME_<CONFIG>
  • RUNTIME_OUTPUT_NAME
  • SKIP_BUILD_RPATH
  • SOURCE_DIR
  • SOURCES
  • SOVERSION
  • STATIC_LIBRARY_FLAGS_<CONFIG>
  • STATIC_LIBRARY_FLAGS
  • STATIC_LIBRARY_OPTIONS
  • SUFFIX
  • TYPE
  • VERSION
  • VISIBILITY_INLINES_HIDDEN
  • VS_CONFIGURATION_TYPE
  • VS_DEBUGGER_COMMAND
  • VS_DEBUGGER_COMMAND_ARGUMENTS
  • VS_DEBUGGER_ENVIRONMENT
  • VS_DEBUGGER_WORKING_DIRECTORY
  • VS_DESKTOP_EXTENSIONS_VERSION
  • VS_DOTNET_REFERENCE_<refname>
  • VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname>
  • VS_DOTNET_REFERENCES
  • VS_DOTNET_REFERENCES_COPY_LOCAL
  • VS_DOTNET_TARGET_FRAMEWORK_VERSION
  • VS_GLOBAL_KEYWORD
  • VS_GLOBAL_PROJECT_TYPES
  • VS_GLOBAL_ROOTNAMESPACE
  • VS_GLOBAL_<variable>
  • VS_IOT_EXTENSIONS_VERSION
  • VS_IOT_STARTUP_TASK
  • VS_KEYWORD
  • VS_MOBILE_EXTENSIONS_VERSION
  • VS_SCC_AUXPATH
  • VS_SCC_LOCALPATH
  • VS_SCC_PROJECTNAME
  • VS_SCC_PROVIDER
  • VS_SDK_REFERENCES
  • VS_USER_PROPS
  • VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION
  • VS_WINRT_COMPONENT
  • VS_WINRT_EXTENSIONS
  • VS_WINRT_REFERENCES
  • WIN32_EXECUTABLE
  • WINDOWS_EXPORT_ALL_SYMBOLS
  • XCODE_ATTRIBUTE_<an-attribute>
  • XCODE_EXPLICIT_FILE_TYPE
  • XCODE_PRODUCT_TYPE
  • XCODE_SCHEME_ADDRESS_SANITIZER
  • XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
  • XCODE_SCHEME_ARGUMENTS
  • XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
  • XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
  • XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
  • XCODE_SCHEME_ENVIRONMENT
  • XCODE_SCHEME_EXECUTABLE
  • XCODE_SCHEME_GUARD_MALLOC
  • XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP
  • XCODE_SCHEME_MALLOC_GUARD_EDGES
  • XCODE_SCHEME_MALLOC_SCRIBBLE
  • XCODE_SCHEME_MALLOC_STACK
  • XCODE_SCHEME_THREAD_SANITIZER
  • XCODE_SCHEME_THREAD_SANITIZER_STOP
  • XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER
  • XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP
  • XCODE_SCHEME_ZOMBIE_OBJECTS
  • XCTEST

Properties on Tests

  • ATTACHED_FILES_ON_FAIL
  • ATTACHED_FILES
  • COST
  • DEPENDS
  • DISABLED
  • ENVIRONMENT
  • FAIL_REGULAR_EXPRESSION
  • FIXTURES_CLEANUP
  • FIXTURES_REQUIRED
  • FIXTURES_SETUP
  • LABELS
  • MEASUREMENT
  • PASS_REGULAR_EXPRESSION
  • PROCESSOR_AFFINITY
  • PROCESSORS
  • REQUIRED_FILES
  • RESOURCE_LOCK
  • RUN_SERIAL
  • SKIP_RETURN_CODE
  • TIMEOUT
  • TIMEOUT_AFTER_MATCH
  • WILL_FAIL
  • WORKING_DIRECTORY

Properties on Source Files

  • ABSTRACT
  • AUTOUIC_OPTIONS
  • AUTORCC_OPTIONS
  • COMPILE_DEFINITIONS
  • COMPILE_FLAGS
  • COMPILE_OPTIONS
  • EXTERNAL_OBJECT
  • Fortran_FORMAT
  • GENERATED
  • HEADER_FILE_ONLY
  • INCLUDE_DIRECTORIES
  • KEEP_EXTENSION
  • LABELS
  • LANGUAGE
  • LOCATION
  • MACOSX_PACKAGE_LOCATION
  • OBJECT_DEPENDS
  • OBJECT_OUTPUTS
  • SKIP_AUTOGEN
  • SKIP_AUTOMOC
  • SKIP_AUTORCC
  • SKIP_AUTOUIC
  • SYMBOLIC
  • VS_COPY_TO_OUT_DIR
  • VS_CSHARP_<tagname>
  • VS_DEPLOYMENT_CONTENT
  • VS_DEPLOYMENT_LOCATION
  • VS_INCLUDE_IN_VSIX
  • VS_RESOURCE_GENERATOR
  • VS_SHADER_DISABLE_OPTIMIZATIONS
  • VS_SHADER_ENABLE_DEBUG
  • VS_SHADER_ENTRYPOINT
  • VS_SHADER_FLAGS
  • VS_SHADER_MODEL
  • VS_SHADER_OBJECT_FILE_NAME
  • VS_SHADER_OUTPUT_HEADER_FILE
  • VS_SHADER_TYPE
  • VS_SHADER_VARIABLE_NAME
  • VS_TOOL_OVERRIDE
  • VS_XAML_TYPE
  • WRAP_EXCLUDE
  • XCODE_EXPLICIT_FILE_TYPE
  • XCODE_FILE_ATTRIBUTES
  • XCODE_LAST_KNOWN_FILE_TYPE

Properties on Cache Entries

  • ADVANCED
  • HELPSTRING
  • MODIFIED
  • STRINGS
  • TYPE
  • VALUE

Properties on Installed Files

  • CPACK_DESKTOP_SHORTCUTS
  • CPACK_NEVER_OVERWRITE
  • CPACK_PERMANENT
  • CPACK_START_MENU_SHORTCUTS
  • CPACK_STARTUP_SHORTCUTS
  • CPACK_WIX_ACL

Deprecated Properties on Directories

  • COMPILE_DEFINITIONS_<CONFIG>
  • TEST_INCLUDE_FILE

Deprecated Properties on Targets

  • COMPILE_DEFINITIONS_<CONFIG>
  • POST_INSTALL_SCRIPT
  • PRE_INSTALL_SCRIPT

Deprecated Properties on Source Files

  • COMPILE_DEFINITIONS_<CONFIG>


ALLOW_DUPLICATE_CUSTOM_TARGETS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ALLOW_DUPLICATE_CUSTOM_TARGETS

Allow duplicate custom targets to be created.

Normally CMake requires that all targets built in a project have globally unique logical names (see policy CMP0002). This is necessary to generate meaningful project file names in Xcode and VS IDE generators. It also allows the target names to be referenced unambiguously.

Makefile generators are capable of supporting duplicate custom target names. For projects that care only about Makefile generators and do not wish to support Xcode or VS IDE generators, one may set this property to true to allow duplicate custom targets. The property allows multiple add_custom_target command calls in different directories to specify the same target name. However, setting this property will cause non-Makefile generators to produce an error and refuse to generate the project.

  • cmake-properties(7) »


AUTOGEN_SOURCE_GROUP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOGEN_SOURCE_GROUP

Name of the source_group() for AUTOMOC and AUTORCC generated files.

Files generated by AUTOMOC and AUTORCC are not always known at configure time and therefore can’t be passed to source_group(). AUTOGEN_SOURCE_GROUP an be used instead to generate or select a source group for AUTOMOC and AUTORCC generated files.

For AUTOMOC and AUTORCC specific overrides see AUTOMOC_SOURCE_GROUP and AUTORCC_SOURCE_GROUP respectively.

  • cmake-properties(7) »


AUTOGEN_TARGETS_FOLDER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOGEN_TARGETS_FOLDER

Name of FOLDER for *_autogen targets that are added automatically by CMake for targets for which AUTOMOC is enabled.

If not set, CMake uses the FOLDER property of the parent target as a default value for this property. See also the documentation for the FOLDER target property and the AUTOMOC target property.

  • cmake-properties(7) »


AUTOMOC_SOURCE_GROUP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOMOC_SOURCE_GROUP

Name of the source_group() for AUTOMOC generated files.

When set this is used instead of AUTOGEN_SOURCE_GROUP for files generated by AUTOMOC.

  • cmake-properties(7) »


AUTOMOC_TARGETS_FOLDER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOMOC_TARGETS_FOLDER

Name of FOLDER for *_autogen targets that are added automatically by CMake for targets for which AUTOMOC is enabled.

This property is obsolete. Use AUTOGEN_TARGETS_FOLDER instead.

If not set, CMake uses the FOLDER property of the parent target as a default value for this property. See also the documentation for the FOLDER target property and the AUTOMOC target property.

  • cmake-properties(7) »


AUTORCC_SOURCE_GROUP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTORCC_SOURCE_GROUP

Name of the source_group() for AUTORCC generated files.

When set this is used instead of AUTOGEN_SOURCE_GROUP for files generated by AUTORCC.

  • cmake-properties(7) »


CMAKE_C_KNOWN_FEATURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CMAKE_C_KNOWN_FEATURES

List of C features known to this version of CMake.

The features listed in this global property may be known to be available to the C compiler. If the feature is available with the C compiler, it will be listed in the CMAKE_C_COMPILE_FEATURES variable.

The features listed here may be used with the target_compile_features() command. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

The features known to this version of CMake are:

c_std_90
Compiler mode is aware of C 90.
c_std_99
Compiler mode is aware of C 99.
c_std_11
Compiler mode is aware of C 11.
c_function_prototypes
Function prototypes, as defined in ISO/IEC 9899:1990.
c_restrict
restrict keyword, as defined in ISO/IEC 9899:1999.
c_static_assert
Static assert, as defined in ISO/IEC 9899:2011.
c_variadic_macros
Variadic macros, as defined in ISO/IEC 9899:1999.

  • cmake-properties(7) »


CMAKE_CXX_KNOWN_FEATURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CMAKE_CXX_KNOWN_FEATURES

List of C++ features known to this version of CMake.

The features listed in this global property may be known to be available to the C++ compiler. If the feature is available with the C++ compiler, it will be listed in the CMAKE_CXX_COMPILE_FEATURES variable.

The features listed here may be used with the target_compile_features() command. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

The features known to this version of CMake are:

cxx_std_98
Compiler mode is aware of C++ 98.
cxx_std_11
Compiler mode is aware of C++ 11.
cxx_std_14
Compiler mode is aware of C++ 14.
cxx_std_17
Compiler mode is aware of C++ 17.
cxx_std_20
Compiler mode is aware of C++ 20.
cxx_aggregate_default_initializers
Aggregate default initializers, as defined in N3605.
cxx_alias_templates
Template aliases, as defined in N2258.
cxx_alignas
Alignment control alignas, as defined in N2341.
cxx_alignof
Alignment control alignof, as defined in N2341.
cxx_attributes
Generic attributes, as defined in N2761.
cxx_attribute_deprecated
[[deprecated]] attribute, as defined in N3760.
cxx_auto_type
Automatic type deduction, as defined in N1984.
cxx_binary_literals
Binary literals, as defined in N3472.
cxx_constexpr
Constant expressions, as defined in N2235.
cxx_contextual_conversions
Contextual conversions, as defined in N3323.
cxx_decltype_incomplete_return_types
Decltype on incomplete return types, as defined in N3276.
cxx_decltype
Decltype, as defined in N2343.
cxx_decltype_auto
decltype(auto) semantics, as defined in N3638.
cxx_default_function_template_args
Default template arguments for function templates, as defined in DR226
cxx_defaulted_functions
Defaulted functions, as defined in N2346.
cxx_defaulted_move_initializers
Defaulted move initializers, as defined in N3053.
cxx_delegating_constructors
Delegating constructors, as defined in N1986.
cxx_deleted_functions
Deleted functions, as defined in N2346.
cxx_digit_separators
Digit separators, as defined in N3781.
cxx_enum_forward_declarations
Enum forward declarations, as defined in N2764.
cxx_explicit_conversions
Explicit conversion operators, as defined in N2437.
cxx_extended_friend_declarations
Extended friend declarations, as defined in N1791.
cxx_extern_templates
Extern templates, as defined in N1987.
cxx_final
Override control final keyword, as defined in N2928, N3206 and N3272.
cxx_func_identifier
Predefined __func__ identifier, as defined in N2340.
cxx_generalized_initializers
Initializer lists, as defined in N2672.
cxx_generic_lambdas
Generic lambdas, as defined in N3649.
cxx_inheriting_constructors
Inheriting constructors, as defined in N2540.
cxx_inline_namespaces
Inline namespaces, as defined in N2535.
cxx_lambdas
Lambda functions, as defined in N2927.
cxx_lambda_init_captures
Initialized lambda captures, as defined in N3648.
cxx_local_type_template_args
Local and unnamed types as template arguments, as defined in N2657.
cxx_long_long_type
long long type, as defined in N1811.
cxx_noexcept
Exception specifications, as defined in N3050.
cxx_nonstatic_member_init
Non-static data member initialization, as defined in N2756.
cxx_nullptr
Null pointer, as defined in N2431.
cxx_override
Override control override keyword, as defined in N2928, N3206 and N3272.
cxx_range_for
Range-based for, as defined in N2930.
cxx_raw_string_literals
Raw string literals, as defined in N2442.
cxx_reference_qualified_functions
Reference qualified functions, as defined in N2439.
cxx_relaxed_constexpr
Relaxed constexpr, as defined in N3652.
cxx_return_type_deduction
Return type deduction on normal functions, as defined in N3386.
cxx_right_angle_brackets
Right angle bracket parsing, as defined in N1757.
cxx_rvalue_references
R-value references, as defined in N2118.
cxx_sizeof_member
Size of non-static data members, as defined in N2253.
cxx_static_assert
Static assert, as defined in N1720.
cxx_strong_enums
Strongly typed enums, as defined in N2347.
cxx_thread_local
Thread-local variables, as defined in N2659.
cxx_trailing_return_types
Automatic function return type, as defined in N2541.
cxx_unicode_literals
Unicode string literals, as defined in N2442.
cxx_uniform_initialization
Uniform initialization, as defined in N2640.
cxx_unrestricted_unions
Unrestricted unions, as defined in N2544.
cxx_user_literals
User-defined literals, as defined in N2765.
cxx_variable_templates
Variable templates, as defined in N3651.
cxx_variadic_macros
Variadic macros, as defined in N1653.
cxx_variadic_templates
Variadic templates, as defined in N2242.
cxx_template_template_parameters
Template template parameters, as defined in ISO/IEC 14882:1998.

  • cmake-properties(7) »


CMAKE_ROLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CMAKE_ROLE

Tells what mode the current running script is in. Could be one of several values:

PROJECT
Running in project mode (processing a CMakeLists.txt file).
SCRIPT
Running in -P script mode.
FIND_PACKAGE
Running in --find-package mode.
CTEST
Running in CTest script mode.
CPACK
Running in CPack.

  • cmake-properties(7) »


DEBUG_CONFIGURATIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DEBUG_CONFIGURATIONS

Specify which configurations are for debugging.

The value must be a semi-colon separated list of configuration names. Currently this property is used only by the target_link_libraries() command. Additional uses may be defined in the future.

This property must be set at the top level of the project and before the first target_link_libraries() command invocation. If any entry in the list does not match a valid configuration for the project the behavior is undefined.

  • cmake-properties(7) »


DISABLED_FEATURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DISABLED_FEATURES

List of features which are disabled during the CMake run.

List of features which are disabled during the CMake run. By default it contains the names of all packages which were not found. This is determined using the <NAME>_FOUND variables. Packages which are searched QUIET are not listed. A project can add its own features to this list. This property is used by the macros in FeatureSummary.cmake.

  • cmake-properties(7) »


ENABLED_FEATURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ENABLED_FEATURES

List of features which are enabled during the CMake run.

List of features which are enabled during the CMake run. By default it contains the names of all packages which were found. This is determined using the <NAME>_FOUND variables. Packages which are searched QUIET are not listed. A project can add its own features to this list. This property is used by the macros in FeatureSummary.cmake.

  • cmake-properties(7) »


ENABLED_LANGUAGES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ENABLED_LANGUAGES

Read-only property that contains the list of currently enabled languages

Set to list of currently enabled languages.

  • cmake-properties(7) »


FIND_LIBRARY_USE_LIB32_PATHS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FIND_LIBRARY_USE_LIB32_PATHS

Whether the find_library() command should automatically search lib32 directories.

FIND_LIBRARY_USE_LIB32_PATHS is a boolean specifying whether the find_library() command should automatically search the lib32 variant of directories called lib in the search path when building 32-bit binaries.

See also the CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX variable.

  • cmake-properties(7) »


FIND_LIBRARY_USE_LIB64_PATHS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FIND_LIBRARY_USE_LIB64_PATHS

Whether find_library() should automatically search lib64 directories.

FIND_LIBRARY_USE_LIB64_PATHS is a boolean specifying whether the find_library() command should automatically search the lib64 variant of directories called lib in the search path when building 64-bit binaries.

See also the CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX variable.

  • cmake-properties(7) »


FIND_LIBRARY_USE_LIBX32_PATHS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FIND_LIBRARY_USE_LIBX32_PATHS

Whether the find_library() command should automatically search libx32 directories.

FIND_LIBRARY_USE_LIBX32_PATHS is a boolean specifying whether the find_library() command should automatically search the libx32 variant of directories called lib in the search path when building x32-abi binaries.

See also the CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX variable.

  • cmake-properties(7) »


FIND_LIBRARY_USE_OPENBSD_VERSIONING — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FIND_LIBRARY_USE_OPENBSD_VERSIONING

Whether find_library() should find OpenBSD-style shared libraries.

This property is a boolean specifying whether the find_library() command should find shared libraries with OpenBSD-style versioned extension: “.so.<major>.<minor>”. The property is set to true on OpenBSD and false on other platforms.

  • cmake-properties(7) »


GENERATOR_IS_MULTI_CONFIG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

GENERATOR_IS_MULTI_CONFIG

Read-only property that is true on multi-configuration generators.

True when using a multi-configuration generator (such as Visual Studio Generators or Xcode). Multi-config generators use CMAKE_CONFIGURATION_TYPES as the set of configurations and ignore CMAKE_BUILD_TYPE.

  • cmake-properties(7) »


GLOBAL_DEPENDS_DEBUG_MODE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

GLOBAL_DEPENDS_DEBUG_MODE

Enable global target dependency graph debug mode.

CMake automatically analyzes the global inter-target dependency graph at the beginning of native build system generation. This property causes it to display details of its analysis to stderr.

  • cmake-properties(7) »


GLOBAL_DEPENDS_NO_CYCLES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

GLOBAL_DEPENDS_NO_CYCLES

Disallow global target dependency graph cycles.

CMake automatically analyzes the global inter-target dependency graph at the beginning of native build system generation. It reports an error if the dependency graph contains a cycle that does not consist of all STATIC library targets. This property tells CMake to disallow all cycles completely, even among static libraries.

  • cmake-properties(7) »


IN_TRY_COMPILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IN_TRY_COMPILE

Read-only property that is true during a try-compile configuration.

True when building a project inside a try_compile() or try_run() command.

  • cmake-properties(7) »


PACKAGES_FOUND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PACKAGES_FOUND

List of packages which were found during the CMake run.

List of packages which were found during the CMake run. Whether a package has been found is determined using the <NAME>_FOUND variables.

  • cmake-properties(7) »


PACKAGES_NOT_FOUND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PACKAGES_NOT_FOUND

List of packages which were not found during the CMake run.

List of packages which were not found during the CMake run. Whether a package has been found is determined using the <NAME>_FOUND variables.

  • cmake-properties(7) »


JOB_POOLS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

JOB_POOLS

Ninja only: List of available pools.

A pool is a named integer property and defines the maximum number of concurrent jobs which can be started by a rule assigned to the pool. The JOB_POOLS property is a semicolon-separated list of pairs using the syntax NAME=integer (without a space after the equality sign).

For instance:

set_property(GLOBAL PROPERTY JOB_POOLS two_jobs=2 ten_jobs=10)

Defined pools could be used globally by setting CMAKE_JOB_POOL_COMPILE and CMAKE_JOB_POOL_LINK or per target by setting the target properties JOB_POOL_COMPILE and JOB_POOL_LINK.

If not set, this property uses the value of the CMAKE_JOB_POOLS variable.

Build targets provided by CMake that are meant for individual interactive use, such as install, are placed in the console pool automatically.

  • cmake-properties(7) »


PREDEFINED_TARGETS_FOLDER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PREDEFINED_TARGETS_FOLDER

Name of FOLDER for targets that are added automatically by CMake.

If not set, CMake uses “CMakePredefinedTargets” as a default value for this property. Targets such as INSTALL, PACKAGE and RUN_TESTS will be organized into this FOLDER. See also the documentation for the FOLDER target property.

  • cmake-properties(7) »


ECLIPSE_EXTRA_NATURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ECLIPSE_EXTRA_NATURES

List of natures to add to the generated Eclipse project file.

Eclipse projects specify language plugins by using natures. This property should be set to the unique identifier for a nature (which looks like a Java package name).

Also see the ECLIPSE_EXTRA_CPROJECT_CONTENTS property.

  • cmake-properties(7) »


ECLIPSE_EXTRA_CPROJECT_CONTENTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ECLIPSE_EXTRA_CPROJECT_CONTENTS

Additional contents to be inserted into the generated Eclipse cproject file.

The cproject file defines the CDT specific information. Some third party IDE’s are based on Eclipse with the addition of other information specific to that IDE. Through this property, it is possible to add this additional contents to the generated project. It is expected to contain valid XML.

Also see the ECLIPSE_EXTRA_NATURES property.

  • cmake-properties(7) »


REPORT_UNDEFINED_PROPERTIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

REPORT_UNDEFINED_PROPERTIES

If set, report any undefined properties to this file.

If this property is set to a filename then when CMake runs it will report any properties or variables that were accessed but not defined into the filename specified in this property.

  • cmake-properties(7) »


RULE_LAUNCH_COMPILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_LAUNCH_COMPILE

Specify a launcher for compile rules.

Makefile Generators and the Ninja generator prefix compiler commands with the given launcher command line. This is intended to allow launchers to intercept build problems with high granularity. Other generators ignore this property because their underlying build systems provide no hook to wrap individual commands with a launcher.

  • cmake-properties(7) »


RULE_LAUNCH_CUSTOM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_LAUNCH_CUSTOM

Specify a launcher for custom rules.

Makefile Generators and the Ninja generator prefix custom commands with the given launcher command line. This is intended to allow launchers to intercept build problems with high granularity. Other generators ignore this property because their underlying build systems provide no hook to wrap individual commands with a launcher.

  • cmake-properties(7) »


RULE_LAUNCH_LINK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_LAUNCH_LINK

Specify a launcher for link rules.

Makefile Generators and the Ninja generator prefix link and archive commands with the given launcher command line. This is intended to allow launchers to intercept build problems with high granularity. Other generators ignore this property because their underlying build systems provide no hook to wrap individual commands with a launcher.

  • cmake-properties(7) »


RULE_MESSAGES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_MESSAGES

Specify whether to report a message for each make rule.

This property specifies whether Makefile generators should add a progress message describing what each build rule does. If the property is not set the default is ON. Set the property to OFF to disable granular messages and report only as each target completes. This is intended to allow scripted builds to avoid the build time cost of detailed reports. If a CMAKE_RULE_MESSAGES cache entry exists its value initializes the value of this property. Non-Makefile generators currently ignore this property.

  • cmake-properties(7) »


TARGET_ARCHIVES_MAY_BE_SHARED_LIBS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TARGET_ARCHIVES_MAY_BE_SHARED_LIBS

Set if shared libraries may be named like archives.

On AIX shared libraries may be named “lib<name>.a”. This property is set to true on such platforms.

  • cmake-properties(7) »


TARGET_MESSAGES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TARGET_MESSAGES

Specify whether to report the completion of each target.

This property specifies whether Makefile Generators should add a progress message describing that each target has been completed. If the property is not set the default is ON. Set the property to OFF to disable target completion messages.

This option is intended to reduce build output when little or no work needs to be done to bring the build tree up to date.

If a CMAKE_TARGET_MESSAGES cache entry exists its value initializes the value of this property.

Non-Makefile generators currently ignore this property.

See the counterpart property RULE_MESSAGES to disable everything except for target completion messages.

  • cmake-properties(7) »


TARGET_SUPPORTS_SHARED_LIBS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TARGET_SUPPORTS_SHARED_LIBS

Does the target platform support shared libraries.

TARGET_SUPPORTS_SHARED_LIBS is a boolean specifying whether the target platform supports shared libraries. Basically all current general general purpose OS do so, the exception are usually embedded systems with no or special OSs.

  • cmake-properties(7) »


USE_FOLDERS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

USE_FOLDERS

Use the FOLDER target property to organize targets into folders.

If not set, CMake treats this property as OFF by default. CMake generators that are capable of organizing into a hierarchy of folders use the values of the FOLDER target property to name those folders. See also the documentation for the FOLDER target property.

  • cmake-properties(7) »


XCODE_EMIT_EFFECTIVE_PLATFORM_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_EMIT_EFFECTIVE_PLATFORM_NAME

Control emission of EFFECTIVE_PLATFORM_NAME by the Xcode generator.

It is required for building the same target with multiple SDKs. A common use case is the parallel use of iphoneos and iphonesimulator SDKs.

Three different states possible that control when the Xcode generator emits the EFFECTIVE_PLATFORM_NAME variable:

  • If set to ON it will always be emitted
  • If set to OFF it will never be emitted
  • If unset (the default) it will only be emitted when the project was configured for an embedded Xcode SDK like iOS, tvOS, watchOS or any of the simulators.

Note

When this behavior is enable for generated Xcode projects, the EFFECTIVE_PLATFORM_NAME variable will leak into Generator expressions like TARGET_FILE and will render those mostly unusable.

  • cmake-properties(7) »


ADDITIONAL_MAKE_CLEAN_FILES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ADDITIONAL_MAKE_CLEAN_FILES

Additional files to clean during the make clean stage.

A list of files that will be cleaned as a part of the “make clean” stage.

  • cmake-properties(7) »


BINARY_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

BINARY_DIR

This read-only directory property reports absolute path to the binary directory corresponding to the source on which it is read.

  • cmake-properties(7) »


BUILDSYSTEM_TARGETS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

BUILDSYSTEM_TARGETS

This read-only directory property contains a semicolon-separated list of buildsystem targets added in the directory by calls to the add_library(), add_executable(), and add_custom_target() commands. The list does not include any Imported Targets or Alias Targets, but does include Interface Libraries. Each entry in the list is the logical name of a target, suitable to pass to the get_property() command TARGET option.

  • cmake-properties(7) »


CACHE_VARIABLES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CACHE_VARIABLES

List of cache variables available in the current directory.

This read-only property specifies the list of CMake cache variables currently defined. It is intended for debugging purposes.

  • cmake-properties(7) »


CLEAN_NO_CUSTOM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CLEAN_NO_CUSTOM

Set to true to tell Makefile Generators not to remove the outputs of custom commands for this directory during the make clean operation. This is ignored on other generators because it is not possible to implement.

  • cmake-properties(7) »


CMAKE_CONFIGURE_DEPENDS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CMAKE_CONFIGURE_DEPENDS

Tell CMake about additional input files to the configuration process. If any named file is modified the build system will re-run CMake to re-configure the file and generate the build system again.

Specify files as a semicolon-separated list of paths. Relative paths are interpreted as relative to the current source directory.

  • cmake-properties(7) »


COMPILE_DEFINITIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_DEFINITIONS

Preprocessor definitions for compiling a directory’s sources.

This property specifies the list of options given so far to the add_compile_definitions() (or add_definitions()) command.

The COMPILE_DEFINITIONS property may be set to a semicolon-separated list of preprocessor definitions using the syntax VAR or VAR=value. Function-style definitions are not supported. CMake will automatically escape the value correctly for the native build system (note that CMake language syntax may require escapes to specify some values).

This property will be initialized in each directory by its value in the directory’s parent.

CMake will automatically drop some definitions that are not supported by the native build tool.

Disclaimer: Most native build tools have poor support for escaping certain values. CMake has work-arounds for many cases but some values may just not be possible to pass correctly. If a value does not seem to be escaped correctly, do not attempt to work-around the problem by adding escape sequences to the value. Your work-around may break in a future version of CMake that has improved escape support. Instead consider defining the macro in a (configured) header file. Then report the limitation. Known limitations include:

#          - broken almost everywhere
;          - broken in VS IDE 7.0 and Borland Makefiles
,          - broken in VS IDE
%          - broken in some cases in NMake
& |        - broken in some cases on MinGW
^ < > \"   - broken in most Make tools on Windows

CMake does not reject these values outright because they do work in some cases. Use with caution.

Contents of COMPILE_DEFINITIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

The corresponding COMPILE_DEFINITIONS_<CONFIG> property may be set to specify per-configuration definitions. Generator expressions should be preferred instead of setting the alternative property.

  • cmake-properties(7) »


COMPILE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_OPTIONS

List of options to pass to the compiler.

This property holds a semicolon-separated list of options given so far to the add_compile_options() command.

This property is used to initialize the COMPILE_OPTIONS target property when a target is created, which is used by the generators to set the options for the compiler.

Contents of COMPILE_OPTIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


DEFINITIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DEFINITIONS

For CMake 2.4 compatibility only. Use COMPILE_DEFINITIONS instead.

This read-only property specifies the list of flags given so far to the add_definitions() command. It is intended for debugging purposes. Use the COMPILE_DEFINITIONS directory property instead.

This built-in read-only property does not exist if policy CMP0059 is set to NEW.

  • cmake-properties(7) »


EXCLUDE_FROM_ALL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

EXCLUDE_FROM_ALL

Exclude the directory from the all target of its parent.

A property on a directory that indicates if its targets are excluded from the default build target. If it is not, then with a Makefile for example typing make will cause the targets to be built. The same concept applies to the default build of other generators.

Targets inherit the EXCLUDE_FROM_ALL property from the directory that they are created in. When a directory is excluded, all of its targets will have EXCLUDE_FROM_ALL set to TRUE. After creating such a target you can change its EXCLUDE_FROM_ALL property to FALSE. This will cause the target to be included in the default build target.

  • cmake-properties(7) »


IMPLICIT_DEPENDS_INCLUDE_TRANSFORM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPLICIT_DEPENDS_INCLUDE_TRANSFORM

Specify #include line transforms for dependencies in a directory.

This property specifies rules to transform macro-like #include lines during implicit dependency scanning of C and C++ source files. The list of rules must be semicolon-separated with each entry of the form “A_MACRO(%)=value-with-%” (the % must be literal). During dependency scanning occurrences of A_MACRO(…) on #include lines will be replaced by the value given with the macro argument substituted for ‘%’. For example, the entry

MYDIR(%)=<mydir/%>

will convert lines of the form

#include MYDIR(myheader.h)

to

#include <mydir/myheader.h>

allowing the dependency to be followed.

This property applies to sources in all targets within a directory. The property value is initialized in each directory by its value in the directory’s parent.

  • cmake-properties(7) »


INCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INCLUDE_DIRECTORIES

List of preprocessor include file search directories.

This property specifies the list of directories given so far to the include_directories() command.

This property is used to populate the INCLUDE_DIRECTORIES target property, which is used by the generators to set the include directories for the compiler.

In addition to accepting values from that command, values may be set directly on any directory using the set_property() command, and can be set on the current directory using the set_directory_properties() command. A directory gets its initial value from its parent directory if it has one. The initial value of the INCLUDE_DIRECTORIES target property comes from the value of this property. Both directory and target property values are adjusted by calls to the include_directories() command. Calls to set_property() or set_directory_properties(), however, will update the directory property value without updating target property values. Therefore direct property updates must be made before calls to add_executable() or add_library() for targets they are meant to affect.

The target property values are used by the generators to set the include paths for the compiler.

Contents of INCLUDE_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


INCLUDE_REGULAR_EXPRESSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INCLUDE_REGULAR_EXPRESSION

Include file scanning regular expression.

This property specifies the regular expression used during dependency scanning to match include files that should be followed. See the include_regular_expression() command for a high-level interface to set this property.

  • cmake-properties(7) »


INTERPROCEDURAL_OPTIMIZATION_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERPROCEDURAL_OPTIMIZATION_<CONFIG>

Per-configuration interprocedural optimization for a directory.

This is a per-configuration version of INTERPROCEDURAL_OPTIMIZATION. If set, this property overrides the generic property for the named configuration.

  • cmake-properties(7) »


INTERPROCEDURAL_OPTIMIZATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERPROCEDURAL_OPTIMIZATION

Enable interprocedural optimization for targets in a directory.

If set to true, enables interprocedural optimizations if they are known to be supported by the compiler.

  • cmake-properties(7) »


LABELS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LABELS

Specify a list of text labels associated with a directory and all of its subdirectories. This is equivalent to setting the LABELS target property and the LABELS test property on all targets and tests in the current directory and subdirectories. Note: Launchers must enabled to propagate labels to targets.

The CMAKE_DIRECTORY_LABELS variable can be used to initialize this property.

The list is reported in dashboard submissions.

  • cmake-properties(7) »


LINK_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_DIRECTORIES

List of linker search directories.

This property holds a semicolon-separated list of directories and is typically populated using the link_directories() command. It gets its initial value from its parent directory, if it has one.

The directory property is used to initialize the LINK_DIRECTORIES target property when a target is created. That target property is used by the generators to set the library search directories for the linker.

Contents of LINK_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


LINK_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_OPTIONS

List of options to use for the link step of shared library, module and executable targets.

This property holds a semicolon-separated list of options given so far to the add_link_options() command.

This property is used to initialize the LINK_OPTIONS target property when a target is created, which is used by the generators to set the options for the compiler.

Contents of LINK_OPTIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


LISTFILE_STACK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LISTFILE_STACK

The current stack of listfiles being processed.

This property is mainly useful when trying to debug errors in your CMake scripts. It returns a list of what list files are currently being processed, in order. So if one listfile does an include() command then that is effectively pushing the included listfile onto the stack.

  • cmake-properties(7) »


MACROS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MACROS

List of macro commands available in the current directory.

This read-only property specifies the list of CMake macros currently defined. It is intended for debugging purposes. See the macro command.

  • cmake-properties(7) »


PARENT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PARENT_DIRECTORY

Source directory that added current subdirectory.

This read-only property specifies the source directory that added the current source directory as a subdirectory of the build. In the top-level directory the value is the empty-string.

  • cmake-properties(7) »


RULE_LAUNCH_COMPILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_LAUNCH_COMPILE

Specify a launcher for compile rules.

See the global property of the same name for details. This overrides the global property for a directory.

  • cmake-properties(7) »


RULE_LAUNCH_CUSTOM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_LAUNCH_CUSTOM

Specify a launcher for custom rules.

See the global property of the same name for details. This overrides the global property for a directory.

  • cmake-properties(7) »


RULE_LAUNCH_LINK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_LAUNCH_LINK

Specify a launcher for link rules.

See the global property of the same name for details. This overrides the global property for a directory.

  • cmake-properties(7) »


SOURCE_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SOURCE_DIR

This read-only directory property reports absolute path to the source directory on which it is read.

  • cmake-properties(7) »


SUBDIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SUBDIRECTORIES

This read-only directory property contains a semicolon-separated list of subdirectories processed so far by the add_subdirectory() or subdirs() commands. Each entry is the absolute path to the source directory (containing the CMakeLists.txt file). This is suitable to pass to the get_property() command DIRECTORY option.

Note

The subdirs() command does not process its arguments until after the calling directory is fully processed. Therefore looking up this property in the current directory will not see them.

  • cmake-properties(7) »


TESTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TESTS

List of tests.

This read-only property holds a semicolon-separated list of tests defined so far, in the current directory, by the add_test() command.

  • cmake-properties(7) »


TEST_INCLUDE_FILES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TEST_INCLUDE_FILES

A list of cmake files that will be included when ctest is run.

If you specify TEST_INCLUDE_FILES, those files will be included and processed when ctest is run on the directory.

  • cmake-properties(7) »


VARIABLES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VARIABLES

List of variables defined in the current directory.

This read-only property specifies the list of CMake variables currently defined. It is intended for debugging purposes.

  • cmake-properties(7) »


VS_GLOBAL_SECTION_POST_<section> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_GLOBAL_SECTION_POST_<section>

Specify a postSolution global section in Visual Studio.

Setting a property like this generates an entry of the following form in the solution file:

GlobalSection(<section>) = postSolution
  <contents based on property value>
EndGlobalSection

The property must be set to a semicolon-separated list of key=value pairs. Each such pair will be transformed into an entry in the solution global section. Whitespace around key and value is ignored. List elements which do not contain an equal sign are skipped.

This property only works for Visual Studio 9 and above; it is ignored on other generators. The property only applies when set on a directory whose CMakeLists.txt contains a project() command.

Note that CMake generates postSolution sections ExtensibilityGlobals and ExtensibilityAddIns by default. If you set the corresponding property, it will override the default section. For example, setting VS_GLOBAL_SECTION_POST_ExtensibilityGlobals will override the default contents of the ExtensibilityGlobals section, while keeping ExtensibilityAddIns on its default. However, CMake will always add a SolutionGuid to the ExtensibilityGlobals section if it is not specified explicitly.

  • cmake-properties(7) »


VS_GLOBAL_SECTION_PRE_<section> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_GLOBAL_SECTION_PRE_<section>

Specify a preSolution global section in Visual Studio.

Setting a property like this generates an entry of the following form in the solution file:

GlobalSection(<section>) = preSolution
  <contents based on property value>
EndGlobalSection

The property must be set to a semicolon-separated list of key=value pairs. Each such pair will be transformed into an entry in the solution global section. Whitespace around key and value is ignored. List elements which do not contain an equal sign are skipped.

This property only works for Visual Studio 9 and above; it is ignored on other generators. The property only applies when set on a directory whose CMakeLists.txt contains a project() command.

  • cmake-properties(7) »


VS_STARTUP_PROJECT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_STARTUP_PROJECT

Specify the default startup project in a Visual Studio solution.

The Visual Studio Generators create a .sln file for each directory whose CMakeLists.txt file calls the project() command. Set this property in the same directory as a project() command call (e.g. in the top-level CMakeLists.txt file) to specify the default startup project for the correpsonding solution file.

The property must be set to the name of an existing target. This will cause that project to be listed first in the generated solution file causing Visual Studio to make it the startup project if the solution has never been opened before.

If this property is not specified, then the ALL_BUILD project will be the default.

  • cmake-properties(7) »


ALIASED_TARGET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ALIASED_TARGET

Name of target aliased by this target.

If this is an Alias Target, this property contains the name of the target aliased.

  • cmake-properties(7) »


ANDROID_ANT_ADDITIONAL_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_ANT_ADDITIONAL_OPTIONS

Set the additional options for Android Ant build system. This is a string value containing all command line options for the Ant build. This property is initialized by the value of the CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_API — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_API

When Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition, this property sets the Android target API version (e.g. 15). The version number must be a positive decimal integer. This property is initialized by the value of the CMAKE_ANDROID_API variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_API_MIN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_API_MIN

Set the Android MIN API version (e.g. 9). The version number must be a positive decimal integer. This property is initialized by the value of the CMAKE_ANDROID_API_MIN variable if it is set when a target is created. Native code builds using this API version.

  • cmake-properties(7) »


ANDROID_ARCH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_ARCH

When Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition, this property sets the Android target architecture.

This is a string property that could be set to the one of the following values:

  • armv7-a: “ARMv7-A (armv7-a)”
  • armv7-a-hard: “ARMv7-A, hard-float ABI (armv7-a)”
  • arm64-v8a: “ARMv8-A, 64bit (arm64-v8a)”
  • x86: “x86 (x86)”
  • x86_64: “x86_64 (x86_64)”

This property is initialized by the value of the CMAKE_ANDROID_ARCH variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_ASSETS_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_ASSETS_DIRECTORIES

Set the Android assets directories to copy into the main assets folder before build. This a string property that contains the directory paths separated by semicolon. This property is initialized by the value of the CMAKE_ANDROID_ASSETS_DIRECTORIES variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_GUI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_GUI

When Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition, this property specifies whether to build an executable as an application package on Android.

When this property is set to true the executable when built for Android will be created as an application package. This property is initialized by the value of the CMAKE_ANDROID_GUI variable if it is set when a target is created.

Add the AndroidManifest.xml source file explicitly to the target add_executable() command invocation to specify the root directory of the application package source.

  • cmake-properties(7) »


ANDROID_JAR_DEPENDENCIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_JAR_DEPENDENCIES

Set the Android property that specifies JAR dependencies. This is a string value property. This property is initialized by the value of the CMAKE_ANDROID_JAR_DEPENDENCIES variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_JAR_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_JAR_DIRECTORIES

Set the Android property that specifies directories to search for the JAR libraries.

This a string property that contains the directory paths separated by semicolons. This property is initialized by the value of the CMAKE_ANDROID_JAR_DIRECTORIES variable if it is set when a target is created.

Contents of ANDROID_JAR_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions.

  • cmake-properties(7) »


ANDROID_JAVA_SOURCE_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_JAVA_SOURCE_DIR

Set the Android property that defines the Java source code root directories. This a string property that contains the directory paths separated by semicolon. This property is initialized by the value of the CMAKE_ANDROID_JAVA_SOURCE_DIR variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_NATIVE_LIB_DEPENDENCIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_NATIVE_LIB_DEPENDENCIES

Set the Android property that specifies the .so dependencies. This is a string property.

This property is initialized by the value of the CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES variable if it is set when a target is created.

Contents of ANDROID_NATIVE_LIB_DEPENDENCIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions.

  • cmake-properties(7) »


ANDROID_NATIVE_LIB_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_NATIVE_LIB_DIRECTORIES

Set the Android property that specifies directories to search for the .so libraries.

This a string property that contains the directory paths separated by semicolons.

This property is initialized by the value of the CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES variable if it is set when a target is created.

Contents of ANDROID_NATIVE_LIB_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions.

  • cmake-properties(7) »


ANDROID_PROCESS_MAX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_PROCESS_MAX

Set the Android property that defines the maximum number of a parallel Android NDK compiler processes (e.g. 4). This property is initialized by the value of the CMAKE_ANDROID_PROCESS_MAX variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_PROGUARD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_PROGUARD

When this property is set to true that enables the ProGuard tool to shrink, optimize, and obfuscate the code by removing unused code and renaming classes, fields, and methods with semantically obscure names. This property is initialized by the value of the CMAKE_ANDROID_PROGUARD variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_PROGUARD_CONFIG_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_PROGUARD_CONFIG_PATH

Set the Android property that specifies the location of the ProGuard config file. Leave empty to use the default one. This a string property that contains the path to ProGuard config file. This property is initialized by the value of the CMAKE_ANDROID_PROGUARD_CONFIG_PATH variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_SECURE_PROPS_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_SECURE_PROPS_PATH

Set the Android property that states the location of the secure properties file. This is a string property that contains the file path. This property is initialized by the value of the CMAKE_ANDROID_SECURE_PROPS_PATH variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_SKIP_ANT_STEP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_SKIP_ANT_STEP

Set the Android property that defines whether or not to skip the Ant build step. This is a boolean property initialized by the value of the CMAKE_ANDROID_SKIP_ANT_STEP variable if it is set when a target is created.

  • cmake-properties(7) »


ANDROID_STL_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ANDROID_STL_TYPE

When Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition, this property specifies the type of STL support for the project. This is a string property that could set to the one of the following values:

none
No C++ Support
system
Minimal C++ without STL
gabi++_static
GAbi++ Static
gabi++_shared
GAbi++ Shared
gnustl_static
GNU libstdc++ Static
gnustl_shared
GNU libstdc++ Shared
stlport_static
STLport Static
stlport_shared
STLport Shared

This property is initialized by the value of the CMAKE_ANDROID_STL_TYPE variable if it is set when a target is created.

  • cmake-properties(7) »


ARCHIVE_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>

Per-configuration output directory for ARCHIVE target files.

This is a per-configuration version of the ARCHIVE_OUTPUT_DIRECTORY target property, but multi-configuration generators (VS, Xcode) do NOT append a per-configuration subdirectory to the specified directory. This property is initialized by the value of the CMAKE_ARCHIVE_OUTPUT_DIRECTORY_<CONFIG> variable if it is set when a target is created.

Contents of ARCHIVE_OUTPUT_DIRECTORY_<CONFIG> may use generator expressions.

  • cmake-properties(7) »


ARCHIVE_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ARCHIVE_OUTPUT_DIRECTORY

Output directory in which to build ARCHIVE target files.

This property specifies the directory into which archive target files should be built. The property value may use generator expressions. Multi-configuration generators (VS, Xcode) append a per-configuration subdirectory to the specified directory unless a generator expression is used.

This property is initialized by the value of the variable CMAKE_ARCHIVE_OUTPUT_DIRECTORY if it is set when a target is created.

See also the ARCHIVE_OUTPUT_DIRECTORY_<CONFIG> target property.

  • cmake-properties(7) »


ARCHIVE_OUTPUT_NAME_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ARCHIVE_OUTPUT_NAME_<CONFIG>

Per-configuration output name for ARCHIVE target files.

This is the configuration-specific version of the ARCHIVE_OUTPUT_NAME target property.

  • cmake-properties(7) »


ARCHIVE_OUTPUT_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ARCHIVE_OUTPUT_NAME

Output name for ARCHIVE target files.

This property specifies the base name for archive target files. It overrides OUTPUT_NAME and OUTPUT_NAME_<CONFIG> properties.

See also the ARCHIVE_OUTPUT_NAME_<CONFIG> target property.

  • cmake-properties(7) »


AUTOGEN_BUILD_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOGEN_BUILD_DIR

Directory where AUTOMOC, AUTOUIC and AUTORCC generate files for the target.

The directory is created on demand and automatically added to the ADDITIONAL_MAKE_CLEAN_FILES.

When unset or empty the directory <dir>/<target-name>_autogen is used where <dir> is CMAKE_CURRENT_BINARY_DIR and <target-name> is NAME.

By default AUTOGEN_BUILD_DIR is unset.

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

  • cmake-properties(7) »


AUTOGEN_ORIGIN_DEPENDS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOGEN_ORIGIN_DEPENDS

Switch for forwarding origin target dependencies to the corresponding _autogen target.

Targets which have their AUTOMOC or AUTOUIC property ON have a corresponding _autogen target which generates moc and uic files. As this _autogen target is created at generate-time, it is not possible to define dependencies of it using e.g. add_dependencies(). Instead the AUTOGEN_ORIGIN_DEPENDS target property decides whether the origin target dependencies should be forwarded to the _autogen target or not.

By default AUTOGEN_ORIGIN_DEPENDS is initialized from CMAKE_AUTOGEN_ORIGIN_DEPENDS which is ON by default.

In total the dependencies of the _autogen target are composed from

  • forwarded origin target dependencies (enabled by default via AUTOGEN_ORIGIN_DEPENDS)
  • additional user defined dependencies from AUTOGEN_TARGET_DEPENDS

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

Note

Disabling AUTOGEN_ORIGIN_DEPENDS is useful to avoid building of origin target dependencies when building the _autogen target only. This is especially interesting when a global autogen target is enabled.

When the _autogen target doesn’t require all the origin target’s dependencies, and AUTOGEN_ORIGIN_DEPENDS is disabled, it might be necessary to extend AUTOGEN_TARGET_DEPENDS to add missing dependencies.

  • cmake-properties(7) »


AUTOGEN_PARALLEL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOGEN_PARALLEL

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

The custom <origin>_autogen target starts a number of threads of which each one parses a source file and on demand starts a moc or uic process. AUTOGEN_PARALLEL controls how many parallel threads (and therefore moc or uic processes) are started.

  • An empty (or unset) value or the string AUTO sets the number of threads/processes to the number of physical CPUs on the host system.
  • A positive non zero integer value sets the exact thread/process count.
  • Otherwise a single thread/process is started.

By default AUTOGEN_PARALLEL is initialized from CMAKE_AUTOGEN_PARALLEL.

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

  • cmake-properties(7) »


AUTOGEN_TARGET_DEPENDS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOGEN_TARGET_DEPENDS

Additional target dependencies of the corresponding _autogen target.

Targets which have their AUTOMOC or AUTOUIC property ON have a corresponding _autogen target which generates moc and uic files. As this _autogen target is created at generate-time, it is not possible to define dependencies of it using e.g. add_dependencies(). Instead the AUTOGEN_TARGET_DEPENDS target property can be set to a ;-list of additional dependencies for the _autogen target. Dependencies can be target names or file names.

In total the dependencies of the _autogen target are composed from

  • forwarded origin target dependencies (enabled by default via AUTOGEN_ORIGIN_DEPENDS)
  • additional user defined dependencies from AUTOGEN_TARGET_DEPENDS

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

Use cases

If AUTOMOC or AUTOUIC depends on a file that is either

  • a GENERATED non C++ file (e.g. a GENERATED .json or .ui file) or
  • a GENERATED C++ file that isn’t recognized by AUTOMOC and AUTOUIC because it’s skipped by SKIP_AUTOMOC, SKIP_AUTOUIC, SKIP_AUTOGEN or CMP0071 or
  • a file that isn’t in the origin target’s sources

it must added to AUTOGEN_TARGET_DEPENDS.

  • cmake-properties(7) »


AUTOMOC_COMPILER_PREDEFINES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOMOC_COMPILER_PREDEFINES

Boolean value used by AUTOMOC to determine if the compiler pre definitions file moc_predefs.h should be generated.

CMake generates a moc_predefs.h file with compiler pre definitions from the output of the command defined in CMAKE_CXX_COMPILER_PREDEFINES_COMMAND when

  • AUTOMOC is enabled,
  • AUTOMOC_COMPILER_PREDEFINES is enabled,
  • CMAKE_CXX_COMPILER_PREDEFINES_COMMAND isn’t empty and
  • the Qt version is greater or equal 5.8.

The moc_predefs.h file, which is generated in AUTOGEN_BUILD_DIR, is passed to moc as the argument to the --include option.

By default AUTOMOC_COMPILER_PREDEFINES is initialized from CMAKE_AUTOMOC_COMPILER_PREDEFINES, which is ON by default.

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

  • cmake-properties(7) »


AUTOMOC_DEPEND_FILTERS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOMOC_DEPEND_FILTERS

Filter definitions used by AUTOMOC to extract file names from a source file that are registered as additional dependencies for the moc file of the source file.

Filters are defined as KEYWORD;REGULAR_EXPRESSION pairs. First the file content is searched for KEYWORD. If it is found at least once, then file names are extracted by successively searching for REGULAR_EXPRESSION and taking the first match group.

The file name found in the first match group is searched for

  • first in the vicinity of the source file
  • and afterwards in the target’s INCLUDE_DIRECTORIES.

If any of the extracted files changes, then the moc file for the source file gets rebuilt even when the source file itself doesn’t change.

If any of the extracted files is GENERATED or if it is not in the target’s sources, then it might be necessary to add it to the _autogen target dependencies. See AUTOGEN_TARGET_DEPENDS for reference.

By default AUTOMOC_DEPEND_FILTERS is initialized from CMAKE_AUTOMOC_DEPEND_FILTERS, which is empty by default.

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

Example 1

A header file my_class.hpp uses a custom macro JSON_FILE_MACRO which is defined in an other header macros.hpp. We want the moc file of my_class.hpp to depend on the file name argument of JSON_FILE_MACRO:

// my_class.hpp
class My_Class : public QObject
{
  Q_OBJECT
  JSON_FILE_MACRO ( "info.json" )
...
};

In CMakeLists.txt we add a filter to CMAKE_AUTOMOC_DEPEND_FILTERS like this:

list( APPEND CMAKE_AUTOMOC_DEPEND_FILTERS
  "JSON_FILE_MACRO"
  "[\n][ \t]*JSON_FILE_MACRO[ \t]*\\([ \t]*\"([^\"]+)\""
)

We assume info.json is a plain (not GENERATED) file that is listed in the target’s source. Therefore we do not need to add it to AUTOGEN_TARGET_DEPENDS.

Example 2

In the target my_target a header file complex_class.hpp uses a custom macro JSON_BASED_CLASS which is defined in an other header macros.hpp:

// macros.hpp
...
#define JSON_BASED_CLASS(name, json) \
class name : public QObject \
{ \
  Q_OBJECT \
  Q_PLUGIN_METADATA(IID "demo" FILE json) \
  name() {} \
};
...

// complex_class.hpp
#pragma once
JSON_BASED_CLASS(Complex_Class, "meta.json")
// end of file

Since complex_class.hpp doesn’t contain a Q_OBJECT macro it would be ignored by AUTOMOC. We change this by adding JSON_BASED_CLASS to CMAKE_AUTOMOC_MACRO_NAMES:

list(APPEND CMAKE_AUTOMOC_MACRO_NAMES "JSON_BASED_CLASS")

We want the moc file of complex_class.hpp to depend on meta.json. So we add a filter to CMAKE_AUTOMOC_DEPEND_FILTERS:

list(APPEND CMAKE_AUTOMOC_DEPEND_FILTERS
  "JSON_BASED_CLASS"
  "[\n^][ \t]*JSON_BASED_CLASS[ \t]*\\([^,]*,[ \t]*\"([^\"]+)\""
)

Additionally we assume meta.json is GENERATED which is why we have to add it to AUTOGEN_TARGET_DEPENDS:

set_property(TARGET my_target APPEND PROPERTY AUTOGEN_TARGET_DEPENDS "meta.json")

  • cmake-properties(7) »


AUTOMOC_EXECUTABLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOMOC_EXECUTABLE

AUTOMOC_EXECUTABLE is file path pointing to the moc executable to use for AUTOMOC enabled files. Setting this property will make CMake skip the automatic detection of the moc binary as well as the sanity-tests normally run to ensure that the binary is available and working as expected.

Usually this property does not need to be set. Only consider this property if auto-detection of moc can not work – e.g. because you are building the moc binary as part of your project.

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

  • cmake-properties(7) »


AUTOMOC_MACRO_NAMES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOMOC_MACRO_NAMES

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

This property is only used if the AUTOMOC property is ON for this target.

When running AUTOMOC, CMake searches for the strings listed in AUTOMOC_MACRO_NAMES in C++ source and header files. If any of the strings is found

  • as the first non space string on a new line or
  • as the first non space string after a { on a new line,

then the file will be processed by moc.

By default AUTOMOC_MACRO_NAMES is initialized from CMAKE_AUTOMOC_MACRO_NAMES.

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

Example

In this case the Q_OBJECT macro is hidden inside another macro called CUSTOM_MACRO. To let CMake know that source files that contain CUSTOM_MACRO need to be moc processed, we call:

set_property(TARGET tgt APPEND PROPERTY AUTOMOC_MACRO_NAMES "CUSTOM_MACRO")

  • cmake-properties(7) »


AUTOMOC_MOC_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOMOC_MOC_OPTIONS

Additional options for moc when using AUTOMOC

This property is only used if the AUTOMOC property is ON for this target. In this case, it holds additional command line options which will be used when moc is executed during the build, i.e. it is equivalent to the optional OPTIONS argument of the qt4_wrap_cpp() macro.

By default it is empty.

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

  • cmake-properties(7) »


AUTOMOC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOMOC

Should the target be processed with automoc (for Qt projects).

AUTOMOC is a boolean specifying whether CMake will handle the Qt moc preprocessor automatically, i.e. without having to use the QT4_WRAP_CPP() or QT5_WRAP_CPP() macro. Currently Qt4 and Qt5 are supported.

When this property is set ON, CMake will scan the header and source files at build time and invoke moc accordingly.

  • If an #include statement like #include "moc_<basename>.cpp" is found, a macro from AUTOMOC_MACRO_NAMES is expected to appear in the <basename>.h(xx) header file. moc is run on the header file to generate moc_<basename>.cpp in the <AUTOGEN_BUILD_DIR>/include directory which is automatically added to the target’s INCLUDE_DIRECTORIES. This allows the compiler to find the included moc_<basename>.cpp file regardless of the location the original source.
    • For multi configuration generators, the include directory is <AUTOGEN_BUILD_DIR>/include_<CONFIG>.
    • See AUTOGEN_BUILD_DIR.
  • If an #include statement like #include "<basename>.moc" is found, a macro from AUTOMOC_MACRO_NAMES is expected to appear in the source file and moc is run on the source file itself.
  • Header files that are not included by an #include "moc_<basename>.cpp" statement are nonetheless scanned for a macro out of AUTOMOC_MACRO_NAMES. The resulting moc_<basename>.cpp files are generated in custom directories and automatically included in a generated <AUTOGEN_BUILD_DIR>/mocs_compilation.cpp file, which is compiled as part of the target.
    • The custom directories with checksum based names help to avoid name collisions for moc files with the same <basename>.
    • See AUTOGEN_BUILD_DIR.
  • Additionally, header files with the same base name as a source file, (like <basename>.h) or _p appended to the base name (like <basename>_p.h), are scanned for a macro out of AUTOMOC_MACRO_NAMES, and if found, moc is also executed on those files.
  • AUTOMOC always checks multiple header alternative extensions, such as hpp, hxx, etc. when searching for headers.
  • AUTOMOC looks for the Q_PLUGIN_METADATA macro and reruns the moc when the file addressed by the FILE argument of the macro changes.

This property is initialized by the value of the CMAKE_AUTOMOC variable if it is set when a target is created.

The moc executable will be detected automatically, but can be forced to a certain binary using the AUTOMOC_EXECUTABLE property.

Additional command line options for moc can be set via the AUTOMOC_MOC_OPTIONS property.

By enabling the CMAKE_AUTOMOC_RELAXED_MODE variable the rules for searching the files which will be processed by moc can be relaxed. See the documentation for this variable for more details.

The global property AUTOGEN_TARGETS_FOLDER can be used to group the automoc targets together in an IDE, e.g. in MSVS.

The global property AUTOGEN_SOURCE_GROUP can be used to group files generated by AUTOMOC together in an IDE, e.g. in MSVS.

Additional macro names to search for can be added to AUTOMOC_MACRO_NAMES.

Additional moc dependency file names can be extracted from source code by using AUTOMOC_DEPEND_FILTERS.

Compiler pre definitions for moc are written to a moc_predefs.h file which is controlled by AUTOMOC_COMPILER_PREDEFINES.

Source C++ files can be excluded from AUTOMOC processing by enabling SKIP_AUTOMOC or the broader SKIP_AUTOGEN.

The number of parallel moc processes to start can be modified by setting AUTOGEN_PARALLEL.

A global autogen target that depends on all AUTOMOC generated <ORIGIN>_autogen targets in the project can be generated by enabling CMAKE_GLOBAL_AUTOGEN_TARGET.

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

  • cmake-properties(7) »


AUTOUIC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOUIC

Should the target be processed with autouic (for Qt projects).

AUTOUIC is a boolean specifying whether CMake will handle the Qt uic code generator automatically, i.e. without having to use the QT4_WRAP_UI() or QT5_WRAP_UI() macro. Currently Qt4 and Qt5 are supported.

When this property is ON, CMake will scan the source files at build time and invoke uic accordingly. If an #include statement like #include "ui_foo.h" is found in source.cpp, a foo.ui file is searched for first in the vicinity of source.cpp and afterwards in the optional AUTOUIC_SEARCH_PATHS of the target. uic is run on the foo.ui file to generate ui_foo.h in the directory <AUTOGEN_BUILD_DIR>/include, which is automatically added to the target’s INCLUDE_DIRECTORIES.

  • For multi configuration generators, the include directory is <AUTOGEN_BUILD_DIR>/include_<CONFIG>.
  • See AUTOGEN_BUILD_DIR.

This property is initialized by the value of the CMAKE_AUTOUIC variable if it is set when a target is created.

Additional command line options for uic can be set via the AUTOUIC_OPTIONS source file property on the foo.ui file. The global property AUTOGEN_TARGETS_FOLDER can be used to group the autouic targets together in an IDE, e.g. in MSVS.

The uic executable will be detected automatically, but can be forced to a certain binary using the AUTOUIC_EXECUTABLE property.

Source files can be excluded from AUTOUIC processing by enabling SKIP_AUTOUIC or the broader SKIP_AUTOGEN.

The number of parallel uic processes to start can be modified by setting AUTOGEN_PARALLEL.

A global autogen target that depends on all AUTOUIC generated <ORIGIN>_autogen targets in the project can be generated by enabling CMAKE_GLOBAL_AUTOGEN_TARGET.

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

  • cmake-properties(7) »


AUTOUIC_EXECUTABLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOUIC_EXECUTABLE

AUTOUIC_EXECUTABLE is file path pointing to the uic executable to use for AUTOUIC enabled files. Setting this property will make CMake skip the automatic detection of the uic binary as well as the sanity-tests normally run to ensure that the binary is available and working as expected.

Usually this property does not need to be set. Only consider this property if auto-detection of uic can not work – e.g. because you are building the uic binary as part of your project.

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

  • cmake-properties(7) »


AUTOUIC_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOUIC_OPTIONS

Additional options for uic when using AUTOUIC

This property holds additional command line options which will be used when uic is executed during the build via AUTOUIC, i.e. it is equivalent to the optional OPTIONS argument of the qt4_wrap_ui() macro.

By default it is empty.

This property is initialized by the value of the CMAKE_AUTOUIC_OPTIONS variable if it is set when a target is created.

The options set on the target may be overridden by AUTOUIC_OPTIONS set on the .ui source file.

This property may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions.

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

EXAMPLE

# ...
set_property(TARGET tgt PROPERTY AUTOUIC_OPTIONS "--no-protection")
# ...

  • cmake-properties(7) »


AUTOUIC_SEARCH_PATHS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOUIC_SEARCH_PATHS

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

This property is initialized by the value of the CMAKE_AUTOUIC_SEARCH_PATHS variable if it is set when a target is created. Otherwise it is empty.

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

  • cmake-properties(7) »


AUTORCC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTORCC

Should the target be processed with autorcc (for Qt projects).

AUTORCC is a boolean specifying whether CMake will handle the Qt rcc code generator automatically, i.e. without having to use the QT4_ADD_RESOURCES() or QT5_ADD_RESOURCES() macro. Currently Qt4 and Qt5 are supported.

When this property is ON, CMake will handle .qrc files added as target sources at build time and invoke rcc accordingly. This property is initialized by the value of the CMAKE_AUTORCC variable if it is set when a target is created.

By default AUTORCC is processed inside a custom command. If the .qrc file is GENERATED though, a custom target is used instead.

Additional command line options for rcc can be set via the AUTORCC_OPTIONS source file property on the .qrc file.

The rcc executable will be detected automatically, but can be forced to a certain binary using the AUTORCC_EXECUTABLE property.

The global property AUTOGEN_TARGETS_FOLDER can be used to group the autorcc targets together in an IDE, e.g. in MSVS.

The global property AUTOGEN_SOURCE_GROUP can be used to group files generated by AUTORCC together in an IDE, e.g. in MSVS.

When there are multiple .qrc files with the same name, CMake will generate unspecified unique names for rcc. Therefore if Q_INIT_RESOURCE() or Q_CLEANUP_RESOURCE() need to be used the .qrc file name must be unique.

Source files can be excluded from AUTORCC processing by enabling SKIP_AUTORCC or the broader SKIP_AUTOGEN.

A global autorcc target that depends on all AUTORCC targets in the project can be generated by enabling CMAKE_GLOBAL_AUTORCC_TARGET.

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

  • cmake-properties(7) »


AUTORCC_EXECUTABLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTORCC_EXECUTABLE

AUTORCC_EXECUTABLE is file path pointing to the rcc executable to use for AUTORCC enabled files. Setting this property will make CMake skip the automatic detection of the rcc binary as well as the sanity-tests normally run to ensure that the binary is available and working as expected.

Usually this property does not need to be set. Only consider this property if auto-detection of rcc can not work – e.g. because you are building the rcc binary as part of your project.

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

  • cmake-properties(7) »


AUTORCC_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTORCC_OPTIONS

Additional options for rcc when using AUTORCC

This property holds additional command line options which will be used when rcc is executed during the build via AUTORCC, i.e. it is equivalent to the optional OPTIONS argument of the qt4_add_resources() macro.

By default it is empty.

This property is initialized by the value of the CMAKE_AUTORCC_OPTIONS variable if it is set when a target is created.

The options set on the target may be overridden by AUTORCC_OPTIONS set on the .qrc source file.

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

EXAMPLE

# ...
set_property(TARGET tgt PROPERTY AUTORCC_OPTIONS "--compress;9")
# ...

  • cmake-properties(7) »


BINARY_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

BINARY_DIR

This read-only property reports the value of the CMAKE_CURRENT_BINARY_DIR variable in the directory in which the target was defined.

  • cmake-properties(7) »


BUILD_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

BUILD_RPATH

A 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 INSTALL_RPATH target property.

This property is initialized by the value of the variable CMAKE_BUILD_RPATH if it is set when a target is created.

  • cmake-properties(7) »


BUILD_RPATH_USE_ORIGIN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

BUILD_RPATH_USE_ORIGIN

Whether to use relative paths for the build RPATH.

This property is initialized by the value of the variable CMAKE_BUILD_RPATH_USE_ORIGIN.

On platforms that support runtime paths (RPATH) with the $ORIGIN token, setting this property to TRUE enables relative paths in the build RPATH for executables and shared libraries that point to shared libraries in the same build tree.

Normally the build RPATH of a binary contains absolute paths to the directory of each shared library it links to. The RPATH entries for directories contained within the build tree can be made relative to enable relocatable builds and to help achieve reproducible builds by omitting the build directory from the build environment.

This property has no effect on platforms that do not support the $ORIGIN token in RPATH, or when the CMAKE_SKIP_RPATH variable is set. The runtime path set through the BUILD_RPATH target property is also unaffected by this property.

  • cmake-properties(7) »


BUILD_WITH_INSTALL_NAME_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

BUILD_WITH_INSTALL_NAME_DIR

BUILD_WITH_INSTALL_NAME_DIR is a boolean specifying whether the macOS install_name of a target in the build tree uses the directory given by INSTALL_NAME_DIR. This setting only applies to targets on macOS.

This property is initialized by the value of the variable CMAKE_BUILD_WITH_INSTALL_NAME_DIR if it is set when a target is created.

If this property is not set and policy CMP0068 is not NEW, the value of BUILD_WITH_INSTALL_RPATH is used in its place.

  • cmake-properties(7) »


BUILD_WITH_INSTALL_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

BUILD_WITH_INSTALL_RPATH

BUILD_WITH_INSTALL_RPATH is a boolean specifying whether to link the target in the build tree with the INSTALL_RPATH. This takes precedence over SKIP_BUILD_RPATH and avoids the need for relinking before installation.

This property is initialized by the value of the CMAKE_BUILD_WITH_INSTALL_RPATH variable if it is set when a target is created.

If policy CMP0068 is not NEW, this property also controls use of INSTALL_NAME_DIR in the build tree on macOS. Either way, the BUILD_WITH_INSTALL_NAME_DIR target property takes precedence.

  • cmake-properties(7) »


BUNDLE_EXTENSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

BUNDLE_EXTENSION

The file extension used to name a BUNDLE, a FRAMEWORK, or a MACOSX_BUNDLE target on the macOS and iOS.

The default value is bundle, framework, or app for the respective target types.

  • cmake-properties(7) »


BUNDLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

BUNDLE

This target is a CFBundle on the macOS.

If a module library target has this property set to true it will be built as a CFBundle when built on the mac. It will have the directory structure required for a CFBundle and will be suitable to be used for creating Browser Plugins or other application resources.

  • cmake-properties(7) »


C_EXTENSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

C_EXTENSIONS

Boolean specifying whether compiler specific extensions are requested.

This property specifies whether compiler specific extensions should be used. For some compilers, this results in adding a flag such as -std=gnu11 instead of -std=c11 to the compile line. This property is ON by default. The basic C standard level is controlled by the C_STANDARD target property.

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

This property is initialized by the value of the CMAKE_C_EXTENSIONS variable if it is set when a target is created.

  • cmake-properties(7) »


C_STANDARD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

C_STANDARD

The C standard whose features are requested to build this target.

This property specifies the C standard whose features are requested to build this target. For some compilers, this results in adding a flag such as -std=gnu11 to the compile line. For compilers that have no notion of a standard level, such as Microsoft Visual C++ before 2015 Update 3, this has no effect.

Supported values are 90, 99 and 11.

If the value requested does not result in a compile flag being added for the compiler in use, a previous standard flag will be added instead. This means that using:

set_property(TARGET tgt PROPERTY C_STANDARD 11)

with a compiler which does not support -std=gnu11 or an equivalent flag will not result in an error or warning, but will instead add the -std=gnu99 or -std=gnu90 flag if supported. This “decay” behavior may be controlled with the C_STANDARD_REQUIRED target property. Additionally, the C_EXTENSIONS target property may be used to control whether compiler-specific extensions are enabled on a per-target basis.

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

This property is initialized by the value of the CMAKE_C_STANDARD variable if it is set when a target is created.

  • cmake-properties(7) »


C_STANDARD_REQUIRED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

C_STANDARD_REQUIRED

Boolean describing whether the value of C_STANDARD is a requirement.

If this property is set to ON, then the value of the C_STANDARD target property is treated as a requirement. If this property is OFF or unset, the C_STANDARD target property is treated as optional and may “decay” to a previous standard if the requested is not available. For compilers that have no notion of a standard level, such as MSVC, this has no effect.

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

This property is initialized by the value of the CMAKE_C_STANDARD_REQUIRED variable if it is set when a target is created.

  • cmake-properties(7) »


COMMON_LANGUAGE_RUNTIME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMMON_LANGUAGE_RUNTIME

By setting this target property, the target is configured to build with C++/CLI support.

The Visual Studio generator defines the clr parameter depending on the value of COMMON_LANGUAGE_RUNTIME:

  • property not set: native C++ (i.e. default)
  • property set but empty: mixed unmanaged/managed C++
  • property set to any non empty value: managed C++

Supported values: "", "pure", "safe"

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

To be able to build managed C++ targets with VS 2017 and above the component C++/CLI support must be installed, which may not be done by default.

See also IMPORTED_COMMON_LANGUAGE_RUNTIME

  • cmake-properties(7) »


COMPATIBLE_INTERFACE_BOOL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPATIBLE_INTERFACE_BOOL

Properties which must be compatible with their link interface

The COMPATIBLE_INTERFACE_BOOL property may contain a list of properties for this target which must be consistent when evaluated as a boolean with the INTERFACE variant of the property in all linked dependees. For example, if a property FOO appears in the list, then for each dependee, the INTERFACE_FOO property content in all of its dependencies must be consistent with each other, and with the FOO property in the depender.

Consistency in this sense has the meaning that if the property is set, then it must have the same boolean value as all others, and if the property is not set, then it is ignored.

Note that for each dependee, the set of properties specified in this property must not intersect with the set specified in any of the other Compatible Interface Properties.

  • cmake-properties(7) »


COMPATIBLE_INTERFACE_NUMBER_MAX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPATIBLE_INTERFACE_NUMBER_MAX

Properties whose maximum value from the link interface will be used.

The COMPATIBLE_INTERFACE_NUMBER_MAX property may contain a list of properties for this target whose maximum value may be read at generate time when evaluated in the INTERFACE variant of the property in all linked dependees. For example, if a property FOO appears in the list, then for each dependee, the INTERFACE_FOO property content in all of its dependencies will be compared with each other and with the FOO property in the depender. When reading the FOO property at generate time, the maximum value will be returned. If the property is not set, then it is ignored.

Note that for each dependee, the set of properties specified in this property must not intersect with the set specified in any of the other Compatible Interface Properties.

  • cmake-properties(7) »


COMPATIBLE_INTERFACE_NUMBER_MIN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPATIBLE_INTERFACE_NUMBER_MIN

Properties whose maximum value from the link interface will be used.

The COMPATIBLE_INTERFACE_NUMBER_MIN property may contain a list of properties for this target whose minimum value may be read at generate time when evaluated in the INTERFACE variant of the property of all linked dependees. For example, if a property FOO appears in the list, then for each dependee, the INTERFACE_FOO property content in all of its dependencies will be compared with each other and with the FOO property in the depender. When reading the FOO property at generate time, the minimum value will be returned. If the property is not set, then it is ignored.

Note that for each dependee, the set of properties specified in this property must not intersect with the set specified in any of the other Compatible Interface Properties.

  • cmake-properties(7) »


COMPATIBLE_INTERFACE_STRING — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPATIBLE_INTERFACE_STRING

Properties which must be string-compatible with their link interface

The COMPATIBLE_INTERFACE_STRING property may contain a list of properties for this target which must be the same when evaluated as a string in the INTERFACE variant of the property all linked dependees. For example, if a property FOO appears in the list, then for each dependee, the INTERFACE_FOO property content in all of its dependencies must be equal with each other, and with the FOO property in the depender. If the property is not set, then it is ignored.

Note that for each dependee, the set of properties specified in this property must not intersect with the set specified in any of the other Compatible Interface Properties.

  • cmake-properties(7) »


COMPILE_DEFINITIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_DEFINITIONS

Preprocessor definitions for compiling a target’s sources.

The COMPILE_DEFINITIONS property may be set to a semicolon-separated list of preprocessor definitions using the syntax VAR or VAR=value. Function-style definitions are not supported. CMake will automatically escape the value correctly for the native build system (note that CMake language syntax may require escapes to specify some values).

CMake will automatically drop some definitions that are not supported by the native build tool.

Disclaimer: Most native build tools have poor support for escaping certain values. CMake has work-arounds for many cases but some values may just not be possible to pass correctly. If a value does not seem to be escaped correctly, do not attempt to work-around the problem by adding escape sequences to the value. Your work-around may break in a future version of CMake that has improved escape support. Instead consider defining the macro in a (configured) header file. Then report the limitation. Known limitations include:

#          - broken almost everywhere
;          - broken in VS IDE 7.0 and Borland Makefiles
,          - broken in VS IDE
%          - broken in some cases in NMake
& |        - broken in some cases on MinGW
^ < > \"   - broken in most Make tools on Windows

CMake does not reject these values outright because they do work in some cases. Use with caution.

Contents of COMPILE_DEFINITIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

The corresponding COMPILE_DEFINITIONS_<CONFIG> property may be set to specify per-configuration definitions. Generator expressions should be preferred instead of setting the alternative property.

  • cmake-properties(7) »


COMPILE_FEATURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_FEATURES

Compiler features enabled for this target.

The list of features in this property are a subset of the features listed in the CMAKE_CXX_COMPILE_FEATURES variable.

Contents of COMPILE_FEATURES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-compile-features(7) manual for information on compile features and a list of supported compilers.

  • cmake-properties(7) »


COMPILE_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_FLAGS

Additional flags to use when compiling this target’s sources.

The COMPILE_FLAGS property sets additional compiler flags used to build sources within the target. Use COMPILE_DEFINITIONS to pass additional preprocessor definitions.

This property is deprecated. Use the COMPILE_OPTIONS property or the target_compile_options() command instead.

  • cmake-properties(7) »


COMPILE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_OPTIONS

List of options to pass to the compiler.

This property holds a semicolon-separated list of options specified so far for its target. Use the target_compile_options() command to append more options.

This property is initialized by the COMPILE_OPTIONS directory property when a target is created, and is used by the generators to set the options for the compiler.

Contents of COMPILE_OPTIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


COMPILE_PDB_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_PDB_NAME

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

This property specifies the base name for the debug symbols file. If not set, the default is unspecified.

Note

The compiler-generated program database files are specified by the /Fd compiler flag and are not the same as linker-generated program database files specified by the /pdb linker flag. Use the PDB_NAME property to specify the latter.

  • cmake-properties(7) »


COMPILE_PDB_NAME_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_PDB_NAME_<CONFIG>

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

This is the configuration-specific version of COMPILE_PDB_NAME.

Note

The compiler-generated program database files are specified by the /Fd compiler flag and are not the same as linker-generated program database files specified by the /pdb linker flag. Use the PDB_NAME_<CONFIG> property to specify the latter.

  • cmake-properties(7) »


COMPILE_PDB_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_PDB_OUTPUT_DIRECTORY

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

This property specifies the directory into which the MS debug symbols will be placed by the compiler. This property is initialized by the value of the CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY variable if it is set when a target is created.

Note

The compiler-generated program database files are specified by the /Fd compiler flag and are not the same as linker-generated program database files specified by the /pdb linker flag. Use the PDB_OUTPUT_DIRECTORY property to specify the latter.

  • cmake-properties(7) »


COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>

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

This is a per-configuration version of COMPILE_PDB_OUTPUT_DIRECTORY, but multi-configuration generators (VS, Xcode) do NOT append a per-configuration subdirectory to the specified directory. This property is initialized by the value of the CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG> variable if it is set when a target is created.

Note

The compiler-generated program database files are specified by the /Fd compiler flag and are not the same as linker-generated program database files specified by the /pdb linker flag. Use the PDB_OUTPUT_DIRECTORY_<CONFIG> property to specify the latter.

  • cmake-properties(7) »


<CONFIG>_OUTPUT_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

<CONFIG>_OUTPUT_NAME

Old per-configuration target file base name. Use OUTPUT_NAME_<CONFIG> instead.

This is a configuration-specific version of the OUTPUT_NAME target property.

  • cmake-properties(7) »


<CONFIG>_POSTFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

<CONFIG>_POSTFIX

Postfix to append to the target file name for configuration <CONFIG>.

When building with configuration <CONFIG> the value of this property is appended to the target file name built on disk. For non-executable targets, this property is initialized by the value of the variable CMAKE_<CONFIG>_POSTFIX if it is set when a target is created. This property is ignored on the Mac for Frameworks and App Bundles.

  • cmake-properties(7) »


CROSSCOMPILING_EMULATOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CROSSCOMPILING_EMULATOR

Use the given emulator to run executables created when crosscompiling. This command will be added as a prefix to add_test(), add_custom_command(), and add_custom_target() commands for built target system executables.

This property is initialized by the value of the CMAKE_CROSSCOMPILING_EMULATOR variable if it is set when a target is created.

  • cmake-properties(7) »


CUDA_PTX_COMPILATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CUDA_PTX_COMPILATION

Compile CUDA sources to .ptx files instead of .obj files within Object Libraries.

For example:

add_library(myptx OBJECT a.cu b.cu)
set_property(TARGET myptx PROPERTY CUDA_PTX_COMPILATION ON)

  • cmake-properties(7) »


CUDA_SEPARABLE_COMPILATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CUDA_SEPARABLE_COMPILATION

CUDA only: Enables separate compilation of device code

If set this will enable separable compilation for all CUDA files for the given target.

For instance:

set_property(TARGET myexe PROPERTY CUDA_SEPARABLE_COMPILATION ON)

This property is initialized by the value of the CMAKE_CUDA_SEPARABLE_COMPILATION variable if it is set when a target is created.

  • cmake-properties(7) »


CUDA_RESOLVE_DEVICE_SYMBOLS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CUDA_RESOLVE_DEVICE_SYMBOLS

CUDA only: Enables device linking for the specific library target

If set this will enable device linking on the library target. Normally device linking is deferred until a shared library or executable is generated, allowing for multiple static libraries to resolve device symbols at the same time when they are used by a shared library or executable.

By default static library targets have this property is disabled, while shared, module, and executable targets have this property enabled.

Note that device linking is not supported for Object Libraries.

For instance:

set_property(TARGET mystaticlib PROPERTY CUDA_RESOLVE_DEVICE_SYMBOLS ON)

  • cmake-properties(7) »


CUDA_EXTENSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CUDA_EXTENSIONS

Boolean specifying whether compiler specific extensions are requested.

This property specifies whether compiler specific extensions should be used. For some compilers, this results in adding a flag such as -std=gnu++11 instead of -std=c++11 to the compile line. This property is ON by default. The basic CUDA/C++ standard level is controlled by the CUDA_STANDARD target property.

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

This property is initialized by the value of the CMAKE_CUDA_EXTENSIONS variable if it is set when a target is created.

  • cmake-properties(7) »


CUDA_STANDARD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CUDA_STANDARD

The CUDA/C++ standard whose features are requested to build this target.

This property specifies the CUDA/C++ standard whose features are requested to build this target. For some compilers, this results in adding a flag such as -std=gnu++11 to the compile line.

Supported values are 98, 11, 14.

If the value requested does not result in a compile flag being added for the compiler in use, a previous standard flag will be added instead. This means that using:

set_property(TARGET tgt PROPERTY CUDA_STANDARD 11)

with a compiler which does not support -std=gnu++11 or an equivalent flag will not result in an error or warning, but will instead add the -std=gnu++98 flag if supported. This “decay” behavior may be controlled with the CUDA_STANDARD_REQUIRED target property. Additionally, the CUDA_EXTENSIONS target property may be used to control whether compiler-specific extensions are enabled on a per-target basis.

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

This property is initialized by the value of the CMAKE_CUDA_STANDARD variable if it is set when a target is created.

  • cmake-properties(7) »


CUDA_STANDARD_REQUIRED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CUDA_STANDARD_REQUIRED

Boolean describing whether the value of CUDA_STANDARD is a requirement.

If this property is set to ON, then the value of the CUDA_STANDARD target property is treated as a requirement. If this property is OFF or unset, the CUDA_STANDARD target property is treated as optional and may “decay” to a previous standard if the requested is not available. For compilers that have no notion of a standard level, such as MSVC, this has no effect.

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

This property is initialized by the value of the CMAKE_CUDA_STANDARD_REQUIRED variable if it is set when a target is created.

  • cmake-properties(7) »


CXX_EXTENSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CXX_EXTENSIONS

Boolean specifying whether compiler specific extensions are requested.

This property specifies whether compiler specific extensions should be used. For some compilers, this results in adding a flag such as -std=gnu++11 instead of -std=c++11 to the compile line. This property is ON by default. The basic C++ standard level is controlled by the CXX_STANDARD target property.

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

This property is initialized by the value of the CMAKE_CXX_EXTENSIONS variable if it is set when a target is created.

  • cmake-properties(7) »


CXX_STANDARD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CXX_STANDARD

The C++ standard whose features are requested to build this target.

This property specifies the C++ standard whose features are requested to build this target. For some compilers, this results in adding a flag such as -std=gnu++11 to the compile line. For compilers that have no notion of a standard level, such as Microsoft Visual C++ before 2015 Update 3, this has no effect.

Supported values are 98, 11, 14, 17, and 20.

If the value requested does not result in a compile flag being added for the compiler in use, a previous standard flag will be added instead. This means that using:

set_property(TARGET tgt PROPERTY CXX_STANDARD 11)

with a compiler which does not support -std=gnu++11 or an equivalent flag will not result in an error or warning, but will instead add the -std=gnu++98 flag if supported. This “decay” behavior may be controlled with the CXX_STANDARD_REQUIRED target property. Additionally, the CXX_EXTENSIONS target property may be used to control whether compiler-specific extensions are enabled on a per-target basis.

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

This property is initialized by the value of the CMAKE_CXX_STANDARD variable if it is set when a target is created.

  • cmake-properties(7) »


CXX_STANDARD_REQUIRED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CXX_STANDARD_REQUIRED

Boolean describing whether the value of CXX_STANDARD is a requirement.

If this property is set to ON, then the value of the CXX_STANDARD target property is treated as a requirement. If this property is OFF or unset, the CXX_STANDARD target property is treated as optional and may “decay” to a previous standard if the requested is not available. For compilers that have no notion of a standard level, such as MSVC, this has no effect.

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

This property is initialized by the value of the CMAKE_CXX_STANDARD_REQUIRED variable if it is set when a target is created.

  • cmake-properties(7) »


DEBUG_POSTFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DEBUG_POSTFIX

See target property <CONFIG>_POSTFIX.

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

  • cmake-properties(7) »


DEFINE_SYMBOL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DEFINE_SYMBOL

Define a symbol when compiling this target’s sources.

DEFINE_SYMBOL sets the name of the preprocessor symbol defined when compiling sources in a shared library. If not set here then it is set to target_EXPORTS by default (with some substitutions if the target is not a valid C identifier). This is useful for headers to know whether they are being included from inside their library or outside to properly setup dllexport/dllimport decorations.

  • cmake-properties(7) »


DEPLOYMENT_REMOTE_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DEPLOYMENT_REMOTE_DIRECTORY

Set the WinCE project RemoteDirectory in DeploymentTool and RemoteExecutable in DebuggerTool in .vcproj files generated by the Visual Studio 9 2008 generator. This is useful when you want to debug on remote WinCE device. For example:

set_property(TARGET ${TARGET} PROPERTY
  DEPLOYMENT_REMOTE_DIRECTORY "\\FlashStorage")

produces:

<DeploymentTool RemoteDirectory="\FlashStorage" ... />
<DebuggerTool RemoteExecutable="\FlashStorage\target_file" ... />

  • cmake-properties(7) »


DEPLOYMENT_ADDITIONAL_FILES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DEPLOYMENT_ADDITIONAL_FILES

Set the WinCE project AdditionalFiles in DeploymentTool in .vcproj files generated by the Visual Studio 9 2008 generator. This is useful when you want to debug on remote WinCE device. Specify additional files that will be copied to the device. For example:

set_property(TARGET ${TARGET} PROPERTY
  DEPLOYMENT_ADDITIONAL_FILES "english.lng|local_folder|remote_folder|0"
  "german.lng|local_folder|remote_folder|0")

produces:

<DeploymentTool AdditionalFiles="english.lng|local_folder|remote_folder|0;german.lng|local_folder|remote_folder|0" ... />

  • cmake-properties(7) »


DOTNET_TARGET_FRAMEWORK_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DOTNET_TARGET_FRAMEWORK_VERSION

Specify the .NET target framework version.

Used to specify the .NET target framework version for C++/CLI. For example, “v4.5”.

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

Can be initialized for all targets using the variable CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION.

  • cmake-properties(7) »


EchoString — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

EchoString

A message to be displayed when the target is built.

A message to display on some generators (such as makefiles) when the target is built.

  • cmake-properties(7) »


ENABLE_EXPORTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ENABLE_EXPORTS

Specify whether an executable exports symbols for loadable modules.

Normally an executable does not export any symbols because it is the final program. It is possible for an executable to export symbols to be used by loadable modules. When this property is set to true CMake will allow other targets to “link” to the executable with the TARGET_LINK_LIBRARIES() command. On all platforms a target-level dependency on the executable is created for targets that link to it. For DLL platforms an import library will be created for the exported symbols and then used for linking. All Windows-based systems including Cygwin are DLL platforms. For non-DLL platforms that require all symbols to be resolved at link time, such as macOS, the module will “link” to the executable using a flag like -bundle_loader. For other non-DLL platforms the link rule is simply ignored since the dynamic loader will automatically bind symbols when the module is loaded.

This property is initialized by the value of the variable CMAKE_ENABLE_EXPORTS if it is set when a target is created.

  • cmake-properties(7) »


EXCLUDE_FROM_ALL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

EXCLUDE_FROM_ALL

Exclude the target from the all target.

A property on a target that indicates if the target is excluded from the default build target. If it is not, then with a Makefile for example typing make will cause this target to be built. The same concept applies to the default build of other generators.

With EXCLUDE_FROM_ALL set to false or not set at all, the target will be brought up to date as part of doing a make install or its equivalent for the CMake generator being used. If a target has EXCLUDE_FROM_ALL set to true, then any attempt to install that target has undefined behavior. Note that such a target can still safely be listed in an install(TARGETS) command as long as the install components the target belongs to are not part of the set of components that anything tries to install.

This property is enabled by default for targets that are created in directories that have EXCLUDE_FROM_ALL set to TRUE.

  • cmake-properties(7) »


EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>

Per-configuration version of target exclusion from “Build Solution”.

This is the configuration-specific version of EXCLUDE_FROM_DEFAULT_BUILD. If the generic EXCLUDE_FROM_DEFAULT_BUILD is also set on a target, EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG> takes precedence in configurations for which it has a value.

  • cmake-properties(7) »


EXCLUDE_FROM_DEFAULT_BUILD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

EXCLUDE_FROM_DEFAULT_BUILD

Exclude target from “Build Solution”.

This property is only used by Visual Studio generators. When set to TRUE, the target will not be built when you press “Build Solution”.

  • cmake-properties(7) »


EXPORT_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

EXPORT_NAME

Exported name for target files.

This sets the name for the IMPORTED target generated when it this target is is exported. If not set, the logical target name is used by default.

  • cmake-properties(7) »


EXPORT_PROPERTIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

EXPORT_PROPERTIES

List additional properties to export for a target.

This property contains a list of property names that should be exported by the install(EXPORT) and export() commands. By default only a limited number of properties are exported. This property can be used to additionally export other properties as well.

Properties starting with INTERFACE_ or IMPORTED_ are not allowed as they are reserved for internal CMake use.

Properties containing generator expressions are also not allowed.

  • cmake-properties(7) »


FOLDER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FOLDER

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

Targets with no FOLDER property will appear as top level entities in IDEs like Visual Studio. Targets with the same FOLDER property value will appear next to each other in a folder of that name. To nest folders, use FOLDER values such as ‘GUI/Dialogs’ with ‘/’ characters separating folder levels.

This property is initialized by the value of the variable CMAKE_FOLDER if it is set when a target is created.

  • cmake-properties(7) »


Fortran_FORMAT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

Fortran_FORMAT

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

This property tells CMake whether the Fortran source files in a target use fixed-format or free-format. CMake will pass the corresponding format flag to the compiler. Use the source-specific Fortran_FORMAT property to change the format of a specific source file. If the variable CMAKE_Fortran_FORMAT is set when a target is created its value is used to initialize this property.

  • cmake-properties(7) »


Fortran_MODULE_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

Fortran_MODULE_DIRECTORY

Specify output directory for Fortran modules provided by the target.

If the target contains Fortran source files that provide modules and the compiler supports a module output directory this specifies the directory in which the modules will be placed. When this property is not set the modules will be placed in the build directory corresponding to the target’s source directory. If the variable CMAKE_Fortran_MODULE_DIRECTORY is set when a target is created its value is used to initialize this property.

Note that some compilers will automatically search the module output directory for modules USEd during compilation but others will not. If your sources USE modules their location must be specified by INCLUDE_DIRECTORIES regardless of this property.

  • cmake-properties(7) »


FRAMEWORK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FRAMEWORK

Build SHARED or STATIC library as Framework Bundle on the macOS and iOS.

If such a library target has this property set to TRUE it will be built as a framework when built on the macOS and iOS. It will have the directory structure required for a framework and will be suitable to be used with the -framework option

To customize Info.plist file in the framework, use MACOSX_FRAMEWORK_INFO_PLIST target property.

For macOS see also the FRAMEWORK_VERSION target property.

Example of creation dynamicFramework:

add_library(dynamicFramework SHARED
            dynamicFramework.c
            dynamicFramework.h
)
set_target_properties(dynamicFramework PROPERTIES
  FRAMEWORK TRUE
  FRAMEWORK_VERSION C
  MACOSX_FRAMEWORK_IDENTIFIER com.cmake.dynamicFramework
  MACOSX_FRAMEWORK_INFO_PLIST Info.plist
  # "current version" in semantic format in Mach-O binary file
  VERSION 16.4.0
  # "compatibility version" in semantic format in Mach-O binary file
  SOVERSION 1.0.0
  PUBLIC_HEADER dynamicFramework.h
  XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
)

  • cmake-properties(7) »


FRAMEWORK_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FRAMEWORK_VERSION

Version of a framework created using the FRAMEWORK target property (e.g. A).

This property only affects macOS, as iOS doesn’t have versioned directory structure.

  • cmake-properties(7) »


GENERATOR_FILE_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

GENERATOR_FILE_NAME

Generator’s file for this target.

An internal property used by some generators to record the name of the project or dsp file associated with this target. Note that at configure time, this property is only set for targets created by include_external_msproject().

  • cmake-properties(7) »


GHS_INTEGRITY_APP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

GHS_INTEGRITY_APP

ON / OFF boolean to determine if an executable target should be treated as an Integrity Application.

If no value is set and if a .int file is added as a source file to the executable target it will be treated as an Integrity Application.

Supported on Green Hills MULTI.

  • cmake-properties(7) »


GHS_NO_SOURCE_GROUP_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

GHS_NO_SOURCE_GROUP_FILE

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

The default behavior or when the property is OFF is to generate a project file for the target and then a sub-project file for each source group.

When this property is ON or if CMAKE_GHS_NO_SOURCE_GROUP_FILE is ON then only a single project file is generated for the target.

Supported on Green Hills MULTI.

  • cmake-properties(7) »


GNUtoMS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

GNUtoMS

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

When linking a shared library or executable that exports symbols using GNU tools on Windows (MinGW/MSYS) with Visual Studio installed convert the import library (.dll.a) from GNU to MS format (.lib). Both import libraries will be installed by install(TARGETS) and exported by install(EXPORT) and export() to be linked by applications with either GNU- or MS-compatible tools.

If the variable CMAKE_GNUtoMS is set when a target is created its value is used to initialize this property. The variable must be set prior to the first command that enables a language such as project() or enable_language(). CMake provides the variable as an option to the user automatically when configuring on Windows with GNU tools.

  • cmake-properties(7) »


HAS_CXX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

HAS_CXX

Link the target using the C++ linker tool (obsolete).

This is equivalent to setting the LINKER_LANGUAGE property to CXX. See that property’s documentation for details.

  • cmake-properties(7) »


IMPLICIT_DEPENDS_INCLUDE_TRANSFORM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPLICIT_DEPENDS_INCLUDE_TRANSFORM

Specify #include line transforms for dependencies in a target.

This property specifies rules to transform macro-like #include lines during implicit dependency scanning of C and C++ source files. The list of rules must be semicolon-separated with each entry of the form “A_MACRO(%)=value-with-%” (the % must be literal). During dependency scanning occurrences of A_MACRO(…) on #include lines will be replaced by the value given with the macro argument substituted for ‘%’. For example, the entry

MYDIR(%)=<mydir/%>

will convert lines of the form

#include MYDIR(myheader.h)

to

#include <mydir/myheader.h>

allowing the dependency to be followed.

This property applies to sources in the target on which it is set.

  • cmake-properties(7) »


IMPORTED_COMMON_LANGUAGE_RUNTIME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_COMMON_LANGUAGE_RUNTIME

Property to define if the target uses C++/CLI.

Ignored for non-imported targets.

See also the COMMON_LANGUAGE_RUNTIME target property.

  • cmake-properties(7) »


IMPORTED_CONFIGURATIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_CONFIGURATIONS

Configurations provided for an IMPORTED target.

Set this to the list of configuration names available for an IMPORTED target. The names correspond to configurations defined in the project from which the target is imported. If the importing project uses a different set of configurations the names may be mapped using the MAP_IMPORTED_CONFIG_<CONFIG> property. Ignored for non-imported targets.

  • cmake-properties(7) »


IMPORTED_GLOBAL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_GLOBAL

Indication of whether an IMPORTED target is globally visible.

The boolean value of this property is True for targets created with the IMPORTED GLOBAL options to add_executable() or add_library(). It is always False for targets built within the project.

For targets created with the IMPORTED option to add_executable() or add_library() but without the additional option GLOBAL this is False, too. However, setting this property for such a locally IMPORTED target to True promotes that target to global scope. This promotion can only be done in the same directory where that IMPORTED target was created in the first place.

Once an imported target has been made global, it cannot be changed back to non-global. Therefore, if a project sets this property, it may only provide a value of True. CMake will issue an error if the project tries to set the property to a non-True value, even if the value was already False.

  • cmake-properties(7) »


IMPORTED_IMPLIB_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_IMPLIB_<CONFIG>

<CONFIG>-specific version of IMPORTED_IMPLIB property.

Configuration names correspond to those provided by the project from which the target is imported.

  • cmake-properties(7) »


IMPORTED_IMPLIB — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_IMPLIB

Full path to the import library for an IMPORTED target.

Set this to the location of the “.lib” part of a windows DLL. Ignored for non-imported targets.

  • cmake-properties(7) »


IMPORTED_LIBNAME_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LIBNAME_<CONFIG>

<CONFIG>-specific version of IMPORTED_LIBNAME property.

Configuration names correspond to those provided by the project from which the target is imported.

  • cmake-properties(7) »


IMPORTED_LIBNAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LIBNAME

Specify the link library name for an imported Interface Library.

An interface library builds no library file itself but does specify usage requirements for its consumers. The IMPORTED_LIBNAME property may be set to specify a single library name to be placed on the link line in place of the interface library target name as a requirement for using the interface.

This property is intended for use in naming libraries provided by a platform SDK for which the full path to a library file may not be known. The value may be a plain library name such as foo but may not be a path (e.g. /usr/lib/libfoo.so) or a flag (e.g. -Wl,...). The name is never treated as a library target name even if it happens to name one.

The IMPORTED_LIBNAME property is allowed only on imported Interface Libraries and is rejected on targets of other types (for which the IMPORTED_LOCATION target property may be used).

  • cmake-properties(7) »


IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG>

<CONFIG>-specific version of IMPORTED_LINK_DEPENDENT_LIBRARIES.

Configuration names correspond to those provided by the project from which the target is imported. If set, this property completely overrides the generic property for the named configuration.

  • cmake-properties(7) »


IMPORTED_LINK_DEPENDENT_LIBRARIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LINK_DEPENDENT_LIBRARIES

Dependent shared libraries of an imported shared library.

Shared libraries may be linked to other shared libraries as part of their implementation. On some platforms the linker searches for the dependent libraries of shared libraries they are including in the link. Set this property to the list of dependent shared libraries of an imported library. The list should be disjoint from the list of interface libraries in the INTERFACE_LINK_LIBRARIES property. On platforms requiring dependent shared libraries to be found at link time CMake uses this list to add appropriate files or paths to the link command line. Ignored for non-imported targets.

  • cmake-properties(7) »


IMPORTED_LINK_INTERFACE_LANGUAGES_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LINK_INTERFACE_LANGUAGES_<CONFIG>

<CONFIG>-specific version of IMPORTED_LINK_INTERFACE_LANGUAGES.

Configuration names correspond to those provided by the project from which the target is imported. If set, this property completely overrides the generic property for the named configuration.

  • cmake-properties(7) »


IMPORTED_LINK_INTERFACE_LANGUAGES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LINK_INTERFACE_LANGUAGES

Languages compiled into an IMPORTED static library.

Set this to the list of languages of source files compiled to produce a STATIC IMPORTED library (such as “C” or “CXX”). CMake accounts for these languages when computing how to link a target to the imported library. For example, when a C executable links to an imported C++ static library CMake chooses the C++ linker to satisfy language runtime dependencies of the static library.

This property is ignored for targets that are not STATIC libraries. This property is ignored for non-imported targets.

  • cmake-properties(7) »


IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG>

<CONFIG>-specific version of IMPORTED_LINK_INTERFACE_LIBRARIES.

Configuration names correspond to those provided by the project from which the target is imported. If set, this property completely overrides the generic property for the named configuration.

This property is ignored if the target also has a non-empty INTERFACE_LINK_LIBRARIES property.

This property is deprecated. Use INTERFACE_LINK_LIBRARIES instead.

  • cmake-properties(7) »


IMPORTED_LINK_INTERFACE_LIBRARIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LINK_INTERFACE_LIBRARIES

Transitive link interface of an IMPORTED target.

Set this to the list of libraries whose interface is included when an IMPORTED library target is linked to another target. The libraries will be included on the link line for the target. Unlike the LINK_INTERFACE_LIBRARIES property, this property applies to all imported target types, including STATIC libraries. This property is ignored for non-imported targets.

This property is ignored if the target also has a non-empty INTERFACE_LINK_LIBRARIES property.

This property is deprecated. Use INTERFACE_LINK_LIBRARIES instead.

  • cmake-properties(7) »


IMPORTED_LINK_INTERFACE_MULTIPLICITY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LINK_INTERFACE_MULTIPLICITY_<CONFIG>

<CONFIG>-specific version of IMPORTED_LINK_INTERFACE_MULTIPLICITY.

If set, this property completely overrides the generic property for the named configuration.

  • cmake-properties(7) »


IMPORTED_LINK_INTERFACE_MULTIPLICITY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LINK_INTERFACE_MULTIPLICITY

Repetition count for cycles of IMPORTED static libraries.

This is LINK_INTERFACE_MULTIPLICITY for IMPORTED targets.

  • cmake-properties(7) »


IMPORTED_LOCATION_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LOCATION_<CONFIG>

<CONFIG>-specific version of IMPORTED_LOCATION property.

Configuration names correspond to those provided by the project from which the target is imported.

  • cmake-properties(7) »


IMPORTED_LOCATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_LOCATION

Full path to the main file on disk for an IMPORTED target.

Set this to the location of an IMPORTED target file on disk. For executables this is the location of the executable file. For bundles on macOS this is the location of the executable file inside Contents/MacOS under the application bundle folder. For static libraries and modules this is the location of the library or module. For shared libraries on non-DLL platforms this is the location of the shared library. For frameworks on macOS this is the location of the library file symlink just inside the framework folder. For DLLs this is the location of the “.dll” part of the library. For UNKNOWN libraries this is the location of the file to be linked. Ignored for non-imported targets.

Projects may skip IMPORTED_LOCATION if the configuration-specific property IMPORTED_LOCATION_<CONFIG> is set. To get the location of an imported target read one of the LOCATION or LOCATION_<CONFIG> properties.

  • cmake-properties(7) »


IMPORTED_NO_SONAME_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_NO_SONAME_<CONFIG>

<CONFIG>-specific version of IMPORTED_NO_SONAME property.

Configuration names correspond to those provided by the project from which the target is imported.

  • cmake-properties(7) »


IMPORTED_NO_SONAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_NO_SONAME

Specifies that an IMPORTED shared library target has no “soname”.

Set this property to true for an imported shared library file that has no “soname” field. CMake may adjust generated link commands for some platforms to prevent the linker from using the path to the library in place of its missing soname. Ignored for non-imported targets.

  • cmake-properties(7) »


IMPORTED_OBJECTS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_OBJECTS_<CONFIG>

<CONFIG>-specific version of IMPORTED_OBJECTS property.

Configuration names correspond to those provided by the project from which the target is imported.

  • cmake-properties(7) »


IMPORTED_OBJECTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_OBJECTS

A semicolon-separated list of absolute paths to the object files on disk for an imported object library.

Ignored for non-imported targets.

Projects may skip IMPORTED_OBJECTS if the configuration-specific property IMPORTED_OBJECTS_<CONFIG> is set instead.

  • cmake-properties(7) »


IMPORTED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED

Read-only indication of whether a target is IMPORTED.

The boolean value of this property is True for targets created with the IMPORTED option to add_executable() or add_library(). It is False for targets built within the project.

  • cmake-properties(7) »


IMPORTED_SONAME_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_SONAME_<CONFIG>

<CONFIG>-specific version of IMPORTED_SONAME property.

Configuration names correspond to those provided by the project from which the target is imported.

  • cmake-properties(7) »


IMPORTED_SONAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORTED_SONAME

The “soname” of an IMPORTED target of shared library type.

Set this to the “soname” embedded in an imported shared library. This is meaningful only on platforms supporting the feature. Ignored for non-imported targets.

  • cmake-properties(7) »


IMPORT_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORT_PREFIX

What comes before the import library name.

Similar to the target property PREFIX, but used for import libraries (typically corresponding to a DLL) instead of regular libraries. A target property that can be set to override the prefix (such as “lib”) on an import library name.

  • cmake-properties(7) »


IMPORT_SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IMPORT_SUFFIX

What comes after the import library name.

Similar to the target property SUFFIX, but used for import libraries (typically corresponding to a DLL) instead of regular libraries. A target property that can be set to override the suffix (such as “.lib”) on an import library name.

  • cmake-properties(7) »


INCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INCLUDE_DIRECTORIES

List of preprocessor include file search directories.

This property specifies the list of directories given so far to the target_include_directories() command. In addition to accepting values from that command, values may be set directly on any target using the set_property() command. A target gets its initial value for this property from the value of the INCLUDE_DIRECTORIES directory property. Both directory and target property values are adjusted by calls to the include_directories() command.

The value of this property is used by the generators to set the include paths for the compiler.

Relative paths should not be added to this property directly. Use one of the commands above instead to handle relative paths.

Contents of INCLUDE_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


INSTALL_NAME_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INSTALL_NAME_DIR

Mac OSX directory name for installed targets.

INSTALL_NAME_DIR is a string specifying the directory portion of the “install_name” field of shared libraries on Mac OSX to use in the installed targets.

This property is initialized by the value of the variable CMAKE_INSTALL_NAME_DIR if it is set when a target is created.

  • cmake-properties(7) »


INSTALL_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

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 property is initialized by the value of the variable CMAKE_INSTALL_RPATH if it is set when a target is created.

  • cmake-properties(7) »


INSTALL_RPATH_USE_LINK_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INSTALL_RPATH_USE_LINK_PATH

Add paths to linker search and installed rpath.

INSTALL_RPATH_USE_LINK_PATH is a boolean that if set to true will append directories in the linker search path and outside the project to the INSTALL_RPATH. This property is initialized by the value of the variable CMAKE_INSTALL_RPATH_USE_LINK_PATH if it is set when a target is created.

  • cmake-properties(7) »


INTERFACE_AUTOUIC_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_AUTOUIC_OPTIONS

List of interface options to pass to uic.

Targets may populate this property to publish the options required to use when invoking uic. Consuming targets can add entries to their own AUTOUIC_OPTIONS property such as $<TARGET_PROPERTY:foo,INTERFACE_AUTOUIC_OPTIONS> to use the uic options specified in the interface of foo. This is done automatically by the target_link_libraries() command.

This property supports generator expressions. See the cmake-generator-expressions(7) manual for available expressions.

  • cmake-properties(7) »


INTERFACE_COMPILE_DEFINITIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_COMPILE_DEFINITIONS

List of public compile definitions requirements for a library.

Targets may populate this property to publish the compile definitions required to compile against the headers for the target. The target_compile_definitions() command populates this property with values given to the PUBLIC and INTERFACE keywords. Projects may also get and set the property directly.

When target dependencies are specified using target_link_libraries(), CMake will read this property from all target dependencies to determine the build properties of the consumer.

Contents of INTERFACE_COMPILE_DEFINITIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) -manual for more on defining buildsystem properties.

  • cmake-properties(7) »


INTERFACE_COMPILE_FEATURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_COMPILE_FEATURES

List of public compile features requirements for a library.

Targets may populate this property to publish the compile features required to compile against the headers for the target. The target_compile_features() command populates this property with values given to the PUBLIC and INTERFACE keywords. Projects may also get and set the property directly.

When target dependencies are specified using target_link_libraries(), CMake will read this property from all target dependencies to determine the build properties of the consumer.

Contents of INTERFACE_COMPILE_FEATURES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) -manual for more on defining buildsystem properties.

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

  • cmake-properties(7) »


INTERFACE_COMPILE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_COMPILE_OPTIONS

List of public compile options requirements for a library.

Targets may populate this property to publish the compile options required to compile against the headers for the target. The target_compile_options() command populates this property with values given to the PUBLIC and INTERFACE keywords. Projects may also get and set the property directly.

When target dependencies are specified using target_link_libraries(), CMake will read this property from all target dependencies to determine the build properties of the consumer.

Contents of INTERFACE_COMPILE_OPTIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) -manual for more on defining buildsystem properties.

  • cmake-properties(7) »


INTERFACE_INCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_INCLUDE_DIRECTORIES

List of public include directories requirements for a library.

Targets may populate this property to publish the include directories required to compile against the headers for the target. The target_include_directories() command populates this property with values given to the PUBLIC and INTERFACE keywords. Projects may also get and set the property directly.

When target dependencies are specified using target_link_libraries(), CMake will read this property from all target dependencies to determine the build properties of the consumer.

Contents of INTERFACE_INCLUDE_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) -manual for more on defining buildsystem properties.

Include directories usage requirements commonly differ between the build-tree and the install-tree. The BUILD_INTERFACE and INSTALL_INTERFACE generator expressions can be used to describe separate usage requirements based on the usage location. Relative paths are allowed within the INSTALL_INTERFACE expression and are interpreted relative to the installation prefix. For example:

target_include_directories(mylib INTERFACE
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include/mylib>
  $<INSTALL_INTERFACE:include/mylib>  # <prefix>/include/mylib
)

Creating Relocatable Packages

Note that it is not advisable to populate the INSTALL_INTERFACE of the INTERFACE_INCLUDE_DIRECTORIES of a target with absolute paths to the include directories of dependencies. That would hard-code into installed packages the include directory paths for dependencies as found on the machine the package was made on.

The INSTALL_INTERFACE of the INTERFACE_INCLUDE_DIRECTORIES is only suitable for specifying the required include directories for headers provided with the target itself, not those provided by the transitive dependencies listed in its INTERFACE_LINK_LIBRARIES target property. Those dependencies should themselves be targets that specify their own header locations in INTERFACE_INCLUDE_DIRECTORIES.

See the Creating Relocatable Packages section of the cmake-packages(7) manual for discussion of additional care that must be taken when specifying usage requirements while creating packages for redistribution.

  • cmake-properties(7) »


INTERFACE_LINK_DEPENDS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_LINK_DEPENDS

Additional public interface files on which a target binary depends for linking.

This property is supported only by Makefile and Ninja generators. It is intended to specify dependencies on “linker scripts” for custom Makefile link rules.

When target dependencies are specified using target_link_libraries(), CMake will read this property from all target dependencies to determine the build properties of the consumer.

Contents of INTERFACE_LINK_DEPENDS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) -manual for more on defining buildsystem properties.

Link dependency files usage requirements commonly differ between the build-tree and the install-tree. The BUILD_INTERFACE and INSTALL_INTERFACE generator expressions can be used to describe separate usage requirements based on the usage location. Relative paths are allowed within the INSTALL_INTERFACE expression and are interpreted relative to the installation prefix. For example:

set_property(TARGET mylib PROPERTY INTERFACE_LINK_DEPENDS
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/mylinkscript>
  $<INSTALL_INTERFACE:mylinkscript>  # <prefix>/mylinkscript
)

  • cmake-properties(7) »


INTERFACE_LINK_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_LINK_DIRECTORIES

List of public link directories requirements for a library.

Targets may populate this property to publish the link directories required to compile against the headers for the target. The target_link_directories() command populates this property with values given to the PUBLIC and INTERFACE keywords. Projects may also get and set the property directly.

When target dependencies are specified using target_link_libraries(), CMake will read this property from all target dependencies to determine the build properties of the consumer.

Contents of INTERFACE_LINK_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) -manual for more on defining buildsystem properties.

  • cmake-properties(7) »


INTERFACE_LINK_LIBRARIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_LINK_LIBRARIES

List public interface libraries for a library.

This property contains the list of transitive link dependencies. When the target is linked into another target using the target_link_libraries() command, the libraries listed (and recursively their link interface libraries) will be provided to the other target also. This property is overridden by the LINK_INTERFACE_LIBRARIES or LINK_INTERFACE_LIBRARIES_<CONFIG> property if policy CMP0022 is OLD or unset.

Contents of INTERFACE_LINK_LIBRARIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Note

A call to target_link_libraries(<target> ...) may update this property on <target>. If <target> was not created in the same directory as the call then target_link_libraries() will add a suffix of the form ::@<directory-id> to each entry, where the ::@ is a separator and the <directory-id> is unspecified. This tells the generators that the named libraries must be looked up in the scope of the caller rather than in the scope in which the <target> was created. Valid directory ids are stripped on export by the install(EXPORT) and export() commands.

Creating Relocatable Packages

Note that it is not advisable to populate the INTERFACE_LINK_LIBRARIES of a target with absolute paths to dependencies. That would hard-code into installed packages the library file paths for dependencies as found on the machine the package was made on.

See the Creating Relocatable Packages section of the cmake-packages(7) manual for discussion of additional care that must be taken when specifying usage requirements while creating packages for redistribution.

  • cmake-properties(7) »


INTERFACE_LINK_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_LINK_OPTIONS

List of public link options requirements for a library.

Targets may populate this property to publish the link options required to compile against the headers for the target. The target_link_options() command populates this property with values given to the PUBLIC and INTERFACE keywords. Projects may also get and set the property directly.

When target dependencies are specified using target_link_libraries(), CMake will read this property from all target dependencies to determine the build properties of the consumer.

Contents of INTERFACE_LINK_OPTIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) -manual for more on defining buildsystem properties.

  • cmake-properties(7) »


INTERFACE_POSITION_INDEPENDENT_CODE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_POSITION_INDEPENDENT_CODE

Whether consumers need to create a position-independent target

The INTERFACE_POSITION_INDEPENDENT_CODE property informs consumers of this target whether they must set their POSITION_INDEPENDENT_CODE property to ON. If this property is set to ON, then the POSITION_INDEPENDENT_CODE property on all consumers will be set to ON. Similarly, if this property is set to OFF, then the POSITION_INDEPENDENT_CODE property on all consumers will be set to OFF. If this property is undefined, then consumers will determine their POSITION_INDEPENDENT_CODE property by other means. Consumers must ensure that the targets that they link to have a consistent requirement for their INTERFACE_POSITION_INDEPENDENT_CODE property.

Contents of INTERFACE_POSITION_INDEPENDENT_CODE may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


INTERFACE_SOURCES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_SOURCES

List of interface sources to compile into consuming targets.

Targets may populate this property to publish the sources for consuming targets to compile. The target_sources() command populates this property with values given to the PUBLIC and INTERFACE keywords. Projects may also get and set the property directly.

When target dependencies are specified using target_link_libraries(), CMake will read this property from all target dependencies to determine the sources of the consumer.

Contents of INTERFACE_SOURCES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


INTERFACE_SYSTEM_INCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERFACE_SYSTEM_INCLUDE_DIRECTORIES

List of public system include directories for a library.

Targets may populate this property to publish the include directories which contain system headers, and therefore should not result in compiler warnings. The target_include_directories(SYSTEM) command signature populates this property with values given to the PUBLIC and INTERFACE keywords.

Projects may also get and set the property directly, but must be aware that adding directories to this property does not make those directories used during compilation. Adding directories to this property marks directories as SYSTEM which otherwise would be used in a non-SYSTEM manner. This can appear similar to ‘duplication’, so prefer the high-level target_include_directories(SYSTEM) command and avoid setting the property by low-level means.

When target dependencies are specified using target_link_libraries(), CMake will read this property from all target dependencies to mark the same include directories as containing system headers.

Contents of INTERFACE_SYSTEM_INCLUDE_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


INTERPROCEDURAL_OPTIMIZATION_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERPROCEDURAL_OPTIMIZATION_<CONFIG>

Per-configuration interprocedural optimization for a target.

This is a per-configuration version of INTERPROCEDURAL_OPTIMIZATION. If set, this property overrides the generic property for the named configuration.

This property is initialized by the CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG> variable if it is set when a target is created.

  • cmake-properties(7) »


INTERPROCEDURAL_OPTIMIZATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INTERPROCEDURAL_OPTIMIZATION

Enable interprocedural optimization for a target.

If set to true, enables interprocedural optimizations if they are known to be supported by the compiler.

This property is initialized by the CMAKE_INTERPROCEDURAL_OPTIMIZATION variable if it is set when a target is created.

  • cmake-properties(7) »


IOS_INSTALL_COMBINED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

IOS_INSTALL_COMBINED

Build a combined (device and simulator) target when installing.

When this property is set to set to false (which is the default) then it will either be built with the device SDK or the simulator SDK depending on the SDK set. But if this property is set to true then the target will at install time also be built for the corresponding SDK and combined into one library.

This feature requires at least Xcode version 6.

  • cmake-properties(7) »


JOB_POOL_COMPILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

JOB_POOL_COMPILE

Ninja only: Pool used for compiling.

The number of parallel compile processes could be limited by defining pools with the global JOB_POOLS property and then specifying here the pool name.

For instance:

set_property(TARGET myexe PROPERTY JOB_POOL_COMPILE ten_jobs)

This property is initialized by the value of CMAKE_JOB_POOL_COMPILE.

  • cmake-properties(7) »


JOB_POOL_LINK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

JOB_POOL_LINK

Ninja only: Pool used for linking.

The number of parallel link processes could be limited by defining pools with the global JOB_POOLS property and then specifying here the pool name.

For instance:

set_property(TARGET myexe PROPERTY JOB_POOL_LINK two_jobs)

This property is initialized by the value of CMAKE_JOB_POOL_LINK.

  • cmake-properties(7) »


LABELS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LABELS

Specify a list of text labels associated with a target.

Target label semantics are currently unspecified.

  • cmake-properties(7) »


<LANG>_CLANG_TIDY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

<LANG>_CLANG_TIDY

This property is implemented only when <LANG> is C or CXX.

Specify a semicolon-separated list containing a command line for the clang-tidy tool. The Makefile Generators and the Ninja generator will run this tool along with the compiler and report a warning if the tool reports any problems.

This property is initialized by the value of the CMAKE_<LANG>_CLANG_TIDY variable if it is set when a target is created.

  • cmake-properties(7) »


<LANG>_COMPILER_LAUNCHER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

<LANG>_COMPILER_LAUNCHER

This property is implemented only when <LANG> is C, CXX, Fortran, or CUDA.

Specify a semicolon-separated list containing a command line for a compiler launching tool. The Makefile Generators and the Ninja generator will run this tool and pass the compiler and its arguments to the tool. Some example tools are distcc and ccache.

This property is initialized by the value of the CMAKE_<LANG>_COMPILER_LAUNCHER variable if it is set when a target is created.

  • cmake-properties(7) »


<LANG>_CPPCHECK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

<LANG>_CPPCHECK

This property is supported only when <LANG> is C or CXX.

Specify a semicolon-separated list containing a command line for the cppcheck static analysis tool. The Makefile Generators and the Ninja generator will run cppcheck along with the compiler and report any problems. If the command-line specifies the exit code options to cppcheck then the build will fail if the tool returns non-zero.

This property is initialized by the value of the CMAKE_<LANG>_CPPCHECK variable if it is set when a target is created.

  • cmake-properties(7) »


<LANG>_CPPLINT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

<LANG>_CPPLINT

This property is supported only when <LANG> is C or CXX.

Specify a semicolon-separated list containing a command line for the cpplint style checker. The Makefile Generators and the Ninja generator will run cpplint along with the compiler and report any problems.

This property is initialized by the value of the CMAKE_<LANG>_CPPLINT variable if it is set when a target is created.

  • cmake-properties(7) »


<LANG>_INCLUDE_WHAT_YOU_USE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

<LANG>_INCLUDE_WHAT_YOU_USE

This property is implemented only when <LANG> is C or CXX.

Specify a semicolon-separated list containing a command line for the include-what-you-use tool. The Makefile Generators and the Ninja generator will run this tool along with the compiler and report a warning if the tool reports any problems.

This property is initialized by the value of the CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE variable if it is set when a target is created.

  • cmake-properties(7) »


<LANG>_VISIBILITY_PRESET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

<LANG>_VISIBILITY_PRESET

Value for symbol visibility compile flags

The <LANG>_VISIBILITY_PRESET property determines the value passed in a visibility related compile option, such as -fvisibility= for <LANG>. This property affects compilation in sources of all types of targets (subject to policy CMP0063).

This property is initialized by the value of the CMAKE_<LANG>_VISIBILITY_PRESET variable if it is set when a target is created.

  • cmake-properties(7) »


LIBRARY_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LIBRARY_OUTPUT_DIRECTORY_<CONFIG>

Per-configuration output directory for LIBRARY target files.

This is a per-configuration version of the LIBRARY_OUTPUT_DIRECTORY target property, but multi-configuration generators (VS, Xcode) do NOT append a per-configuration subdirectory to the specified directory. This property is initialized by the value of the CMAKE_LIBRARY_OUTPUT_DIRECTORY_<CONFIG> variable if it is set when a target is created.

Contents of LIBRARY_OUTPUT_DIRECTORY_<CONFIG> may use generator expressions.

  • cmake-properties(7) »


LIBRARY_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LIBRARY_OUTPUT_DIRECTORY

Output directory in which to build LIBRARY target files.

This property specifies the directory into which library target files should be built. The property value may use generator expressions. Multi-configuration generators (VS, Xcode) append a per-configuration subdirectory to the specified directory unless a generator expression is used.

This property is initialized by the value of the variable CMAKE_LIBRARY_OUTPUT_DIRECTORY if it is set when a target is created.

See also the LIBRARY_OUTPUT_DIRECTORY_<CONFIG> target property.

  • cmake-properties(7) »


LIBRARY_OUTPUT_NAME_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LIBRARY_OUTPUT_NAME_<CONFIG>

Per-configuration output name for LIBRARY target files.

This is the configuration-specific version of the LIBRARY_OUTPUT_NAME target property.

  • cmake-properties(7) »


LIBRARY_OUTPUT_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LIBRARY_OUTPUT_NAME

Output name for LIBRARY target files.

This property specifies the base name for library target files. It overrides OUTPUT_NAME and OUTPUT_NAME_<CONFIG> properties.

See also the LIBRARY_OUTPUT_NAME_<CONFIG> target property.

  • cmake-properties(7) »


LINK_DEPENDS_NO_SHARED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_DEPENDS_NO_SHARED

Do not depend on linked shared library files.

Set this property to true to tell CMake generators not to add file-level dependencies on the shared library files linked by this target. Modification to the shared libraries will not be sufficient to re-link this target. Logical target-level dependencies will not be affected so the linked shared libraries will still be brought up to date before this target is built.

This property is initialized by the value of the variable CMAKE_LINK_DEPENDS_NO_SHARED if it is set when a target is created.

  • cmake-properties(7) »


LINK_DEPENDS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_DEPENDS

Additional files on which a target binary depends for linking.

Specifies a semicolon-separated list of full-paths to files on which the link rule for this target depends. The target binary will be linked if any of the named files is newer than it.

This property is supported only by Makefile and Ninja generators. It is intended to specify dependencies on “linker scripts” for custom Makefile link rules.

Contents of LINK_DEPENDS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


LINKER_LANGUAGE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINKER_LANGUAGE

Specifies language whose compiler will invoke the linker.

For executables, shared libraries, and modules, this sets the language whose compiler is used to link the target (such as “C” or “CXX”). A typical value for an executable is the language of the source file providing the program entry point (main). If not set, the language with the highest linker preference value is the default. See documentation of CMAKE_<LANG>_LINKER_PREFERENCE variables.

If this property is not set by the user, it will be calculated at generate-time by CMake.

  • cmake-properties(7) »


LINK_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_DIRECTORIES

List of directories to use for the link step of shared library, module and executable targets.

This property holds a semicolon-separated list of directories specified so far for its target. Use the target_link_directories() command to append more search directories.

This property is initialized by the LINK_DIRECTORIES directory property when a target is created, and is used by the generators to set the search directories for the linker.

Contents of LINK_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


LINK_FLAGS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_FLAGS_<CONFIG>

Per-configuration linker flags for a shared library, module or executable target.

This is the configuration-specific version of LINK_FLAGS.

Note

This property has been superseded by LINK_OPTIONS property.

  • cmake-properties(7) »


LINK_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_FLAGS

Additional flags to use when linking this target if it is a shared library, module library, or an executable. Static libraries need to use STATIC_LIBRARY_OPTIONS or STATIC_LIBRARY_FLAGS properties.

The LINK_FLAGS property, managed as a string, can be used to add extra flags to the link step of a target. LINK_FLAGS_<CONFIG> will add to the configuration <CONFIG>, for example, DEBUG, RELEASE, MINSIZEREL, RELWITHDEBINFO, …

Note

This property has been superseded by LINK_OPTIONS property.

  • cmake-properties(7) »


LINK_INTERFACE_LIBRARIES_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_INTERFACE_LIBRARIES_<CONFIG>

Per-configuration list of public interface libraries for a target.

This is the configuration-specific version of LINK_INTERFACE_LIBRARIES. If set, this property completely overrides the generic property for the named configuration.

This property is overridden by the INTERFACE_LINK_LIBRARIES property if policy CMP0022 is NEW.

This property is deprecated. Use INTERFACE_LINK_LIBRARIES instead.

Creating Relocatable Packages

Note that it is not advisable to populate the LINK_INTERFACE_LIBRARIES_<CONFIG> of a target with absolute paths to dependencies. That would hard-code into installed packages the library file paths for dependencies as found on the machine the package was made on.

See the Creating Relocatable Packages section of the cmake-packages(7) manual for discussion of additional care that must be taken when specifying usage requirements while creating packages for redistribution.

  • cmake-properties(7) »


LINK_INTERFACE_LIBRARIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_INTERFACE_LIBRARIES

List public interface libraries for a shared library or executable.

By default linking to a shared library target transitively links to targets with which the library itself was linked. For an executable with exports (see the ENABLE_EXPORTS target property) no default transitive link dependencies are used. This property replaces the default transitive link dependencies with an explicit list. When the target is linked into another target using the target_link_libraries() command, the libraries listed (and recursively their link interface libraries) will be provided to the other target also. If the list is empty then no transitive link dependencies will be incorporated when this target is linked into another target even if the default set is non-empty. This property is initialized by the value of the CMAKE_LINK_INTERFACE_LIBRARIES variable if it is set when a target is created. This property is ignored for STATIC libraries.

This property is overridden by the INTERFACE_LINK_LIBRARIES property if policy CMP0022 is NEW.

This property is deprecated. Use INTERFACE_LINK_LIBRARIES instead.

Creating Relocatable Packages

Note that it is not advisable to populate the LINK_INTERFACE_LIBRARIES of a target with absolute paths to dependencies. That would hard-code into installed packages the library file paths for dependencies as found on the machine the package was made on.

See the Creating Relocatable Packages section of the cmake-packages(7) manual for discussion of additional care that must be taken when specifying usage requirements while creating packages for redistribution.

  • cmake-properties(7) »


LINK_INTERFACE_MULTIPLICITY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_INTERFACE_MULTIPLICITY_<CONFIG>

Per-configuration repetition count for cycles of STATIC libraries.

This is the configuration-specific version of LINK_INTERFACE_MULTIPLICITY. If set, this property completely overrides the generic property for the named configuration.

  • cmake-properties(7) »


LINK_INTERFACE_MULTIPLICITY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_INTERFACE_MULTIPLICITY

Repetition count for STATIC libraries with cyclic dependencies.

When linking to a STATIC library target with cyclic dependencies the linker may need to scan more than once through the archives in the strongly connected component of the dependency graph. CMake by default constructs the link line so that the linker will scan through the component at least twice. This property specifies the minimum number of scans if it is larger than the default. CMake uses the largest value specified by any target in a component.

  • cmake-properties(7) »


LINK_LIBRARIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_LIBRARIES

List of direct link dependencies.

This property specifies the list of libraries or targets which will be used for linking. In addition to accepting values from the target_link_libraries() command, values may be set directly on any target using the set_property() command.

The value of this property is used by the generators to set the link libraries for the compiler.

Contents of LINK_LIBRARIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Note

A call to target_link_libraries(<target> ...) may update this property on <target>. If <target> was not created in the same directory as the call then target_link_libraries() will add a suffix of the form ::@<directory-id> to each entry, where the ::@ is a separator and the <directory-id> is unspecified. This tells the generators that the named libraries must be looked up in the scope of the caller rather than in the scope in which the <target> was created. Valid directory ids are stripped on export by the install(EXPORT) and export() commands.

  • cmake-properties(7) »


LINK_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_OPTIONS

List of options to use for the link step of shared library, module and executable targets. Targets that are static libraries need to use the STATIC_LIBRARY_OPTIONS target property.

This property holds a semicolon-separated list of options specified so far for its target. Use the target_link_options() command to append more options.

This property is initialized by the LINK_OPTIONS directory property when a target is created, and is used by the generators to set the options for the compiler.

Contents of LINK_OPTIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Note

This property must be used in preference to LINK_FLAGS property.

  • cmake-properties(7) »


LINK_SEARCH_END_STATIC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_SEARCH_END_STATIC

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 property is initialized by the value of the variable CMAKE_LINK_SEARCH_END_STATIC if it is set when a target is created.

See also LINK_SEARCH_START_STATIC.

  • cmake-properties(7) »


LINK_SEARCH_START_STATIC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_SEARCH_START_STATIC

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 property is initialized by the value of the variable CMAKE_LINK_SEARCH_START_STATIC if it is set when a target is created.

See also LINK_SEARCH_END_STATIC.

  • cmake-properties(7) »


LINK_WHAT_YOU_USE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LINK_WHAT_YOU_USE

This is a boolean option that when set to TRUE will automatically run ldd -r -u on the target after it is linked. In addition, the linker flag -Wl,--no-as-needed will be passed to the target with the link command so that all libraries specified on the command line will be linked into the target. This will result in the link producing a list of libraries that provide no symbols used by this target but are being linked to it. This is only applicable to executable and shared library targets and will only work when ld and ldd accept the flags used.

This property is initialized by the value of the CMAKE_LINK_WHAT_YOU_USE variable if it is set when a target is created.

  • cmake-properties(7) »


LOCATION_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LOCATION_<CONFIG>

Read-only property providing a target location on disk.

A read-only property that indicates where a target’s main file is located on disk for the configuration <CONFIG>. The property is defined only for library and executable targets. An imported target may provide a set of configurations different from that of the importing project. By default CMake looks for an exact-match but otherwise uses an arbitrary available configuration. Use the MAP_IMPORTED_CONFIG_<CONFIG> property to map imported configurations explicitly.

Do not set properties that affect the location of a target after reading this property. These include properties whose names match “(RUNTIME|LIBRARY|ARCHIVE)_OUTPUT_(NAME|DIRECTORY)(_<CONFIG>)?”, (IMPLIB_)?(PREFIX|SUFFIX), or “LINKER_LANGUAGE”. Failure to follow this rule is not diagnosed and leaves the location of the target undefined.

  • cmake-properties(7) »


LOCATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LOCATION

Read-only location of a target on disk.

For an imported target, this read-only property returns the value of the LOCATION_<CONFIG> property for an unspecified configuration <CONFIG> provided by the target.

For a non-imported target, this property is provided for compatibility with CMake 2.4 and below. It was meant to get the location of an executable target’s output file for use in add_custom_command. The path may contain a build-system-specific portion that is replaced at build time with the configuration getting built (such as “$(ConfigurationName)” in VS). In CMake 2.6 and above add_custom_command automatically recognizes a target name in its COMMAND and DEPENDS options and computes the target location. In CMake 2.8.4 and above add_custom_command recognizes generator expressions to refer to target locations anywhere in the command. Therefore this property is not needed for creating custom commands.

Do not set properties that affect the location of a target after reading this property. These include properties whose names match “(RUNTIME|LIBRARY|ARCHIVE)_OUTPUT_(NAME|DIRECTORY)(_<CONFIG>)?”, (IMPLIB_)?(PREFIX|SUFFIX), or “LINKER_LANGUAGE”. Failure to follow this rule is not diagnosed and leaves the location of the target undefined.

  • cmake-properties(7) »


MACOSX_BUNDLE_INFO_PLIST — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MACOSX_BUNDLE_INFO_PLIST

Specify a custom Info.plist template for a macOS and iOS Application Bundle.

An executable target with MACOSX_BUNDLE enabled will be built as an application bundle on macOS. By default its Info.plist file is created by configuring a template called MacOSXBundleInfo.plist.in located in the CMAKE_MODULE_PATH. This property specifies an alternative template file name which may be a full path.

The following target properties may be set to specify content to be configured into the file:

MACOSX_BUNDLE_BUNDLE_NAME
Sets CFBundleName.
MACOSX_BUNDLE_BUNDLE_VERSION
Sets CFBundleVersion.
MACOSX_BUNDLE_COPYRIGHT
Sets NSHumanReadableCopyright.
MACOSX_BUNDLE_GUI_IDENTIFIER
Sets CFBundleIdentifier.
MACOSX_BUNDLE_ICON_FILE
Sets CFBundleIconFile.
MACOSX_BUNDLE_INFO_STRING
Sets CFBundleGetInfoString.
MACOSX_BUNDLE_LONG_VERSION_STRING
Sets CFBundleLongVersionString.
MACOSX_BUNDLE_SHORT_VERSION_STRING
Sets CFBundleShortVersionString.

CMake variables of the same name may be set to affect all targets in a directory that do not have each specific property set. If a custom Info.plist is specified by this property it may of course hard-code all the settings instead of using the target properties.

  • cmake-properties(7) »


MACOSX_BUNDLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MACOSX_BUNDLE

Build an executable as an Application Bundle on macOS or iOS.

When this property is set to TRUE the executable when built on macOS or iOS will be created as an application bundle. This makes it a GUI executable that can be launched from the Finder. See the MACOSX_BUNDLE_INFO_PLIST target property for information about creation of the Info.plist file for the application bundle. This property is initialized by the value of the variable CMAKE_MACOSX_BUNDLE if it is set when a target is created.

  • cmake-properties(7) »


MACOSX_FRAMEWORK_INFO_PLIST — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MACOSX_FRAMEWORK_INFO_PLIST

Specify a custom Info.plist template for a macOS and iOS Framework.

A library target with FRAMEWORK enabled will be built as a framework on macOS. By default its Info.plist file is created by configuring a template called MacOSXFrameworkInfo.plist.in located in the CMAKE_MODULE_PATH. This property specifies an alternative template file name which may be a full path.

The following target properties may be set to specify content to be configured into the file:

MACOSX_FRAMEWORK_BUNDLE_VERSION
Sets CFBundleVersion.
MACOSX_FRAMEWORK_ICON_FILE
Sets CFBundleIconFile.
MACOSX_FRAMEWORK_IDENTIFIER
Sets CFBundleIdentifier.
MACOSX_FRAMEWORK_SHORT_VERSION_STRING
Sets CFBundleShortVersionString.

CMake variables of the same name may be set to affect all targets in a directory that do not have each specific property set. If a custom Info.plist is specified by this property it may of course hard-code all the settings instead of using the target properties.

  • cmake-properties(7) »


MACOSX_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MACOSX_RPATH

Whether this target on macOS or iOS is located at runtime using rpaths.

When this property is set to TRUE, the directory portion of the install_name field of this shared library will be @rpath unless overridden by INSTALL_NAME_DIR. This indicates the shared library is to be found at runtime using runtime paths (rpaths).

This property is initialized by the value of the variable CMAKE_MACOSX_RPATH if it is set when a target is created.

Runtime paths will also be embedded in binaries using this target and can be controlled by the INSTALL_RPATH target property on the target linking to this target.

Policy CMP0042 was introduced to change the default value of MACOSX_RPATH to TRUE. This is because use of @rpath is a more flexible and powerful alternative to @executable_path and @loader_path.

  • cmake-properties(7) »


MANUALLY_ADDED_DEPENDENCIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MANUALLY_ADDED_DEPENDENCIES

Get manually added dependencies to other top-level targets.

This read-only property can be used to query all dependencies that were added for this target with the add_dependencies() command.

  • cmake-properties(7) »


MAP_IMPORTED_CONFIG_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MAP_IMPORTED_CONFIG_<CONFIG>

Map from project configuration to imported target’s configuration.

Set this to the list of configurations of an imported target that may be used for the current project’s <CONFIG> configuration. Targets imported from another project may not provide the same set of configuration names available in the current project. Setting this property tells CMake what imported configurations are suitable for use when building the <CONFIG> configuration. The first configuration in the list found to be provided by the imported target (i.e. via IMPORTED_LOCATION_<CONFIG> for the mapped-to <CONFIG>) is selected. As a special case, an empty list element refers to the configuration-less imported target location (i.e. IMPORTED_LOCATION).

If this property is set and no matching configurations are available, then the imported target is considered to be not found. This property is ignored for non-imported targets.

This property is initialized by the value of the CMAKE_MAP_IMPORTED_CONFIG_<CONFIG> variable if it is set when a target is created.

Example

For example creating imported C++ library foo:

add_library(foo STATIC IMPORTED)

Use foo_debug path for Debug build type:

set_property(
  TARGET foo APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG
  )

set_target_properties(foo PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
  IMPORTED_LOCATION_DEBUG "${foo_debug}"
  )

Use foo_release path for Release build type:

set_property(
  TARGET foo APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE
  )

set_target_properties(foo PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
  IMPORTED_LOCATION_RELEASE "${foo_release}"
  )

Use Release version of library for MinSizeRel and RelWithDebInfo build types:

set_target_properties(foo PROPERTIES
  MAP_IMPORTED_CONFIG_MINSIZEREL Release
  MAP_IMPORTED_CONFIG_RELWITHDEBINFO Release
  )

  • cmake-properties(7) »


NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

NAME

Logical name for the target.

Read-only logical name for the target as used by CMake.

  • cmake-properties(7) »


NO_SONAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

NO_SONAME

Whether to set “soname” when linking a shared library.

Enable this boolean property if a generated shared library should not have “soname” set. Default is to set “soname” on all shared libraries as long as the platform supports it. Generally, use this property only for leaf private libraries or plugins. If you use it on normal shared libraries which other targets link against, on some platforms a linker will insert a full path to the library (as specified at link time) into the dynamic section of the dependent binary. Therefore, once installed, dynamic loader may eventually fail to locate the library for the binary.

  • cmake-properties(7) »


NO_SYSTEM_FROM_IMPORTED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

NO_SYSTEM_FROM_IMPORTED

Do not treat include directories from the interfaces of consumed Imported Targets as SYSTEM.

The contents of the INTERFACE_INCLUDE_DIRECTORIES target property of imported targets are treated as SYSTEM includes by default. If this property is enabled on a target, compilation of sources in that target will not treat the contents of the INTERFACE_INCLUDE_DIRECTORIES of consumed imported targets as system includes.

This property is initialized by the value of the CMAKE_NO_SYSTEM_FROM_IMPORTED variable if it is set when a target is created.

  • cmake-properties(7) »


OSX_ARCHITECTURES_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

OSX_ARCHITECTURES_<CONFIG>

Per-configuration macOS and iOS binary architectures for a target.

This property is the configuration-specific version of OSX_ARCHITECTURES.

  • cmake-properties(7) »


OSX_ARCHITECTURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

OSX_ARCHITECTURES

Target specific architectures for macOS.

The OSX_ARCHITECTURES property sets the target binary architecture for targets on macOS (-arch). This property is initialized by the value of the variable CMAKE_OSX_ARCHITECTURES if it is set when a target is created. Use OSX_ARCHITECTURES_<CONFIG> to set the binary architectures on a per-configuration basis, where <CONFIG> is an upper-case name (e.g. OSX_ARCHITECTURES_DEBUG).

  • cmake-properties(7) »


OUTPUT_NAME_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

OUTPUT_NAME_<CONFIG>

Per-configuration target file base name.

This is the configuration-specific version of the OUTPUT_NAME target property.

  • cmake-properties(7) »


OUTPUT_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

OUTPUT_NAME

Output name for target files.

This sets the base name for output files created for an executable or library target. If not set, the logical target name is used by default during generation. The value is not set by default during configuration.

Contents of OUTPUT_NAME and the variants listed below may use generator expressions.

See also the variants:

  • OUTPUT_NAME_<CONFIG>
  • ARCHIVE_OUTPUT_NAME_<CONFIG>
  • ARCHIVE_OUTPUT_NAME
  • LIBRARY_OUTPUT_NAME_<CONFIG>
  • LIBRARY_OUTPUT_NAME
  • RUNTIME_OUTPUT_NAME_<CONFIG>
  • RUNTIME_OUTPUT_NAME

  • cmake-properties(7) »


PDB_NAME_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PDB_NAME_<CONFIG>

Per-configuration output name for the MS debug symbol .pdb file generated by the linker for an executable or shared library target.

This is the configuration-specific version of PDB_NAME.

Note

This property does not apply to STATIC library targets because no linker is invoked to produce them so they have no linker-generated .pdb file containing debug symbols.

The linker-generated program database files are specified by the /pdb linker flag and are not the same as compiler-generated program database files specified by the /Fd compiler flag. Use the COMPILE_PDB_NAME_<CONFIG> property to specify the latter.

  • cmake-properties(7) »


PDB_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PDB_NAME

Output name for the MS debug symbol .pdb file generated by the linker for an executable or shared library target.

This property specifies the base name for the debug symbols file. If not set, the OUTPUT_NAME target property value or logical target name is used by default.

Note

This property does not apply to STATIC library targets because no linker is invoked to produce them so they have no linker-generated .pdb file containing debug symbols.

The linker-generated program database files are specified by the /pdb linker flag and are not the same as compiler-generated program database files specified by the /Fd compiler flag. Use the COMPILE_PDB_NAME property to specify the latter.

  • cmake-properties(7) »


PDB_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PDB_OUTPUT_DIRECTORY_<CONFIG>

Per-configuration output directory for the MS debug symbol .pdb file generated by the linker for an executable or shared library target.

This is a per-configuration version of PDB_OUTPUT_DIRECTORY, but multi-configuration generators (VS, Xcode) do NOT append a per-configuration subdirectory to the specified directory. This property is initialized by the value of the CMAKE_PDB_OUTPUT_DIRECTORY_<CONFIG> variable if it is set when a target is created.

Contents of PDB_OUTPUT_DIRECTORY_<CONFIG> may use generator expressions.

Note

This property does not apply to STATIC library targets because no linker is invoked to produce them so they have no linker-generated .pdb file containing debug symbols.

The linker-generated program database files are specified by the /pdb linker flag and are not the same as compiler-generated program database files specified by the /Fd compiler flag. Use the COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG> property to specify the latter.

  • cmake-properties(7) »


PDB_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PDB_OUTPUT_DIRECTORY

Output directory for the MS debug symbols .pdb file generated by the linker for an executable or shared library target.

This property specifies the directory into which the MS debug symbols will be placed by the linker. The property value may use generator expressions. Multi-configuration generators append a per-configuration subdirectory to the specified directory unless a generator expression is used.

This property is initialized by the value of the CMAKE_PDB_OUTPUT_DIRECTORY variable if it is set when a target is created.

Note

This property does not apply to STATIC library targets because no linker is invoked to produce them so they have no linker-generated .pdb file containing debug symbols.

The linker-generated program database files are specified by the /pdb linker flag and are not the same as compiler-generated program database files specified by the /Fd compiler flag. Use the COMPILE_PDB_OUTPUT_DIRECTORY property to specify the latter.

  • cmake-properties(7) »


POSITION_INDEPENDENT_CODE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

POSITION_INDEPENDENT_CODE

Whether to create a position-independent target

The POSITION_INDEPENDENT_CODE property determines whether position independent executables or shared libraries will be created. This property is True by default for SHARED and MODULE library targets and False otherwise. This property is initialized by the value of the CMAKE_POSITION_INDEPENDENT_CODE variable if it is set when a target is created.

Note

For executable targets, the link step is controlled by the CMP0083 policy and the CheckPIESupported module.

  • cmake-properties(7) »


PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PREFIX

What comes before the library name.

A target property that can be set to override the prefix (such as “lib”) on a library name.

  • cmake-properties(7) »


PRIVATE_HEADER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PRIVATE_HEADER

Specify private header files in a FRAMEWORK shared library target.

Shared library targets marked with the FRAMEWORK property generate frameworks on macOS, iOS and normal shared libraries on other platforms. This property may be set to a list of header files to be placed in the PrivateHeaders directory inside the framework folder. On non-Apple platforms these headers may be installed using the PRIVATE_HEADER option to the install(TARGETS) command.

  • cmake-properties(7) »


PROJECT_LABEL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PROJECT_LABEL

Change the name of a target in an IDE.

Can be used to change the name of the target in an IDE like Visual Studio.

  • cmake-properties(7) »


PUBLIC_HEADER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PUBLIC_HEADER

Specify public header files in a FRAMEWORK shared library target.

Shared library targets marked with the FRAMEWORK property generate frameworks on macOS, iOS and normal shared libraries on other platforms. This property may be set to a list of header files to be placed in the Headers directory inside the framework folder. On non-Apple platforms these headers may be installed using the PUBLIC_HEADER option to the install(TARGETS) command.

  • cmake-properties(7) »


RESOURCE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RESOURCE

Specify resource files in a FRAMEWORK or BUNDLE.

Target marked with the FRAMEWORK or BUNDLE property generate framework or application bundle (both macOS and iOS is supported) or normal shared libraries on other platforms. This property may be set to a list of files to be placed in the corresponding directory (eg. Resources directory for macOS) inside the bundle. On non-Apple platforms these files may be installed using the RESOURCE option to the install(TARGETS) command.

Following example of Application Bundle:

add_executable(ExecutableTarget
  addDemo.c
  resourcefile.txt
  appresourcedir/appres.txt
)

target_link_libraries(ExecutableTarget heymath mul)

set(RESOURCE_FILES
  resourcefile.txt
  appresourcedir/appres.txt
)

set_target_properties(ExecutableTarget PROPERTIES
  MACOSX_BUNDLE TRUE
  MACOSX_FRAMEWORK_IDENTIFIER org.cmake.ExecutableTarget
  RESOURCE "${RESOURCE_FILES}"
)

will produce flat structure for iOS systems:

ExecutableTarget.app
  appres.txt
  ExecutableTarget
  Info.plist
  resourcefile.txt

For macOS systems it will produce following directory structure:

ExecutableTarget.app/
  Contents
    Info.plist
    MacOS
      ExecutableTarget
    Resources
      appres.txt
      resourcefile.txt

For Linux, such cmake script produce following files:

ExecutableTarget
Resources
  appres.txt
  resourcefile.txt

  • cmake-properties(7) »


RULE_LAUNCH_COMPILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_LAUNCH_COMPILE

Specify a launcher for compile rules.

See the global property of the same name for details. This overrides the global and directory property for a target.

  • cmake-properties(7) »


RULE_LAUNCH_CUSTOM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_LAUNCH_CUSTOM

Specify a launcher for custom rules.

See the global property of the same name for details. This overrides the global and directory property for a target.

  • cmake-properties(7) »


RULE_LAUNCH_LINK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RULE_LAUNCH_LINK

Specify a launcher for link rules.

See the global property of the same name for details. This overrides the global and directory property for a target.

  • cmake-properties(7) »


RUNTIME_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RUNTIME_OUTPUT_DIRECTORY_<CONFIG>

Per-configuration output directory for RUNTIME target files.

This is a per-configuration version of the RUNTIME_OUTPUT_DIRECTORY target property, but multi-configuration generators (VS, Xcode) do NOT append a per-configuration subdirectory to the specified directory. This property is initialized by the value of the CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG> variable if it is set when a target is created.

Contents of RUNTIME_OUTPUT_DIRECTORY_<CONFIG> may use generator expressions.

  • cmake-properties(7) »


RUNTIME_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RUNTIME_OUTPUT_DIRECTORY

Output directory in which to build RUNTIME target files.

This property specifies the directory into which runtime target files should be built. The property value may use generator expressions. Multi-configuration generators (VS, Xcode) append a per-configuration subdirectory to the specified directory unless a generator expression is used.

This property is initialized by the value of the variable CMAKE_RUNTIME_OUTPUT_DIRECTORY if it is set when a target is created.

See also the RUNTIME_OUTPUT_DIRECTORY_<CONFIG> target property.

  • cmake-properties(7) »


RUNTIME_OUTPUT_NAME_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RUNTIME_OUTPUT_NAME_<CONFIG>

Per-configuration output name for RUNTIME target files.

This is the configuration-specific version of the RUNTIME_OUTPUT_NAME target property.

  • cmake-properties(7) »


RUNTIME_OUTPUT_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RUNTIME_OUTPUT_NAME

Output name for RUNTIME target files.

This property specifies the base name for runtime target files. It overrides OUTPUT_NAME and OUTPUT_NAME_<CONFIG> properties.

See also the RUNTIME_OUTPUT_NAME_<CONFIG> target property.

  • cmake-properties(7) »


SKIP_BUILD_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SKIP_BUILD_RPATH

Should rpaths be used for the build tree.

SKIP_BUILD_RPATH is a boolean specifying whether to skip automatic generation of an rpath allowing the target to run from the build tree. This property is initialized by the value of the variable CMAKE_SKIP_BUILD_RPATH if it is set when a target is created.

  • cmake-properties(7) »


SOURCE_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SOURCE_DIR

This read-only property reports the value of the CMAKE_CURRENT_SOURCE_DIR variable in the directory in which the target was defined.

  • cmake-properties(7) »


SOURCES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SOURCES

Source names specified for a target.

List of sources specified for a target.

  • cmake-properties(7) »


SOVERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SOVERSION

What version number is this target.

For shared libraries VERSION and SOVERSION can be used to specify the build version and API version respectively. When building or installing appropriate symlinks are created if the platform supports symlinks and the linker supports so-names. If only one of both is specified the missing is assumed to have the same version number. SOVERSION is ignored if NO_SONAME property is set.

Windows Versions

For shared libraries and executables on Windows the VERSION attribute is parsed to extract a <major>.<minor> version number. These numbers are used as the image version of the binary.

Mach-O Versions

For shared libraries and executables on Mach-O systems (e.g. macOS, iOS), the SOVERSION property corresponds to compatibility version and VERSION to current version. See the FRAMEWORK target property for an example. Versions of Mach-O binaries may be checked with the otool -L <binary> command.

  • cmake-properties(7) »


STATIC_LIBRARY_FLAGS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

STATIC_LIBRARY_FLAGS_<CONFIG>

Per-configuration archiver (or MSVC librarian) flags for a static library target.

This is the configuration-specific version of STATIC_LIBRARY_FLAGS.

Note

This property has been superseded by STATIC_LIBRARY_OPTIONS property.

  • cmake-properties(7) »


STATIC_LIBRARY_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

STATIC_LIBRARY_FLAGS

Archiver (or MSVC librarian) flags for a static library target. Targets that are shared libraries, modules, or executables need to use the LINK_OPTIONS or LINK_FLAGS target properties.

The STATIC_LIBRARY_FLAGS property, managed as a string, can be used to add extra flags to the link step of a static library target. STATIC_LIBRARY_FLAGS_<CONFIG> will add to the configuration <CONFIG>, for example, DEBUG, RELEASE, MINSIZEREL, RELWITHDEBINFO, …

Note

This property has been superseded by STATIC_LIBRARY_OPTIONS property.

  • cmake-properties(7) »


STATIC_LIBRARY_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

STATIC_LIBRARY_OPTIONS

Archiver (or MSVC librarian) flags for a static library target. Targets that are shared libraries, modules, or executables need to use the LINK_OPTIONS target property.

This property holds a semicolon-separated list of options specified so far for its target. Use set_target_properties() or set_property() commands to set its content.

Contents of STATIC_LIBRARY_OPTIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Note

This property must be used in preference to STATIC_LIBRARY_FLAGS property.

  • cmake-properties(7) »


SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SUFFIX

What comes after the target name.

A target property that can be set to override the suffix (such as “.so” or “.exe”) on the name of a library, module or executable.

  • cmake-properties(7) »


TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TYPE

The type of the target.

This read-only property can be used to test the type of the given target. It will be one of STATIC_LIBRARY, MODULE_LIBRARY, SHARED_LIBRARY, OBJECT_LIBRARY, INTERFACE_LIBRARY, EXECUTABLE or one of the internal target types.

  • cmake-properties(7) »


VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VERSION

What version number is this target.

For shared libraries VERSION and SOVERSION can be used to specify the build version and API version respectively. When building or installing appropriate symlinks are created if the platform supports symlinks and the linker supports so-names. If only one of both is specified the missing is assumed to have the same version number. For executables VERSION can be used to specify the build version. When building or installing appropriate symlinks are created if the platform supports symlinks.

Windows Versions

For shared libraries and executables on Windows the VERSION attribute is parsed to extract a <major>.<minor> version number. These numbers are used as the image version of the binary.

Mach-O Versions

For shared libraries and executables on Mach-O systems (e.g. macOS, iOS), the SOVERSION property correspond to compatibility version and VERSION to current version. See the FRAMEWORK target property for an example. Versions of Mach-O binaries may be checked with the otool -L <binary> command.

  • cmake-properties(7) »


VISIBILITY_INLINES_HIDDEN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VISIBILITY_INLINES_HIDDEN

Whether to add a compile flag to hide symbols of inline functions

The VISIBILITY_INLINES_HIDDEN property determines whether a flag for hiding symbols for inline functions, such as -fvisibility-inlines-hidden, should be used when invoking the compiler. This property affects compilation in sources of all types of targets (subject to policy CMP0063).

This property is initialized by the value of the CMAKE_VISIBILITY_INLINES_HIDDEN variable if it is set when a target is created.

  • cmake-properties(7) »


VS_CONFIGURATION_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_CONFIGURATION_TYPE

Visual Studio project configuration type.

Sets the ConfigurationType attribute for a generated Visual Studio project. If this property is set, it overrides the default setting that is based on the target type (e.g. StaticLibrary, Application, …).

Supported on Visual Studio Generators for VS 2010 and higher.

  • cmake-properties(7) »


VS_DEBUGGER_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DEBUGGER_COMMAND

Sets the local debugger command for Visual Studio C++ targets. The property value may use generator expressions. This is defined in <LocalDebuggerCommand> in the Visual Studio project file.

This property only works for Visual Studio 2010 and above; it is ignored on other generators.

  • cmake-properties(7) »


VS_DEBUGGER_COMMAND_ARGUMENTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DEBUGGER_COMMAND_ARGUMENTS

Sets the local debugger command line arguments for Visual Studio C++ targets. The property value may use generator expressions. This is defined in <LocalDebuggerCommandArguments> in the Visual Studio project file.

This property only works for Visual Studio 2010 and above; it is ignored on other generators.

  • cmake-properties(7) »


VS_DEBUGGER_ENVIRONMENT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DEBUGGER_ENVIRONMENT

Sets the local debugger environment for Visual Studio C++ targets. The property value may use generator expressions. This is defined in <LocalDebuggerEnvironment> in the Visual Studio project file.

This property only works for Visual Studio 2010 and above; it is ignored on other generators.

  • cmake-properties(7) »


VS_DEBUGGER_WORKING_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DEBUGGER_WORKING_DIRECTORY

Sets the local debugger working directory for Visual Studio C++ targets. The property value may use generator expressions. This is defined in <LocalDebuggerWorkingDirectory> in the Visual Studio project file.

This property only works for Visual Studio 2010 and above; it is ignored on other generators.

  • cmake-properties(7) »


VS_DESKTOP_EXTENSIONS_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DESKTOP_EXTENSIONS_VERSION

Visual Studio Windows 10 Desktop Extensions Version

Specifies the version of the Desktop Extensions that should be included in the target. For example 10.0.10240.0. If the value is not specified, the Desktop Extensions will not be included. To use the same version of the extensions as the Windows 10 SDK that is being used, you can use the CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION variable.

  • cmake-properties(7) »


VS_DOTNET_REFERENCE_<refname> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DOTNET_REFERENCE_<refname>

Visual Studio managed project .NET reference with name <refname> and hint path.

Adds one .NET reference to generated Visual Studio project. The reference will have the name <refname> and will point to the assembly given as value of the property.

See also VS_DOTNET_REFERENCES and VS_DOTNET_REFERENCES_COPY_LOCAL

  • cmake-properties(7) »


VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname>

Defines an XML property <tagname> for a .NET reference <refname>.

Reference properties can be set for .NET references which are defined by the target properties VS_DOTNET_REFERENCES, VS_DOTNET_REFERENCE_<refname> and also for project references to other C# targets which are established by target_link_libraries().

This property is only applicable to C# targets and Visual Studio generators 2010 and later.

  • cmake-properties(7) »


VS_DOTNET_REFERENCES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DOTNET_REFERENCES

Visual Studio managed project .NET references

Adds one or more semicolon-delimited .NET references to a generated Visual Studio project. For example, “System;System.Windows.Forms”.

  • cmake-properties(7) »


VS_DOTNET_REFERENCES_COPY_LOCAL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DOTNET_REFERENCES_COPY_LOCAL

Sets the Copy Local property for all .NET hint references in the target

Boolean property to enable/disable copying of .NET hint references to output directory. The default is ON.

  • cmake-properties(7) »


VS_DOTNET_TARGET_FRAMEWORK_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DOTNET_TARGET_FRAMEWORK_VERSION

Specify the .NET target framework version.

Used to specify the .NET target framework version for C++/CLI. For example, “v4.5”.

This property is deprecated and should not be used anymore. Use DOTNET_TARGET_FRAMEWORK_VERSION instead.

  • cmake-properties(7) »


VS_GLOBAL_KEYWORD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_GLOBAL_KEYWORD

Visual Studio project keyword for VS 10 (2010) and newer.

Sets the “keyword” attribute for a generated Visual Studio project. Defaults to “Win32Proj”. You may wish to override this value with “ManagedCProj”, for example, in a Visual Studio managed C++ unit test project.

Use the VS_KEYWORD target property to set the keyword for Visual Studio 9 (2008) and older.

  • cmake-properties(7) »


VS_GLOBAL_PROJECT_TYPES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_GLOBAL_PROJECT_TYPES

Visual Studio project type(s).

Can be set to one or more UUIDs recognized by Visual Studio to indicate the type of project. This value is copied verbatim into the generated project file. Example for a managed C++ unit testing project:

{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}

UUIDs are semicolon-delimited.

  • cmake-properties(7) »


VS_GLOBAL_ROOTNAMESPACE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_GLOBAL_ROOTNAMESPACE

Visual Studio project root namespace.

Sets the “RootNamespace” attribute for a generated Visual Studio project. The attribute will be generated only if this is set.

  • cmake-properties(7) »


VS_GLOBAL_<variable> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_GLOBAL_<variable>

Visual Studio project-specific global variable.

Tell the Visual Studio generator to set the global variable ‘<variable>’ to a given value in the generated Visual Studio project. Ignored on other generators. Qt integration works better if VS_GLOBAL_QtVersion is set to the version FindQt4.cmake found. For example, “4.7.3”

  • cmake-properties(7) »


VS_IOT_EXTENSIONS_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_IOT_EXTENSIONS_VERSION

Visual Studio Windows 10 IoT Extensions Version

Specifies the version of the IoT Extensions that should be included in the target. For example 10.0.10240.0. If the value is not specified, the IoT Extensions will not be included. To use the same version of the extensions as the Windows 10 SDK that is being used, you can use the CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION variable.

  • cmake-properties(7) »


VS_IOT_STARTUP_TASK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_IOT_STARTUP_TASK

Visual Studio Windows 10 IoT Continuous Background Task

Specifies that the target should be compiled as a Continuous Background Task library.

  • cmake-properties(7) »


VS_KEYWORD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_KEYWORD

Visual Studio project keyword for VS 9 (2008) and older.

Can be set to change the visual studio keyword, for example Qt integration works better if this is set to Qt4VSv1.0.

Use the VS_GLOBAL_KEYWORD target property to set the keyword for Visual Studio 10 (2010) and newer.

  • cmake-properties(7) »


VS_MOBILE_EXTENSIONS_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_MOBILE_EXTENSIONS_VERSION

Visual Studio Windows 10 Mobile Extensions Version

Specifies the version of the Mobile Extensions that should be included in the target. For example 10.0.10240.0. If the value is not specified, the Mobile Extensions will not be included. To use the same version of the extensions as the Windows 10 SDK that is being used, you can use the CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION variable.

  • cmake-properties(7) »


VS_SCC_AUXPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SCC_AUXPATH

Visual Studio Source Code Control Aux Path.

Can be set to change the visual studio source code control auxpath property.

  • cmake-properties(7) »


VS_SCC_LOCALPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SCC_LOCALPATH

Visual Studio Source Code Control Local Path.

Can be set to change the visual studio source code control local path property.

  • cmake-properties(7) »


VS_SCC_PROJECTNAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SCC_PROJECTNAME

Visual Studio Source Code Control Project.

Can be set to change the visual studio source code control project name property.

  • cmake-properties(7) »


VS_SCC_PROVIDER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SCC_PROVIDER

Visual Studio Source Code Control Provider.

Can be set to change the visual studio source code control provider property.

  • cmake-properties(7) »


VS_SDK_REFERENCES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SDK_REFERENCES

Visual Studio project SDK references. Specify a semicolon-separated list of SDK references to be added to a generated Visual Studio project, e.g. Microsoft.AdMediatorWindows81, Version=1.0.

  • cmake-properties(7) »


VS_USER_PROPS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_USER_PROPS

Sets the user props file to be included in the visual studio C++ project file. The standard path is $(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props, which is in most cases the same as %LOCALAPPDATA%\\Microsoft\\MSBuild\\v4.0\\Microsoft.Cpp.Win32.user.props or %LOCALAPPDATA%\\Microsoft\\MSBuild\\v4.0\\Microsoft.Cpp.x64.user.props.

The *.user.props files can be used for Visual Studio wide configuration which is independent from cmake.

  • cmake-properties(7) »


VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION

Visual Studio Windows Target Platform Minimum Version

For Windows 10. Specifies the minimum version of the OS that is being targeted. For example 10.0.10240.0. If the value is not specified, the value of CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION will be used on WindowsStore projects otherwise the target platform minimum version will not be specified for the project.

  • cmake-properties(7) »


VS_WINRT_COMPONENT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_WINRT_COMPONENT

Mark a target as a Windows Runtime component for the Visual Studio generator. Compile the target with C++/CX language extensions for Windows Runtime. For SHARED and MODULE libraries, this also defines the _WINRT_DLL preprocessor macro.

Note

Currently this is implemented only by Visual Studio generators. Support may be added to other generators in the future.

  • cmake-properties(7) »


VS_WINRT_EXTENSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_WINRT_EXTENSIONS

Deprecated. Use VS_WINRT_COMPONENT instead. This property was an experimental partial implementation of that one.

  • cmake-properties(7) »


VS_WINRT_REFERENCES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_WINRT_REFERENCES

Visual Studio project Windows Runtime Metadata references

Adds one or more semicolon-delimited WinRT references to a generated Visual Studio project. For example, “Windows;Windows.UI.Core”.

  • cmake-properties(7) »


WIN32_EXECUTABLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

WIN32_EXECUTABLE

Build an executable with a WinMain entry point on windows.

When this property is set to true the executable when linked on Windows will be created with a WinMain() entry point instead of just main(). This makes it a GUI executable instead of a console application. See the CMAKE_MFC_FLAG variable documentation to configure use of the Microsoft Foundation Classes (MFC) for WinMain executables. This property is initialized by the value of the CMAKE_WIN32_EXECUTABLE variable if it is set when a target is created.

  • cmake-properties(7) »


WINDOWS_EXPORT_ALL_SYMBOLS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

WINDOWS_EXPORT_ALL_SYMBOLS

This property is implemented only for MS-compatible tools on Windows.

Enable this boolean property to automatically create a module definition (.def) file with all global symbols found in the input .obj files for a SHARED library (or executable with ENABLE_EXPORTS) on Windows. The module definition file will be passed to the linker causing all symbols to be exported from the .dll. For global data symbols, __declspec(dllimport) must still be used when compiling against the code in the .dll. All other function symbols will be automatically exported and imported by callers. This simplifies porting projects to Windows by reducing the need for explicit dllexport markup, even in C++ classes.

When this property is enabled, zero or more .def files may also be specified as source files of the target. The exports named by these files will be merged with those detected from the object files to generate a single module definition file to be passed to the linker. This can be used to export symbols from a .dll that are not in any of its object files but are added by the linker from dependencies (e.g. msvcrt.lib).

This property is initialized by the value of the CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS variable if it is set when a target is created.

  • cmake-properties(7) »


XCODE_ATTRIBUTE_<an-attribute> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_ATTRIBUTE_<an-attribute>

Set Xcode target attributes directly.

Tell the Xcode generator to set ‘<an-attribute>’ to a given value in the generated Xcode project. Ignored on other generators.

See the CMAKE_XCODE_ATTRIBUTE_<an-attribute> variable to set attributes on all targets in a directory tree.

Contents of XCODE_ATTRIBUTE_<an-attribute> may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-properties(7) »


XCODE_EXPLICIT_FILE_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_EXPLICIT_FILE_TYPE

Set the Xcode explicitFileType attribute on its reference to a target. CMake computes a default based on target type but can be told explicitly with this property.

See also XCODE_PRODUCT_TYPE.

  • cmake-properties(7) »


XCODE_PRODUCT_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_PRODUCT_TYPE

Set the Xcode productType attribute on its reference to a target. CMake computes a default based on target type but can be told explicitly with this property.

See also XCODE_EXPLICIT_FILE_TYPE.

  • cmake-properties(7) »


XCODE_SCHEME_ADDRESS_SANITIZER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_ADDRESS_SANITIZER

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_ARGUMENTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_ARGUMENTS

Specify command line arguments that should be added to the Arguments section of the generated Xcode scheme.

If set to a list of arguments those will be added to the scheme.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_ENVIRONMENT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_ENVIRONMENT

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.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_EXECUTABLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_EXECUTABLE

Specify path to executable in the Info section of the generated Xcode scheme. If not set the schema generator will select the current target if it is actually executable.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_GUARD_MALLOC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_GUARD_MALLOC

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_GUARD_MALLOC if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_MALLOC_GUARD_EDGES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_MALLOC_GUARD_EDGES

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_MALLOC_SCRIBBLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_MALLOC_SCRIBBLE

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_MALLOC_STACK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_MALLOC_STACK

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_MALLOC_STACK if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_THREAD_SANITIZER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_THREAD_SANITIZER

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_THREAD_SANITIZER if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_THREAD_SANITIZER_STOP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_THREAD_SANITIZER_STOP

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCODE_SCHEME_ZOMBIE_OBJECTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_SCHEME_ZOMBIE_OBJECTS

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

This property is initialized by the value of the variable CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS if it is set when a target is created.

Please refer to the CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-properties(7) »


XCTEST — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCTEST

This target is a XCTest CFBundle on the Mac.

This property will usually get set via the xctest_add_bundle() macro in FindXCTest module.

If a module library target has this property set to true it will be built as a CFBundle when built on the Mac. It will have the directory structure required for a CFBundle.

This property depends on BUNDLE to be effective.

  • cmake-properties(7) »


ATTACHED_FILES_ON_FAIL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ATTACHED_FILES_ON_FAIL

Attach a list of files to a dashboard submission if the test fails.

Same as ATTACHED_FILES, but these files will only be included if the test does not pass.

  • cmake-properties(7) »


ATTACHED_FILES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ATTACHED_FILES

Attach a list of files to a dashboard submission.

Set this property to a list of files that will be encoded and submitted to the dashboard as an addition to the test result.

  • cmake-properties(7) »


COST — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COST

Set this to a floating point value. Tests in a test set will be run in descending order of cost.

This property describes the cost of a test. You can explicitly set this value; tests with higher COST values will run first.

  • cmake-properties(7) »


DEPENDS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DEPENDS

Specifies that this test should only be run after the specified list of tests.

Set this to a list of tests that must finish before this test is run. The results of those tests are not considered, the dependency relationship is purely for order of execution (i.e. it is really just a run after relationship). Consider using test fixtures with setup tests if a dependency with successful completion is required (see FIXTURES_REQUIRED).

  • cmake-properties(7) »


DISABLED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

DISABLED

If set to true, the test will be skipped and its status will be ‘Not Run’. A DISABLED test will not be counted in the total number of tests and its completion status will be reported to CDash as ‘Disabled’.

A DISABLED test does not participate in test fixture dependency resolution. If a DISABLED test has fixture requirements defined in its FIXTURES_REQUIRED property, it will not cause setup or cleanup tests for those fixtures to be added to the test set.

If a test with the FIXTURES_SETUP property set is DISABLED, the fixture behavior will be as though that setup test was passing and any test case requiring that fixture will still run.

  • cmake-properties(7) »


ENVIRONMENT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ENVIRONMENT

Specify environment variables that should be defined for running a test.

If set to a list of environment variables and values of the form MYVAR=value those environment variables will be defined while running the test. The environment is restored to its previous state after the test is done.

  • cmake-properties(7) »


FAIL_REGULAR_EXPRESSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FAIL_REGULAR_EXPRESSION

If the output matches this regular expression the test will fail.

If set, if the output matches one of specified regular expressions, the test will fail. Example:

set_tests_properties(mytest PROPERTIES
  FAIL_REGULAR_EXPRESSION "[^a-z]Error;ERROR;Failed"
)

FAIL_REGULAR_EXPRESSION expects a list of regular expressions.

  • cmake-properties(7) »


FIXTURES_CLEANUP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FIXTURES_CLEANUP

Specifies a list of fixtures for which the test is to be treated as a cleanup test. These fixture names are distinct from test case names and are not required to have any similarity to the names of tests associated with them.

Fixture cleanup tests are ordinary tests with all of the usual test functionality. Setting the FIXTURES_CLEANUP property for a test has two primary effects:

  • CTest will ensure the test executes after all other tests which list any of the fixtures in its FIXTURES_REQUIRED property.
  • If CTest is asked to run only a subset of tests (e.g. using regular expressions or the --rerun-failed option) and the cleanup test is not in the set of tests to run, it will automatically be added if any tests in the set require any fixture listed in FIXTURES_CLEANUP.

A cleanup test can have multiple fixtures listed in its FIXTURES_CLEANUP property. It will execute only once for the whole CTest run, not once for each fixture. A fixture can also have more than one cleanup test defined. If there are multiple cleanup tests for a fixture, projects can control their order with the usual DEPENDS test property if necessary.

A cleanup test is allowed to require other fixtures, but not any fixture listed in its FIXTURES_CLEANUP property. For example:

# Ok: Dependent fixture is different to cleanup
set_tests_properties(cleanupFoo PROPERTIES
  FIXTURES_CLEANUP  Foo
  FIXTURES_REQUIRED Bar
)

# Error: cannot require same fixture as cleanup
set_tests_properties(cleanupFoo PROPERTIES
  FIXTURES_CLEANUP  Foo
  FIXTURES_REQUIRED Foo
)

Cleanup tests will execute even if setup or regular tests for that fixture fail or are skipped.

See FIXTURES_REQUIRED for a more complete discussion of how to use test fixtures.

  • cmake-properties(7) »


FIXTURES_REQUIRED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FIXTURES_REQUIRED

Specifies a list of fixtures the test requires. Fixture names are case sensitive and they are not required to have any similarity to test names.

Fixtures are a way to attach setup and cleanup tasks to a set of tests. If a test requires a given fixture, then all tests marked as setup tasks for that fixture will be executed first (once for the whole set of tests, not once per test requiring the fixture). After all tests requiring a particular fixture have completed, CTest will ensure all tests marked as cleanup tasks for that fixture are then executed. Tests are marked as setup tasks with the FIXTURES_SETUP property and as cleanup tasks with the FIXTURES_CLEANUP property. If any of a fixture’s setup tests fail, all tests listing that fixture in their FIXTURES_REQUIRED property will not be executed. The cleanup tests for the fixture will always be executed, even if some setup tests fail.

When CTest is asked to execute only a subset of tests (e.g. by the use of regular expressions or when run with the --rerun-failed command line option), it will automatically add any setup or cleanup tests for fixtures required by any of the tests that are in the execution set. This behavior can be overridden with the -FS, -FC and -FA command line options to ctest(1) if desired.

Since setup and cleanup tasks are also tests, they can have an ordering specified by the DEPENDS test property just like any other tests. This can be exploited to implement setup or cleanup using multiple tests for a single fixture to modularise setup or cleanup logic.

The concept of a fixture is different to that of a resource specified by RESOURCE_LOCK, but they may be used together. A fixture defines a set of tests which share setup and cleanup requirements, whereas a resource lock has the effect of ensuring a particular set of tests do not run in parallel. Some situations may need both, such as setting up a database, serialising test access to that database and deleting the database again at the end. For such cases, tests would populate both FIXTURES_REQUIRED and RESOURCE_LOCK to combine the two behaviours. Names used for RESOURCE_LOCK have no relationship with names of fixtures, so note that a resource lock does not imply a fixture and vice versa.

Consider the following example which represents a database test scenario similar to that mentioned above:

add_test(NAME testsDone   COMMAND emailResults)
add_test(NAME fooOnly     COMMAND testFoo)
add_test(NAME dbOnly      COMMAND testDb)
add_test(NAME dbWithFoo   COMMAND testDbWithFoo)
add_test(NAME createDB    COMMAND initDB)
add_test(NAME setupUsers  COMMAND userCreation)
add_test(NAME cleanupDB   COMMAND deleteDB)
add_test(NAME cleanupFoo  COMMAND removeFoos)

set_tests_properties(setupUsers PROPERTIES DEPENDS createDB)

set_tests_properties(createDB   PROPERTIES FIXTURES_SETUP    DB)
set_tests_properties(setupUsers PROPERTIES FIXTURES_SETUP    DB)
set_tests_properties(cleanupDB  PROPERTIES FIXTURES_CLEANUP  DB)
set_tests_properties(cleanupFoo PROPERTIES FIXTURES_CLEANUP  Foo)
set_tests_properties(testsDone  PROPERTIES FIXTURES_CLEANUP  "DB;Foo")

set_tests_properties(fooOnly    PROPERTIES FIXTURES_REQUIRED Foo)
set_tests_properties(dbOnly     PROPERTIES FIXTURES_REQUIRED DB)
set_tests_properties(dbWithFoo  PROPERTIES FIXTURES_REQUIRED "DB;Foo")

set_tests_properties(dbOnly dbWithFoo createDB setupUsers cleanupDB
                     PROPERTIES RESOURCE_LOCK DbAccess)

Key points from this example:

  • Two fixtures are defined: DB and Foo. Tests can require a single fixture as fooOnly and dbOnly do, or they can depend on multiple fixtures like dbWithFoo does.
  • A DEPENDS relationship is set up to ensure setupUsers happens after createDB, both of which are setup tests for the DB fixture and will therefore be executed before the dbOnly and dbWithFoo tests automatically.
  • No explicit DEPENDS relationships were needed to make the setup tests run before or the cleanup tests run after the regular tests.
  • The Foo fixture has no setup tests defined, only a single cleanup test.
  • testsDone is a cleanup test for both the DB and Foo fixtures. Therefore, it will only execute once regular tests for both fixtures have finished (i.e. after fooOnly, dbOnly and dbWithFoo). No DEPENDS relationship was specified for testsDone, so it is free to run before, after or concurrently with other cleanup tests for either fixture.
  • The setup and cleanup tests never list the fixtures they are for in their own FIXTURES_REQUIRED property, as that would result in a dependency on themselves and be considered an error.

  • cmake-properties(7) »


FIXTURES_SETUP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

FIXTURES_SETUP

Specifies a list of fixtures for which the test is to be treated as a setup test. These fixture names are distinct from test case names and are not required to have any similarity to the names of tests associated with them.

Fixture setup tests are ordinary tests with all of the usual test functionality. Setting the FIXTURES_SETUP property for a test has two primary effects:

  • CTest will ensure the test executes before any other test which lists the fixture name(s) in its FIXTURES_REQUIRED property.
  • If CTest is asked to run only a subset of tests (e.g. using regular expressions or the --rerun-failed option) and the setup test is not in the set of tests to run, it will automatically be added if any tests in the set require any fixture listed in FIXTURES_SETUP.

A setup test can have multiple fixtures listed in its FIXTURES_SETUP property. It will execute only once for the whole CTest run, not once for each fixture. A fixture can also have more than one setup test defined. If there are multiple setup tests for a fixture, projects can control their order with the usual DEPENDS test property if necessary.

A setup test is allowed to require other fixtures, but not any fixture listed in its FIXTURES_SETUP property. For example:

# Ok: dependent fixture is different to setup
set_tests_properties(setupFoo PROPERTIES
  FIXTURES_SETUP    Foo
  FIXTURES_REQUIRED Bar
)

# Error: cannot require same fixture as setup
set_tests_properties(setupFoo PROPERTIES
  FIXTURES_SETUP    Foo
  FIXTURES_REQUIRED Foo
)

If any of a fixture’s setup tests fail, none of the tests listing that fixture in its FIXTURES_REQUIRED property will be run. Cleanup tests will, however, still be executed.

See FIXTURES_REQUIRED for a more complete discussion of how to use test fixtures.

  • cmake-properties(7) »


LABELS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LABELS

Specify a list of text labels associated with a test.

The list is reported in dashboard submissions.

  • cmake-properties(7) »


MEASUREMENT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MEASUREMENT

Specify a CDASH measurement and value to be reported for a test.

If set to a name then that name will be reported to CDASH as a named measurement with a value of 1. You may also specify a value by setting MEASUREMENT to “measurement=value”.

  • cmake-properties(7) »


PASS_REGULAR_EXPRESSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PASS_REGULAR_EXPRESSION

The output must match this regular expression for the test to pass.

If set, the test output will be checked against the specified regular expressions and at least one of the regular expressions has to match, otherwise the test will fail. Example:

set_tests_properties(mytest PROPERTIES
  PASS_REGULAR_EXPRESSION "TestPassed;All ok"
)

PASS_REGULAR_EXPRESSION expects a list of regular expressions.

  • cmake-properties(7) »


PROCESSOR_AFFINITY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PROCESSOR_AFFINITY

Set to a true value to ask CTest to launch the test process with CPU affinity for a fixed set of processors. If enabled and supported for the current platform, CTest will choose a set of processors to place in the CPU affinity mask when launching the test process. The number of processors in the set is determined by the PROCESSORS test property or the number of processors available to CTest, whichever is smaller. The set of processors chosen will be disjoint from the processors assigned to other concurrently running tests that also have the PROCESSOR_AFFINITY property enabled.

  • cmake-properties(7) »


PROCESSORS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PROCESSORS

Set to specify how many process slots this test requires. If not set, the default is 1 processor.

Denotes the number of processors that this test will require. This is typically used for MPI tests, and should be used in conjunction with the ctest_test() PARALLEL_LEVEL option.

This will also be used to display a weighted test timing result in label and subproject summaries in the command line output of ctest(1). The wall clock time for the test run will be multiplied by this property to give a better idea of how much cpu resource CTest allocated for the test.

See also the PROCESSOR_AFFINITY test property.

  • cmake-properties(7) »


REQUIRED_FILES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

REQUIRED_FILES

List of files required to run the test.

If set to a list of files, the test will not be run unless all of the files exist.

  • cmake-properties(7) »


RESOURCE_LOCK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RESOURCE_LOCK

Specify a list of resources that are locked by this test.

If multiple tests specify the same resource lock, they are guaranteed not to run concurrently.

See also FIXTURES_REQUIRED if the resource requires any setup or cleanup steps.

  • cmake-properties(7) »


RUN_SERIAL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

RUN_SERIAL

Do not run this test in parallel with any other test.

Use this option in conjunction with the ctest_test PARALLEL_LEVEL option to specify that this test should not be run in parallel with any other tests.

  • cmake-properties(7) »


SKIP_RETURN_CODE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SKIP_RETURN_CODE

Return code to mark a test as skipped.

Sometimes only a test itself can determine if all requirements for the test are met. If such a situation should not be considered a hard failure a return code of the process can be specified that will mark the test as “Not Run” if it is encountered.

  • cmake-properties(7) »


TIMEOUT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TIMEOUT

How many seconds to allow for this test.

This property if set will limit a test to not take more than the specified number of seconds to run. If it exceeds that the test process will be killed and ctest will move to the next test. This setting takes precedence over CTEST_TEST_TIMEOUT.

  • cmake-properties(7) »


TIMEOUT_AFTER_MATCH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TIMEOUT_AFTER_MATCH

Change a test’s timeout duration after a matching line is encountered in its output.

Usage

add_test(mytest ...)
set_property(TEST mytest PROPERTY TIMEOUT_AFTER_MATCH "${seconds}" "${regex}")

Description

Allow a test seconds to complete after regex is encountered in its output.

When the test outputs a line that matches regex its start time is reset to the current time and its timeout duration is changed to seconds. Prior to this, the timeout duration is determined by the TIMEOUT property or the CTEST_TEST_TIMEOUT variable if either of these are set. Because the test’s start time is reset, its execution time will not include any time that was spent waiting for the matching output.

TIMEOUT_AFTER_MATCH is useful for avoiding spurious timeouts when your test must wait for some system resource to become available before it can execute. Set TIMEOUT to a longer duration that accounts for resource acquisition and use TIMEOUT_AFTER_MATCH to control how long the actual test is allowed to run.

If the required resource can be controlled by CTest you should use RESOURCE_LOCK instead of TIMEOUT_AFTER_MATCH. This property should be used when only the test itself can determine when its required resources are available.

  • cmake-properties(7) »


WILL_FAIL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

WILL_FAIL

If set to true, this will invert the pass/fail flag of the test.

This property can be used for tests that are expected to fail and return a non zero return code.

  • cmake-properties(7) »


WORKING_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

WORKING_DIRECTORY

The directory from which the test executable will be called.

If this is not set, the test will be run with the working directory set to the binary directory associated with where the test was created (i.e. the CMAKE_CURRENT_BINARY_DIR for where add_test() was called).

  • cmake-properties(7) »


ABSTRACT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ABSTRACT

Is this source file an abstract class.

A property on a source file that indicates if the source file represents a class that is abstract. This only makes sense for languages that have a notion of an abstract class and it is only used by some tools that wrap classes into other languages.

  • cmake-properties(7) »


AUTOUIC_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTOUIC_OPTIONS

Additional options for uic when using AUTOUIC

This property holds additional command line options which will be used when uic is executed during the build via AUTOUIC, i.e. it is equivalent to the optional OPTIONS argument of the qt4_wrap_ui() macro.

By default it is empty.

The options set on the .ui source file may override AUTOUIC_OPTIONS set on the target.

EXAMPLE

# ...
set_property(SOURCE widget.ui PROPERTY AUTOUIC_OPTIONS "--no-protection")
# ...

  • cmake-properties(7) »


AUTORCC_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

AUTORCC_OPTIONS

Additional options for rcc when using AUTORCC

This property holds additional command line options which will be used when rcc is executed during the build via AUTORCC, i.e. it is equivalent to the optional OPTIONS argument of the qt4_add_resources() macro.

By default it is empty.

The options set on the .qrc source file may override AUTORCC_OPTIONS set on the target.

EXAMPLE

# ...
set_property(SOURCE resources.qrc PROPERTY AUTORCC_OPTIONS "--compress;9")
# ...

  • cmake-properties(7) »


COMPILE_DEFINITIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_DEFINITIONS

Preprocessor definitions for compiling a source file.

The COMPILE_DEFINITIONS property may be set to a semicolon-separated list of preprocessor definitions using the syntax VAR or VAR=value. Function-style definitions are not supported. CMake will automatically escape the value correctly for the native build system (note that CMake language syntax may require escapes to specify some values). This property may be set on a per-configuration basis using the name COMPILE_DEFINITIONS_<CONFIG> where <CONFIG> is an upper-case name (ex. “COMPILE_DEFINITIONS_DEBUG”).

CMake will automatically drop some definitions that are not supported by the native build tool. Xcode does not support per-configuration definitions on source files.

Disclaimer: Most native build tools have poor support for escaping certain values. CMake has work-arounds for many cases but some values may just not be possible to pass correctly. If a value does not seem to be escaped correctly, do not attempt to work-around the problem by adding escape sequences to the value. Your work-around may break in a future version of CMake that has improved escape support. Instead consider defining the macro in a (configured) header file. Then report the limitation. Known limitations include:

#          - broken almost everywhere
;          - broken in VS IDE 7.0 and Borland Makefiles
,          - broken in VS IDE
%          - broken in some cases in NMake
& |        - broken in some cases on MinGW
^ < > \"   - broken in most Make tools on Windows

CMake does not reject these values outright because they do work in some cases. Use with caution.

Contents of COMPILE_DEFINITIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. However, Xcode does not support per-config per-source settings, so expressions that depend on the build configuration are not allowed with that generator.

Generator expressions should be preferred instead of setting the alternative per-configuration property.

  • cmake-properties(7) »


COMPILE_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_FLAGS

Additional flags to be added when compiling this source file.

The COMPILE_FLAGS property, managed as a string, sets additional compiler flags used to build source files. Use COMPILE_DEFINITIONS to pass additional preprocessor definitions.

Contents of COMPILE_FLAGS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. However, Xcode does not support per-config per-source settings, so expressions that depend on the build configuration are not allowed with that generator.

Note

This property has been superseded by the COMPILE_OPTIONS property.

  • cmake-properties(7) »


COMPILE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_OPTIONS

List of additional options to pass to the compiler.

This property holds a semicolon-separated list of options and will be added to the list of compile flags when this source file builds. Use COMPILE_DEFINITIONS to pass additional preprocessor definitions and INCLUDE_DIRECTORIES to pass additional include directories.

Contents of COMPILE_OPTIONS may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. However, Xcode does not support per-config per-source settings, so expressions that depend on the build configuration are not allowed with that generator.

Note

This property should be preferred over the COMPILE_FLAGS property.

  • cmake-properties(7) »


EXTERNAL_OBJECT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

EXTERNAL_OBJECT

If set to true then this is an object file.

If this property is set to true then the source file is really an object file and should not be compiled. It will still be linked into the target though.

  • cmake-properties(7) »


Fortran_FORMAT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

Fortran_FORMAT

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

This property tells CMake whether a given Fortran source file uses fixed-format or free-format. CMake will pass the corresponding format flag to the compiler. Consider using the target-wide Fortran_FORMAT property if all source files in a target share the same format.

  • cmake-properties(7) »


GENERATED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

GENERATED

Is this source file generated as part of the build or CMake process.

Tells the internal CMake engine that a source file is generated by an outside process such as another build step, or the execution of CMake itself. This information is then used to exempt the file from any existence or validity checks. Generated files are created by the execution of commands such as add_custom_command() and file(GENERATE).

When a generated file created by an add_custom_command() command is explicitly listed as a source file for any target in the same directory scope (which usually means the same CMakeLists.txt file), CMake will automatically create a dependency to make sure the file is generated before building that target.

Generated sources may be hidden in some IDE tools, while in others they might be shown. For the special case of sources generated by CMake’s AUTOMOC or AUTORCC functionality, the AUTOGEN_SOURCE_GROUP, AUTOMOC_SOURCE_GROUP and AUTORCC_SOURCE_GROUP target properties may influence where the generated sources are grouped in the project’s file lists.

  • cmake-properties(7) »


HEADER_FILE_ONLY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

HEADER_FILE_ONLY

Is this source file only a header file.

A property on a source file that indicates if the source file is a header file with no associated implementation. This is set automatically based on the file extension and is used by CMake to determine if certain dependency information should be computed.

By setting this property to ON, you can disable compilation of the given source file, even if it should be compiled because it is part of the library’s/executable’s sources.

This is useful if you have some source files which you somehow pre-process, and then add these pre-processed sources via add_library() or add_executable(). Normally, in IDE, there would be no reference of the original sources, only of these pre-processed sources. So by setting this property for all the original source files to ON, and then either calling add_library() or add_executable() while passing both the pre-processed sources and the original sources, or by using target_sources() to add original source files will do exactly what would one expect, i.e. the original source files would be visible in IDE, and will not be built.

  • cmake-properties(7) »


INCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

INCLUDE_DIRECTORIES

List of preprocessor include file search directories.

This property holds a semicolon-separated list of paths and will be added to the list of include directories when this source file builds. These directories will take precedence over directories defined at target level except for Xcode generator due to technical limitations.

Relative paths should not be added to this property directly.

Contents of INCLUDE_DIRECTORIES may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. However, Xcode does not support per-config per-source settings, so expressions that depend on the build configuration are not allowed with that generator.

  • cmake-properties(7) »


KEEP_EXTENSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

KEEP_EXTENSION

Make the output file have the same extension as the source file.

If this property is set then the file extension of the output file will be the same as that of the source file. Normally the output file extension is computed based on the language of the source file, for example .cxx will go to a .o extension.

  • cmake-properties(7) »


LABELS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LABELS

Specify a list of text labels associated with a source file.

This property has meaning only when the source file is listed in a target whose LABELS property is also set. No other semantics are currently specified.

  • cmake-properties(7) »


LANGUAGE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LANGUAGE

What programming language is the file.

A property that can be set to indicate what programming language the source file is. If it is not set the language is determined based on the file extension. Typical values are CXX C etc. Setting this property for a file means this file will be compiled. Do not set this for headers or files that should not be compiled.

  • cmake-properties(7) »


LOCATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

LOCATION

The full path to a source file.

A read only property on a SOURCE FILE that contains the full path to the source file.

  • cmake-properties(7) »


MACOSX_PACKAGE_LOCATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MACOSX_PACKAGE_LOCATION

Place a source file inside a Application Bundle ( MACOSX_BUNDLE), Core Foundation Bundle ( BUNDLE), or Framework Bundle ( FRAMEWORK). It is applicable for macOS and iOS.

Executable targets with the MACOSX_BUNDLE property set are built as macOS or iOS application bundles on Apple platforms. Shared library targets with the FRAMEWORK property set are built as macOS or iOS frameworks on Apple platforms. Module library targets with the BUNDLE property set are built as macOS CFBundle bundles on Apple platforms. Source files listed in the target with this property set will be copied to a directory inside the bundle or framework content folder specified by the property value. For macOS Application Bundles the content folder is <name>.app/Contents. For macOS Frameworks the content folder is <name>.framework/Versions/<version>. For macOS CFBundles the content folder is <name>.bundle/Contents (unless the extension is changed). See the PUBLIC_HEADER, PRIVATE_HEADER, and RESOURCE target properties for specifying files meant for Headers, PrivateHeaders, or Resources directories.

If the specified location is equal to Resources, the resulting location will be the same as if the RESOURCE property had been used. If the specified location is a sub-folder of Resources, it will be placed into the respective sub-folder. Note: For iOS Apple uses a flat bundle layout where no Resources folder exist. Therefore CMake strips the Resources folder name from the specified location.

  • cmake-properties(7) »


OBJECT_DEPENDS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

OBJECT_DEPENDS

Additional files on which a compiled object file depends.

Specifies a semicolon-separated list of full-paths to files on which any object files compiled from this source file depend. On Makefile Generators and the Ninja generator an object file will be recompiled if any of the named files is newer than it. Visual Studio Generators and the Xcode generator cannot implement such compilation dependencies.

This property need not be used to specify the dependency of a source file on a generated header file that it includes. Although the property was originally introduced for this purpose, it is no longer necessary. If the generated header file is created by a custom command in the same target as the source file, the automatic dependency scanning process will recognize the dependency. If the generated header file is created by another target, an inter-target dependency should be created with the add_dependencies() command (if one does not already exist due to linking relationships).

  • cmake-properties(7) »


OBJECT_OUTPUTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

OBJECT_OUTPUTS

Additional outputs for a Makefile rule.

Additional outputs created by compilation of this source file. If any of these outputs is missing the object will be recompiled. This is supported only on Makefile generators and will be ignored on other generators.

  • cmake-properties(7) »


SKIP_AUTOGEN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SKIP_AUTOGEN

Exclude the source file from AUTOMOC, AUTOUIC and AUTORCC processing (for Qt projects).

For finer exclusion control see SKIP_AUTOMOC, SKIP_AUTOUIC and SKIP_AUTORCC.

EXAMPLE

# ...
set_property(SOURCE file.h PROPERTY SKIP_AUTOGEN ON)
# ...

  • cmake-properties(7) »


SKIP_AUTOMOC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SKIP_AUTOMOC

Exclude the source file from AUTOMOC processing (for Qt projects).

For broader exclusion control see SKIP_AUTOGEN.

EXAMPLE

# ...
set_property(SOURCE file.h PROPERTY SKIP_AUTOMOC ON)
# ...

  • cmake-properties(7) »


SKIP_AUTORCC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SKIP_AUTORCC

Exclude the source file from AUTORCC processing (for Qt projects).

For broader exclusion control see SKIP_AUTOGEN.

EXAMPLE

# ...
set_property(SOURCE file.qrc PROPERTY SKIP_AUTORCC ON)
# ...

  • cmake-properties(7) »


SKIP_AUTOUIC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SKIP_AUTOUIC

Exclude the source file from AUTOUIC processing (for Qt projects).

SKIP_AUTOUIC can be set on C++ header and source files and on .ui files.

For broader exclusion control see SKIP_AUTOGEN.

EXAMPLE

# ...
set_property(SOURCE file.h PROPERTY SKIP_AUTOUIC ON)
set_property(SOURCE file.cpp PROPERTY SKIP_AUTOUIC ON)
set_property(SOURCE widget.ui PROPERTY SKIP_AUTOUIC ON)
# ...

  • cmake-properties(7) »


SYMBOLIC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

SYMBOLIC

Is this just a name for a rule.

If SYMBOLIC (boolean) is set to true the build system will be informed that the source file is not actually created on disk but instead used as a symbolic name for a build rule.

  • cmake-properties(7) »


VS_COPY_TO_OUT_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_COPY_TO_OUT_DIR

Sets the <CopyToOutputDirectory> tag for a source file in a Visual Studio project file. Valid values are Never, Always and PreserveNewest.

  • cmake-properties(7) »


VS_CSHARP_<tagname> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_CSHARP_<tagname>

Visual Studio and CSharp source-file-specific configuration.

Tell the Visual Studio generator to set the source file tag <tagname> to a given value in the generated Visual Studio CSharp project. Ignored on other generators and languages. This property can be used to define dependencies between source files or set any other Visual Studio specific parameters.

Example usage:

set_source_files_property(<filename>
         PROPERTIES
         VS_CSHARP_DependentUpon <other file>
         VS_CSHARP_SubType "Form")

  • cmake-properties(7) »


VS_DEPLOYMENT_CONTENT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DEPLOYMENT_CONTENT

Mark a source file as content for deployment with a Windows Phone or Windows Store application when built with a Visual Studio generator. The value must evaluate to either 1 or 0 and may use generator expressions to make the choice based on the build configuration. The .vcxproj file entry for the source file will be marked either DeploymentContent or ExcludedFromBuild for values 1 and 0, respectively.

  • cmake-properties(7) »


VS_DEPLOYMENT_LOCATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_DEPLOYMENT_LOCATION

Specifies the deployment location for a content source file with a Windows Phone or Windows Store application when built with a Visual Studio generator. This property is only applicable when using VS_DEPLOYMENT_CONTENT. The value represent the path relative to the app package and applies to all configurations.

  • cmake-properties(7) »


VS_INCLUDE_IN_VSIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_INCLUDE_IN_VSIX

Boolean property to specify if the file should be included within a VSIX extension package. This is needed for development of Visual Studio extensions.

  • cmake-properties(7) »


VS_RESOURCE_GENERATOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_RESOURCE_GENERATOR

This property allows to specify the resource generator to be used on this file. It defaults to PublicResXFileCodeGenerator if not set.

This property only applies to C# projects.

  • cmake-properties(7) »


VS_SHADER_DISABLE_OPTIMIZATIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SHADER_DISABLE_OPTIMIZATIONS

Disable compiler optimizations for an .hlsl source file. This adds the -Od flag to the command line for the FxCompiler tool. Specify the value true for this property to disable compiler optimizations.

  • cmake-properties(7) »


VS_SHADER_ENABLE_DEBUG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SHADER_ENABLE_DEBUG

Enable debugging information for an .hlsl source file. This adds the -Zi flag to the command line for the FxCompiler tool. Specify the value true to generate debugging information for the compiled shader.

  • cmake-properties(7) »


VS_SHADER_ENTRYPOINT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SHADER_ENTRYPOINT

Specifies the name of the entry point for the shader of a .hlsl source file.

  • cmake-properties(7) »


VS_SHADER_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SHADER_FLAGS

Set additional VS shader flags of a .hlsl source file.

  • cmake-properties(7) »


VS_SHADER_MODEL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SHADER_MODEL

Specifies the shader model of a .hlsl source file. Some shader types can only be used with recent shader models

  • cmake-properties(7) »


VS_SHADER_OBJECT_FILE_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SHADER_OBJECT_FILE_NAME

Specifies a file name for the compiled shader object file for an .hlsl source file. This adds the -Fo flag to the command line for the FxCompiler tool.

  • cmake-properties(7) »


VS_SHADER_OUTPUT_HEADER_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SHADER_OUTPUT_HEADER_FILE

Set filename for output header file containing object code of a .hlsl source file.

  • cmake-properties(7) »


VS_SHADER_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SHADER_TYPE

Set the VS shader type of a .hlsl source file.

  • cmake-properties(7) »


VS_SHADER_VARIABLE_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_SHADER_VARIABLE_NAME

Set name of variable in header file containing object code of a .hlsl source file.

  • cmake-properties(7) »


VS_TOOL_OVERRIDE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_TOOL_OVERRIDE

Override the default Visual Studio tool that will be applied to the source file with a new tool not based on the extension of the file.

  • cmake-properties(7) »


VS_XAML_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VS_XAML_TYPE

Mark a XAML source file as a different type than the default Page. The most common usage would be to set the default App.xaml file as ApplicationDefinition.

  • cmake-properties(7) »


WRAP_EXCLUDE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

WRAP_EXCLUDE

Exclude this source file from any code wrapping techniques.

Some packages can wrap source files into alternate languages to provide additional functionality. For example, C++ code can be wrapped into Java or Python etc using SWIG etc. If WRAP_EXCLUDE is set to true (1 etc) that indicates that this source file should not be wrapped.

  • cmake-properties(7) »


XCODE_EXPLICIT_FILE_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_EXPLICIT_FILE_TYPE

Set the Xcode explicitFileType attribute on its reference to a source file. CMake computes a default based on file extension but can be told explicitly with this property.

See also XCODE_LAST_KNOWN_FILE_TYPE.

  • cmake-properties(7) »


XCODE_FILE_ATTRIBUTES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_FILE_ATTRIBUTES

Add values to the Xcode ATTRIBUTES setting on its reference to a source file. Among other things, this can be used to set the role on a mig file:

set_source_files_properties(defs.mig
    PROPERTIES
        XCODE_FILE_ATTRIBUTES "Client;Server"
)

  • cmake-properties(7) »


XCODE_LAST_KNOWN_FILE_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

XCODE_LAST_KNOWN_FILE_TYPE

Set the Xcode lastKnownFileType attribute on its reference to a source file. CMake computes a default based on file extension but can be told explicitly with this property.

See also XCODE_EXPLICIT_FILE_TYPE, which is preferred over this property if set.

  • cmake-properties(7) »


ADVANCED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

ADVANCED

True if entry should be hidden by default in GUIs.

This is a boolean value indicating whether the entry is considered interesting only for advanced configuration. The mark_as_advanced() command modifies this property.

  • cmake-properties(7) »


HELPSTRING — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

HELPSTRING

Help associated with entry in GUIs.

This string summarizes the purpose of an entry to help users set it through a CMake GUI.

  • cmake-properties(7) »


MODIFIED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

MODIFIED

Internal management property. Do not set or get.

This is an internal cache entry property managed by CMake to track interactive user modification of entries. Ignore it.

  • cmake-properties(7) »


STRINGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

STRINGS

Enumerate possible STRING entry values for GUI selection.

For cache entries with type STRING, this enumerates a set of values. CMake GUIs may use this to provide a selection widget instead of a generic string entry field. This is for convenience only. CMake does not enforce that the value matches one of those listed.

  • cmake-properties(7) »


TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TYPE

Widget type for entry in GUIs.

Cache entry values are always strings, but CMake GUIs present widgets to help users set values. The GUIs use this property as a hint to determine the widget type. Valid TYPE values are:

BOOL          = Boolean ON/OFF value.
PATH          = Path to a directory.
FILEPATH      = Path to a file.
STRING        = Generic string value.
INTERNAL      = Do not present in GUI at all.
STATIC        = Value managed by CMake, do not change.
UNINITIALIZED = Type not yet specified.

Generally the TYPE of a cache entry should be set by the command which creates it (set, option, find_library, etc.).

  • cmake-properties(7) »


VALUE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

VALUE

Value of a cache entry.

This property maps to the actual value of a cache entry. Setting this property always sets the value without checking, so use with care.

  • cmake-properties(7) »


CPACK_DESKTOP_SHORTCUTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CPACK_DESKTOP_SHORTCUTS

Species a list of shortcut names that should be created on the Desktop for this file.

The property is currently only supported by the WIX generator.

  • cmake-properties(7) »


CPACK_NEVER_OVERWRITE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CPACK_NEVER_OVERWRITE

Request that this file not be overwritten on install or reinstall.

The property is currently only supported by the WIX generator.

  • cmake-properties(7) »


CPACK_PERMANENT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CPACK_PERMANENT

Request that this file not be removed on uninstall.

The property is currently only supported by the WIX generator.

  • cmake-properties(7) »


CPACK_START_MENU_SHORTCUTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CPACK_START_MENU_SHORTCUTS

Species a list of shortcut names that should be created in the Start Menu for this file.

The property is currently only supported by the WIX generator.

  • cmake-properties(7) »


CPACK_STARTUP_SHORTCUTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CPACK_STARTUP_SHORTCUTS

Species a list of shortcut names that should be created in the Startup folder for this file.

The property is currently only supported by the WIX generator.

  • cmake-properties(7) »


CPACK_WIX_ACL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

CPACK_WIX_ACL

Specifies access permissions for files or directories installed by a WiX installer.

The property can contain multiple list entries, each of which has to match the following format.

<user>[@<domain>]=<permission>[,<permission>]

<user> and <domain> specify the windows user and domain for which the <Permission> element should be generated.

<permission> is any of the YesNoType attributes listed here:

http://wixtoolset.org/documentation/manual/v3/xsd/wix/permission.html

  • cmake-properties(7) »


COMPILE_DEFINITIONS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_DEFINITIONS_<CONFIG>

Ignored. See CMake Policy CMP0043.

Per-configuration preprocessor definitions in a directory.

This is the configuration-specific version of COMPILE_DEFINITIONS where <CONFIG> is an upper-case name (ex. COMPILE_DEFINITIONS_DEBUG).

This property will be initialized in each directory by its value in the directory’s parent.

Contents of COMPILE_DEFINITIONS_<CONFIG> may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Generator expressions should be preferred instead of setting this property.

  • cmake-properties(7) »


TEST_INCLUDE_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

TEST_INCLUDE_FILE

Deprecated. Use TEST_INCLUDE_FILES instead.

A cmake file that will be included when ctest is run.

If you specify TEST_INCLUDE_FILE, that file will be included and processed when ctest is run on the directory.

  • cmake-properties(7) »


COMPILE_DEFINITIONS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_DEFINITIONS_<CONFIG>

Ignored. See CMake Policy CMP0043.

Per-configuration preprocessor definitions on a target.

This is the configuration-specific version of COMPILE_DEFINITIONS where <CONFIG> is an upper-case name (ex. COMPILE_DEFINITIONS_DEBUG).

Contents of COMPILE_DEFINITIONS_<CONFIG> may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

Generator expressions should be preferred instead of setting this property.

  • cmake-properties(7) »


POST_INSTALL_SCRIPT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

POST_INSTALL_SCRIPT

Deprecated install support.

The PRE_INSTALL_SCRIPT and POST_INSTALL_SCRIPT properties are the old way to specify CMake scripts to run before and after installing a target. They are used only when the old INSTALL_TARGETS command is used to install the target. Use the INSTALL command instead.

  • cmake-properties(7) »


PRE_INSTALL_SCRIPT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

PRE_INSTALL_SCRIPT

Deprecated install support.

The PRE_INSTALL_SCRIPT and POST_INSTALL_SCRIPT properties are the old way to specify CMake scripts to run before and after installing a target. They are used only when the old INSTALL_TARGETS command is used to install the target. Use the INSTALL command instead.

  • cmake-properties(7) »


COMPILE_DEFINITIONS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-properties(7) »

COMPILE_DEFINITIONS_<CONFIG>

Ignored. See CMake Policy CMP0043.

Per-configuration preprocessor definitions on a source file.

This is the configuration-specific version of COMPILE_DEFINITIONS. Note that Xcode does not support per-configuration source file flags so this property will be ignored by the Xcode generator.

  • cmake-properties(7) »


cmake-qt(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-qt(7)

Contents

  • cmake-qt(7)
    • Introduction
    • Qt Build Tools
      • AUTOMOC
      • AUTOUIC
      • AUTORCC
    • The <ORIGIN>_autogen target
    • Visual Studio Generators
    • qtmain.lib on Windows

Introduction

CMake can find and use Qt 4 and Qt 5 libraries. The Qt 4 libraries are found by the FindQt4 find-module shipped with CMake, whereas the Qt 5 libraries are found using “Config-file Packages” shipped with Qt 5. See cmake-packages(7) for more information about CMake packages, and see the Qt cmake manual for your Qt version.

Qt 4 and Qt 5 may be used together in the same CMake buildsystem:

cmake_minimum_required(VERSION 3.8.0 FATAL_ERROR)

project(Qt4And5)

set(CMAKE_AUTOMOC ON)

find_package(Qt5 COMPONENTS Widgets DBus REQUIRED)
add_executable(publisher publisher.cpp)
target_link_libraries(publisher Qt5::Widgets Qt5::DBus)

find_package(Qt4 REQUIRED)
add_executable(subscriber subscriber.cpp)
target_link_libraries(subscriber Qt4::QtGui Qt4::QtDBus)

A CMake target may not link to both Qt 4 and Qt 5. A diagnostic is issued if this is attempted or results from transitive target dependency evaluation.

Qt Build Tools

Qt relies on some bundled tools for code generation, such as moc for meta-object code generation, uic for widget layout and population, and rcc for virtual file system content generation. These tools may be automatically invoked by cmake(1) if the appropriate conditions are met. The automatic tool invocation may be used with both Qt 4 and Qt 5.

AUTOMOC

The AUTOMOC target property controls whether cmake(1) inspects the C++ files in the target to determine if they require moc to be run, and to create rules to execute moc at the appropriate time.

If a macro from AUTOMOC_MACRO_NAMES is found in a header file, moc will be run on the file. The result will be put into a file named according to moc_<basename>.cpp. If the macro is found in a C++ implementation file, the moc output will be put into a file named according to <basename>.moc, following the Qt conventions. The <basename>.moc must be included by the user in the C++ implementation file with a preprocessor #include.

Included moc_*.cpp and *.moc files will be generated in the <AUTOGEN_BUILD_DIR>/include directory which is automatically added to the target’s INCLUDE_DIRECTORIES.

  • This differs from CMake 3.7 and below; see their documentation for details.
  • For multi configuration generators, the include directory is <AUTOGEN_BUILD_DIR>/include_<CONFIG>.
  • See AUTOGEN_BUILD_DIR.

Not included moc_<basename>.cpp files will be generated in custom folders to avoid name collisions and included in a separate <AUTOGEN_BUILD_DIR>/mocs_compilation.cpp file which is compiled into the target.

  • See AUTOGEN_BUILD_DIR.

The moc command line will consume the COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES target properties from the target it is being invoked for, and for the appropriate build configuration.

The AUTOMOC target property may be pre-set for all following targets by setting the CMAKE_AUTOMOC variable. The AUTOMOC_MOC_OPTIONS target property may be populated to set options to pass to moc. The CMAKE_AUTOMOC_MOC_OPTIONS variable may be populated to pre-set the options for all following targets.

Additional macro names to search for can be added to AUTOMOC_MACRO_NAMES.

Additional moc dependency file names can be extracted from source code by using AUTOMOC_DEPEND_FILTERS.

Source C++ files can be excluded from AUTOMOC processing by enabling SKIP_AUTOMOC or the broader SKIP_AUTOGEN.

AUTOUIC

The AUTOUIC target property controls whether cmake(1) inspects the C++ files in the target to determine if they require uic to be run, and to create rules to execute uic at the appropriate time.

If a preprocessor #include directive is found which matches <path>ui_<basename>.h, and a <basename>.ui file exists, then uic will be executed to generate the appropriate file. The <basename>.ui file is searched for in the following places

  1. <source_dir>/<basename>.ui
  2. <source_dir>/<path><basename>.ui
  3. <AUTOUIC_SEARCH_PATHS>/<basename>.ui
  4. <AUTOUIC_SEARCH_PATHS>/<path><basename>.ui

where <source_dir> is the directory of the C++ file and AUTOUIC_SEARCH_PATHS is a list of additional search paths.

The generated generated ui_*.h files are placed in the <AUTOGEN_BUILD_DIR>/include directory which is automatically added to the target’s INCLUDE_DIRECTORIES.

  • This differs from CMake 3.7 and below; see their documentation for details.
  • For multi configuration generators, the include directory is <AUTOGEN_BUILD_DIR>/include_<CONFIG>.
  • See AUTOGEN_BUILD_DIR.

The AUTOUIC target property may be pre-set for all following targets by setting the CMAKE_AUTOUIC variable. The AUTOUIC_OPTIONS target property may be populated to set options to pass to uic. The CMAKE_AUTOUIC_OPTIONS variable may be populated to pre-set the options for all following targets. The AUTOUIC_OPTIONS source file property may be set on the <basename>.ui file to set particular options for the file. This overrides options from the AUTOUIC_OPTIONS target property.

A target may populate the INTERFACE_AUTOUIC_OPTIONS target property with options that should be used when invoking uic. This must be consistent with the AUTOUIC_OPTIONS target property content of the depender target. The CMAKE_DEBUG_TARGET_PROPERTIES variable may be used to track the origin target of such INTERFACE_AUTOUIC_OPTIONS. This means that a library which provides an alternative translation system for Qt may specify options which should be used when running uic:

add_library(KI18n klocalizedstring.cpp)
target_link_libraries(KI18n Qt5::Core)

# KI18n uses the tr2i18n() function instead of tr().  That function is
# declared in the klocalizedstring.h header.
set(autouic_options
  -tr tr2i18n
  -include klocalizedstring.h
)

set_property(TARGET KI18n APPEND PROPERTY
  INTERFACE_AUTOUIC_OPTIONS ${autouic_options}
)

A consuming project linking to the target exported from upstream automatically uses appropriate options when uic is run by AUTOUIC, as a result of linking with the IMPORTED target:

set(CMAKE_AUTOUIC ON)
# Uses a libwidget.ui file:
add_library(LibWidget libwidget.cpp)
target_link_libraries(LibWidget
  KF5::KI18n
  Qt5::Widgets
)

Source files can be excluded from AUTOUIC processing by enabling SKIP_AUTOUIC or the broader SKIP_AUTOGEN.

AUTORCC

The AUTORCC target property controls whether cmake(1) creates rules to execute rcc at the appropriate time on source files which have the suffix .qrc.

add_executable(myexe main.cpp resource_file.qrc)

The AUTORCC target property may be pre-set for all following targets by setting the CMAKE_AUTORCC variable. The AUTORCC_OPTIONS target property may be populated to set options to pass to rcc. The CMAKE_AUTORCC_OPTIONS variable may be populated to pre-set the options for all following targets. The AUTORCC_OPTIONS source file property may be set on the <name>.qrc file to set particular options for the file. This overrides options from the AUTORCC_OPTIONS target property.

Source files can be excluded from AUTORCC processing by enabling SKIP_AUTORCC or the broader SKIP_AUTOGEN.

The <ORIGIN>_autogen target

The moc and uic tools are executed as part of a synthesized <ORIGIN>_autogen custom target generated by CMake. By default that <ORIGIN>_autogen target inherits the dependencies of the <ORIGIN> target (see AUTOGEN_ORIGIN_DEPENDS). Target dependencies may be added to the <ORIGIN>_autogen target by adding them to the AUTOGEN_TARGET_DEPENDS target property.

Visual Studio Generators

When using the Visual Studio generators, CMake generates a PRE_BUILD custom command instead of the <ORIGIN>_autogen custom target (for AUTOMOC and AUTOUIC). This isn’t always possible though and an <ORIGIN>_autogen custom target is used, when either

  • the <ORIGIN> target depends on GENERATED files which aren’t excluded from AUTOMOC and AUTOUIC by SKIP_AUTOMOC, SKIP_AUTOUIC, SKIP_AUTOGEN or CMP0071
  • AUTOGEN_TARGET_DEPENDS lists a source file
  • CMAKE_GLOBAL_AUTOGEN_TARGET is enabled

qtmain.lib on Windows

The Qt 4 and 5 IMPORTED targets for the QtGui libraries specify that the qtmain.lib static library shipped with Qt will be linked by all dependent executables which have the WIN32_EXECUTABLE enabled.

To disable this behavior, enable the Qt5_NO_LINK_QTMAIN target property for Qt 5 based targets or QT4_NO_LINK_QTMAIN target property for Qt 4 based targets.

add_executable(myexe WIN32 main.cpp)
target_link_libraries(myexe Qt4::QtGui)

add_executable(myexe_no_qtmain WIN32 main_no_qtmain.cpp)
set_property(TARGET main_no_qtmain PROPERTY QT4_NO_LINK_QTMAIN ON)
target_link_libraries(main_no_qtmain Qt4::QtGui)


cmake-server(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-server(7)

Contents

  • cmake-server(7)
    • Introduction
    • Operation
    • Debugging
    • Protocol API
      • General Message Layout
        • Type “reply”
        • Type “error”
        • Type “progress”
        • Type “message”
        • Type “signal”
      • Specific Signals
        • “dirty” Signal
        • “fileChange” Signal
      • Specific Message Types
        • Type “hello”
        • Type “handshake”
        • Type “globalSettings”
        • Type “setGlobalSettings”
        • Type “configure”
        • Type “compute”
        • Type “codemodel”
        • Type “ctestInfo”
        • Type “cmakeInputs”
        • Type “cache”
        • Type “fileSystemWatchers”

Introduction

cmake(1) is capable of providing semantic information about CMake code it executes to generate a buildsystem. If executed with the -E server command line options, it starts in a long running mode and allows a client to request the available information via a JSON protocol.

The protocol is designed to be useful to IDEs, refactoring tools, and other tools which have a need to understand the buildsystem in entirety.

A single cmake-buildsystem(7) may describe buildsystem contents and build properties which differ based on generation-time context including:

  • The Platform (eg, Windows, APPLE, Linux).
  • The build configuration (eg, Debug, Release, Coverage).
  • The Compiler (eg, MSVC, GCC, Clang) and compiler version.
  • The language of the source files compiled.
  • Available compile features (eg CXX variadic templates).
  • CMake policies.

The protocol aims to provide information to tooling to satisfy several needs:

  1. Provide a complete and easily parsed source of all information relevant to the tooling as it relates to the source code. There should be no need for tooling to parse generated buildsystems to access include directories or compile definitions for example.
  2. Semantic information about the CMake buildsystem itself.
  3. Provide a stable interface for reading the information in the CMake cache.
  4. Information for determining when cmake needs to be re-run as a result of file changes.

Operation

Start cmake(1) in the server command mode, supplying the path to the build directory to process:

cmake -E server (--debug|--pipe=<NAMED_PIPE>)

The server will communicate using stdin/stdout (with the --debug parameter) or using a named pipe (with the --pipe=<NAMED_PIPE> parameter). Note that “named pipe” refers to a local domain socket on Unix and to a named pipe on Windows.

When connecting to the server (via named pipe or by starting it in --debug mode), the server will reply with a hello message:

[== "CMake Server" ==[
{"supportedProtocolVersions":[{"major":1,"minor":0}],"type":"hello"}
]== "CMake Server" ==]

Messages sent to and from the process are wrapped in magic strings:

[== "CMake Server" ==[
{
  ... some JSON message ...
}
]== "CMake Server" ==]

The server is now ready to accept further requests via the named pipe or stdin.

Debugging

CMake server mode can be asked to provide statistics on execution times, etc. or to dump a copy of the response into a file. This is done passing a “debug” JSON object as a child of the request.

The debug object supports the “showStats” key, which takes a boolean and makes the server mode return a “zzzDebug” object with stats as part of its response. “dumpToFile” takes a string value and will cause the cmake server to copy the response into the given filename.

This is a response from the cmake server with “showStats” set to true:

[== "CMake Server" ==[
{
  "cookie":"",
  "errorMessage":"Waiting for type \"handshake\".",
  "inReplyTo":"unknown",
 "type":"error",
  "zzzDebug": {
    "dumpFile":"/tmp/error.txt",
    "jsonSerialization":0.011016,
    "size":111,
    "totalTime":0.025995
  }
}
]== "CMake Server" ==]

The server has made a copy of this response into the file /tmp/error.txt and took 0.011 seconds to turn the JSON response into a string, and it took 0.025 seconds to process the request in total. The reply has a size of 111 bytes.

Protocol API

General Message Layout

All messages need to have a “type” value, which identifies the type of message that is passed back or forth. E.g. the initial message sent by the server is of type “hello”. Messages without a type will generate an response of type “error”.

All requests sent to the server may contain a “cookie” value. This value will he handed back unchanged in all responses triggered by the request.

All responses will contain a value “inReplyTo”, which may be empty in case of parse errors, but will contain the type of the request message in all other cases.

Type “reply”

This type is used by the server to reply to requests.

The message may – depending on the type of the original request – contain values.

Example:

[== "CMake Server" ==[
{"cookie":"zimtstern","inReplyTo":"handshake","type":"reply"}
]== "CMake Server" ==]

Type “error”

This type is used to return an error condition to the client. It will contain an “errorMessage”.

Example:

[== "CMake Server" ==[
{"cookie":"","errorMessage":"Protocol version not supported.","inReplyTo":"handshake","type":"error"}
]== "CMake Server" ==]

Type “progress”

When the server is busy for a long time, it is polite to send back replies of type “progress” to the client. These will contain a “progressMessage” with a string describing the action currently taking place as well as “progressMinimum”, “progressMaximum” and “progressCurrent” with integer values describing the range of progress.

Messages of type “progress” will be followed by more “progress” messages or with a message of type “reply” or “error” that complete the request.

“progress” messages may not be emitted after the “reply” or “error” message for the request that triggered the responses was delivered.

Type “message”

A message is triggered when the server processes a request and produces some form of output that should be displayed to the user. A Message has a “message” with the actual text to display as well as a “title” with a suggested dialog box title.

Example:

[== "CMake Server" ==[
{"cookie":"","message":"Something happened.","title":"Title Text","inReplyTo":"handshake","type":"message"}
]== "CMake Server" ==]

Type “signal”

The server can send signals when it detects changes in the system state. Signals are of type “signal”, have an empty “cookie” and “inReplyTo” field and always have a “name” set to show which signal was sent.

Specific Signals

The cmake server may sent signals with the following names:

“dirty” Signal

The “dirty” signal is sent whenever the server determines that the configuration of the project is no longer up-to-date. This happens when any of the files that have an influence on the build system is changed.

The “dirty” signal may look like this:

[== "CMake Server" ==[
{
  "cookie":"",
  "inReplyTo":"",
  "name":"dirty",
  "type":"signal"}
]== "CMake Server" ==]

“fileChange” Signal

The “fileChange” signal is sent whenever a watched file is changed. It contains the “path” that has changed and a list of “properties” with the kind of change that was detected. Possible changes are “change” and “rename”.

The “fileChange” signal looks like this:

[== "CMake Server" ==[
{
  "cookie":"",
  "inReplyTo":"",
  "name":"fileChange",
  "path":"/absolute/CMakeLists.txt",
  "properties":["change"],
  "type":"signal"}
]== "CMake Server" ==]

Specific Message Types

Type “hello”

The initial message send by the cmake server on startup is of type “hello”. This is the only message ever sent by the server that is not of type “reply”, “progress” or “error”.

It will contain “supportedProtocolVersions” with an array of server protocol versions supported by the cmake server. These are JSON objects with “major” and “minor” keys containing non-negative integer values. Some versions may be marked as experimental. These will contain the “isExperimental” key set to true. Enabling these requires a special command line argument when starting the cmake server mode.

Within a “major” version all “minor” versions are fully backwards compatible. New “minor” versions may introduce functionality in such a way that existing clients of the same “major” version will continue to work, provided they ignore keys in the output that they do not know about.

Example:

[== "CMake Server" ==[
{"supportedProtocolVersions":[{"major":0,"minor":1}],"type":"hello"}
]== "CMake Server" ==]

Type “handshake”

The first request that the client may send to the server is of type “handshake”.

This request needs to pass one of the “supportedProtocolVersions” of the “hello” type response received earlier back to the server in the “protocolVersion” field. Giving the “major” version of the requested protocol version will make the server use the latest minor version of that protocol. Use this if you do not explicitly need to depend on a specific minor version.

Protocol version 1.0 requires the following attributes to be set:

  • “sourceDirectory” with a path to the sources
  • “buildDirectory” with a path to the build directory
  • “generator” with the generator name
  • “extraGenerator” (optional!) with the extra generator to be used
  • “platform” with the generator platform (if supported by the generator)
  • “toolset” with the generator toolset (if supported by the generator)

Protocol version 1.2 makes all but the build directory optional, provided there is a valid cache in the build directory that contains all the other information already.

Example:

[== "CMake Server" ==[
{"cookie":"zimtstern","type":"handshake","protocolVersion":{"major":0},
 "sourceDirectory":"/home/code/cmake", "buildDirectory":"/tmp/testbuild",
 "generator":"Ninja"}
]== "CMake Server" ==]

which will result in a response type “reply”:

[== "CMake Server" ==[
{"cookie":"zimtstern","inReplyTo":"handshake","type":"reply"}
]== "CMake Server" ==]

indicating that the server is ready for action.

Type “globalSettings”

This request can be sent after the initial handshake. It will return a JSON structure with information on cmake state.

Example:

[== "CMake Server" ==[
{"type":"globalSettings"}
]== "CMake Server" ==]

which will result in a response type “reply”:

[== "CMake Server" ==[
{
  "buildDirectory": "/tmp/test-build",
  "capabilities": {
    "generators": [
      {
        "extraGenerators": [],
        "name": "Watcom WMake",
        "platformSupport": false,
        "toolsetSupport": false
      },
      <...>
    ],
    "serverMode": false,
    "version": {
      "isDirty": false,
      "major": 3,
      "minor": 6,
      "patch": 20160830,
      "string": "3.6.20160830-gd6abad",
      "suffix": "gd6abad"
    }
  },
  "checkSystemVars": false,
  "cookie": "",
  "extraGenerator": "",
  "generator": "Ninja",
  "debugOutput": false,
  "inReplyTo": "globalSettings",
  "sourceDirectory": "/home/code/cmake",
  "trace": false,
  "traceExpand": false,
  "type": "reply",
  "warnUninitialized": false,
  "warnUnused": false,
  "warnUnusedCli": true
}
]== "CMake Server" ==]

Type “setGlobalSettings”

This request can be sent to change the global settings attributes. Unknown attributes are going to be ignored. Read-only attributes reported by “globalSettings” are all capabilities, buildDirectory, generator, extraGenerator and sourceDirectory. Any attempt to set these will be ignored, too.

All other settings will be changed.

The server will respond with an empty reply message or an error.

Example:

[== "CMake Server" ==[
{"type":"setGlobalSettings","debugOutput":true}
]== "CMake Server" ==]

CMake will reply to this with:

[== "CMake Server" ==[
{"inReplyTo":"setGlobalSettings","type":"reply"}
]== "CMake Server" ==]

Type “configure”

This request will configure a project for build.

To configure a build directory already containing cmake files, it is enough to set “buildDirectory” via “setGlobalSettings”. To create a fresh build directory you also need to set “currentGenerator” and “sourceDirectory” via “setGlobalSettings” in addition to “buildDirectory”.

You may a list of strings to “configure” via the “cacheArguments” key. These strings will be interpreted similar to command line arguments related to cache handling that are passed to the cmake command line client.

Example:

[== "CMake Server" ==[
{"type":"configure", "cacheArguments":["-Dsomething=else"]}
]== "CMake Server" ==]

CMake will reply like this (after reporting progress for some time):

[== "CMake Server" ==[
{"cookie":"","inReplyTo":"configure","type":"reply"}
]== "CMake Server" ==]

Type “compute”

This request will generate build system files in the build directory and is only available after a project was successfully “configure”d.

Example:

[== "CMake Server" ==[
{"type":"compute"}
]== "CMake Server" ==]

CMake will reply (after reporting progress information):

[== "CMake Server" ==[
{"cookie":"","inReplyTo":"compute","type":"reply"}
]== "CMake Server" ==]

Type “codemodel”

The “codemodel” request can be used after a project was “compute”d successfully.

It will list the complete project structure as it is known to cmake.

The reply will contain a key “configurations”, which will contain a list of configuration objects. Configuration objects are used to destinquish between different configurations the build directory might have enabled. While most generators only support one configuration, others might support several.

Each configuration object can have the following keys:

“name”
contains the name of the configuration. The name may be empty.
“projects”
contains a list of project objects, one for each build project.

Project objects define one (sub-)project defined in the cmake build system.

Each project object can have the following keys:

“name”
contains the (sub-)projects name.
“minimumCMakeVersion”
contains the minimum cmake version allowed for this project, null if the project doesn’t specify one.
“hasInstallRule”
true if the project contains any install rules, false otherwise.
“sourceDirectory”
contains the current source directory
“buildDirectory”
contains the current build directory.
“targets”
contains a list of build system target objects.

Target objects define individual build targets for a certain configuration.

Each target object can have the following keys:

“name”
contains the name of the target.
“type”
defines the type of build of the target. Possible values are “STATIC_LIBRARY”, “MODULE_LIBRARY”, “SHARED_LIBRARY”, “OBJECT_LIBRARY”, “EXECUTABLE”, “UTILITY” and “INTERFACE_LIBRARY”.
“fullName”
contains the full name of the build result (incl. extensions, etc.).
“sourceDirectory”
contains the current source directory.
“buildDirectory”
contains the current build directory.
“isGeneratorProvided”
true if the target is auto-created by a generator, false otherwise
“hasInstallRule”
true if the target contains any install rules, false otherwise.
“installPaths”
full path to the destination directories defined by target install rules.
“artifacts”
with a list of build artifacts. The list is sorted with the most important artifacts first (e.g. a .DLL file is listed before a .PDB file on windows).
“linkerLanguage”
contains the language of the linker used to produce the artifact.
“linkLibraries”
with a list of libraries to link to. This value is encoded in the system’s native shell format.
“linkFlags”
with a list of flags to pass to the linker. This value is encoded in the system’s native shell format.
“linkLanguageFlags”
with the flags for a compiler using the linkerLanguage. This value is encoded in the system’s native shell format.
“frameworkPath”
with the framework path (on Apple computers). This value is encoded in the system’s native shell format.
“linkPath”
with the link path. This value is encoded in the system’s native shell format.
“sysroot”
with the sysroot path.
“fileGroups”
contains the source files making up the target.

FileGroups are used to group sources using similar settings together.

Each fileGroup object may contain the following keys:

“language”
contains the programming language used by all files in the group.
“compileFlags”
with a string containing all the flags passed to the compiler when building any of the files in this group. This value is encoded in the system’s native shell format.
“includePath”
with a list of include paths. Each include path is an object containing a “path” with the actual include path and “isSystem” with a bool value informing whether this is a normal include or a system include. This value is encoded in the system’s native shell format.
“defines”
with a list of defines in the form “SOMEVALUE” or “SOMEVALUE=42”. This value is encoded in the system’s native shell format.
“sources”
with a list of source files.

All file paths in the fileGroup are either absolute or relative to the sourceDirectory of the target.

Example:

[== "CMake Server" ==[
{"type":"codemodel"}
]== "CMake Server" ==]

CMake will reply:

[== "CMake Server" ==[
{
  "configurations": [
    {
      "name": "",
      "projects": [
        {
          "buildDirectory": "/tmp/build/Source/CursesDialog/form",
          "name": "CMAKE_FORM",
          "sourceDirectory": "/home/code/src/cmake/Source/CursesDialog/form",
          "targets": [
            {
              "artifacts": [ "/tmp/build/Source/CursesDialog/form/libcmForm.a" ],
              "buildDirectory": "/tmp/build/Source/CursesDialog/form",
              "fileGroups": [
                {
                  "compileFlags": "  -std=gnu11",
                  "defines": [ "CURL_STATICLIB", "LIBARCHIVE_STATIC" ],
                  "includePath": [ { "path": "/tmp/build/Utilities" }, <...> ],
                  "isGenerated": false,
                  "language": "C",
                  "sources": [ "fld_arg.c", <...> ]
                }
              ],
              "fullName": "libcmForm.a",
              "linkerLanguage": "C",
              "name": "cmForm",
              "sourceDirectory": "/home/code/src/cmake/Source/CursesDialog/form",
              "type": "STATIC_LIBRARY"
            }
          ]
        },
        <...>
      ]
    }
  ],
  "cookie": "",
  "inReplyTo": "codemodel",
  "type": "reply"
}
]== "CMake Server" ==]

Type “ctestInfo”

The “ctestInfo” request can be used after a project was “compute”d successfully.

It will list the complete project test structure as it is known to cmake.

The reply will contain a key “configurations”, which will contain a list of configuration objects. Configuration objects are used to destinquish between different configurations the build directory might have enabled. While most generators only support one configuration, others might support several.

Each configuration object can have the following keys:

“name”
contains the name of the configuration. The name may be empty.
“projects”
contains a list of project objects, one for each build project.

Project objects define one (sub-)project defined in the cmake build system.

Each project object can have the following keys:

“name”
contains the (sub-)projects name.
“ctestInfo”
contains a list of test objects.

Each test object can have the following keys:

“ctestName”
contains the name of the test.
“ctestCommand”
contains the test command.
“properties”
contains a list of test property objects.

Each test property object can have the following keys:

“key”
contains the test property key.
“value”
contains the test property value.

Type “cmakeInputs”

The “cmakeInputs” requests will report files used by CMake as part of the build system itself.

This request is only available after a project was successfully “configure”d.

Example:

[== "CMake Server" ==[
{"type":"cmakeInputs"}
]== "CMake Server" ==]

CMake will reply with the following information:

[== "CMake Server" ==[
{"buildFiles":
  [
    {"isCMake":true,"isTemporary":false,"sources":["/usr/lib/cmake/...", ... ]},
    {"isCMake":false,"isTemporary":false,"sources":["CMakeLists.txt", ...]},
    {"isCMake":false,"isTemporary":true,"sources":["/tmp/build/CMakeFiles/...", ...]}
  ],
  "cmakeRootDirectory":"/usr/lib/cmake",
  "sourceDirectory":"/home/code/src/cmake",
  "cookie":"",
  "inReplyTo":"cmakeInputs",
  "type":"reply"
}
]== "CMake Server" ==]

All file names are either relative to the top level source directory or absolute.

The list of files which “isCMake” set to true are part of the cmake installation.

The list of files witch “isTemporary” set to true are part of the build directory and will not survive the build directory getting cleaned out.

Type “cache”

The “cache” request will list the cached configuration values.

Example:

[== "CMake Server" ==[
{"type":"cache"}
]== "CMake Server" ==]

CMake will respond with the following output:

[== "CMake Server" ==[
{
  "cookie":"","inReplyTo":"cache","type":"reply",
  "cache":
  [
    {
      "key":"SOMEVALUE",
      "properties":
      {
        "ADVANCED":"1",
        "HELPSTRING":"This is not helpful"
      }
      "type":"STRING",
      "value":"TEST"}
  ]
}
]== "CMake Server" ==]

The output can be limited to a list of keys by passing an array of key names to the “keys” optional field of the “cache” request.

Type “fileSystemWatchers”

The server can watch the filesystem for changes. The “fileSystemWatchers” command will report on the files and directories watched.

Example:

[== "CMake Server" ==[
{"type":"fileSystemWatchers"}
]== "CMake Server" ==]

CMake will respond with the following output:

[== "CMake Server" ==[
{
  "cookie":"","inReplyTo":"fileSystemWatchers","type":"reply",
  "watchedFiles": [ "/absolute/path" ],
  "watchedDirectories": [ "/absolute" ]
}
]== "CMake Server" ==]


cmake-toolchains(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-toolchains(7)

Contents

  • cmake-toolchains(7)
    • Introduction
    • Languages
    • Variables and Properties
    • Toolchain Features
    • Cross Compiling
      • Cross Compiling for Linux
      • Cross Compiling for the Cray Linux Environment
      • Cross Compiling using Clang
      • Cross Compiling for QNX
      • Cross Compiling for Windows CE
      • Cross Compiling for Windows 10 Universal Applications
      • Cross Compiling for Windows Phone
      • Cross Compiling for Windows Store
      • Cross Compiling for Android
        • Cross Compiling for Android with the NDK
        • Cross Compiling for Android with a Standalone Toolchain
        • Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition
      • Cross Compiling for iOS, tvOS, or watchOS
        • Code Signing
        • Switching Between Device and Simulator

Introduction

CMake uses a toolchain of utilities to compile, link libraries and create archives, and other tasks to drive the build. The toolchain utilities available are determined by the languages enabled. In normal builds, CMake automatically determines the toolchain for host builds based on system introspection and defaults. In cross-compiling scenarios, a toolchain file may be specified with information about compiler and utility paths.

Languages

Languages are enabled by the project() command. Language-specific built-in variables, such as CMAKE_CXX_COMPILER, CMAKE_CXX_COMPILER_ID etc are set by invoking the project() command. If no project command is in the top-level CMakeLists file, one will be implicitly generated. By default the enabled languages are C and CXX:

project(C_Only C)

A special value of NONE can also be used with the project() command to enable no languages:

project(MyProject NONE)

The enable_language() command can be used to enable languages after the project() command:

enable_language(CXX)

When a language is enabled, CMake finds a compiler for that language, and determines some information, such as the vendor and version of the compiler, the target architecture and bitwidth, the location of corresponding utilities etc.

The ENABLED_LANGUAGES global property contains the languages which are currently enabled.

Variables and Properties

Several variables relate to the language components of a toolchain which are enabled. CMAKE_<LANG>_COMPILER is the full path to the compiler used for <LANG>. CMAKE_<LANG>_COMPILER_ID is the identifier used by CMake for the compiler and CMAKE_<LANG>_COMPILER_VERSION is the version of the compiler.

The CMAKE_<LANG>_FLAGS variables and the configuration-specific equivalents contain flags that will be added to the compile command when compiling a file of a particular language.

As the linker is invoked by the compiler driver, CMake needs a way to determine which compiler to use to invoke the linker. This is calculated by the LANGUAGE of source files in the target, and in the case of static libraries, the language of the dependent libraries. The choice CMake makes may be overridden with the LINKER_LANGUAGE target property.

Toolchain Features

CMake provides the try_compile() command and wrapper macros such as CheckCXXSourceCompiles, CheckCXXSymbolExists and CheckIncludeFile to test capability and availability of various toolchain features. These APIs test the toolchain in some way and cache the result so that the test does not have to be performed again the next time CMake runs.

Some toolchain features have built-in handling in CMake, and do not require compile-tests. For example, POSITION_INDEPENDENT_CODE allows specifying that a target should be built as position-independent code, if the compiler supports that feature. The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target properties add flags for hidden visibility, if supported by the compiler.

Cross Compiling

If cmake(1) is invoked with the command line parameter -DCMAKE_TOOLCHAIN_FILE=path/to/file, the file will be loaded early to set values for the compilers. The CMAKE_CROSSCOMPILING variable is set to true when CMake is cross-compiling.

Cross Compiling for Linux

A typical cross-compiling toolchain for Linux has content such as:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_SYSROOT /home/devel/rasp-pi-rootfs)
set(CMAKE_STAGING_PREFIX /home/devel/stage)

set(tools /home/devel/gcc-4.7-linaro-rpi-gnueabihf)
set(CMAKE_C_COMPILER ${tools}/bin/arm-linux-gnueabihf-gcc)
set(CMAKE_CXX_COMPILER ${tools}/bin/arm-linux-gnueabihf-g++)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

The CMAKE_SYSTEM_NAME is the CMake-identifier of the target platform to build for.

The CMAKE_SYSTEM_PROCESSOR is the CMake-identifier of the target architecture to build for.

The CMAKE_SYSROOT is optional, and may be specified if a sysroot is available.

The CMAKE_STAGING_PREFIX is also optional. It may be used to specify a path on the host to install to. The CMAKE_INSTALL_PREFIX is always the runtime installation location, even when cross-compiling.

The CMAKE_<LANG>_COMPILER variables may be set to full paths, or to names of compilers to search for in standard locations. For toolchains that do not support linking binaries without custom flags or scripts one may set the CMAKE_TRY_COMPILE_TARGET_TYPE variable to STATIC_LIBRARY to tell CMake not to try to link executables during its checks.

CMake find_* commands will look in the sysroot, and the CMAKE_FIND_ROOT_PATH entries by default in all cases, as well as looking in the host system root prefix. Although this can be controlled on a case-by-case basis, when cross-compiling, it can be useful to exclude looking in either the host or the target for particular artifacts. Generally, includes, libraries and packages should be found in the target system prefixes, whereas executables which must be run as part of the build should be found only on the host and not on the target. This is the purpose of the CMAKE_FIND_ROOT_PATH_MODE_* variables.

Cross Compiling for the Cray Linux Environment

Cross compiling for compute nodes in the Cray Linux Environment can be done without needing a separate toolchain file. Specifying -DCMAKE_SYSTEM_NAME=CrayLinuxEnvironment on the CMake command line will ensure that the appropriate build settings and search paths are configured. The platform will pull its configuration from the current environment variables and will configure a project to use the compiler wrappers from the Cray Programming Environment’s PrgEnv-* modules if present and loaded.

The default configuration of the Cray Programming Environment is to only support static libraries. This can be overridden and shared libraries enabled by setting the CRAYPE_LINK_TYPE environment variable to dynamic.

Running CMake without specifying CMAKE_SYSTEM_NAME will run the configure step in host mode assuming a standard Linux environment. If not overridden, the PrgEnv-* compiler wrappers will end up getting used, which if targeting the either the login node or compute node, is likely not the desired behavior. The exception to this would be if you are building directly on a NID instead of cross-compiling from a login node. If trying to build software for a login node, you will need to either first unload the currently loaded PrgEnv-* module or explicitly tell CMake to use the system compilers in /usr/bin instead of the Cray wrappers. If instead targeting a compute node is desired, just specify the CMAKE_SYSTEM_NAME as mentioned above.

Cross Compiling using Clang

Some compilers such as Clang are inherently cross compilers. The CMAKE_<LANG>_COMPILER_TARGET can be set to pass a value to those supported compilers when compiling:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(triple arm-linux-gnueabihf)

set(CMAKE_C_COMPILER clang)
set(CMAKE_C_COMPILER_TARGET ${triple})
set(CMAKE_CXX_COMPILER clang++)
set(CMAKE_CXX_COMPILER_TARGET ${triple})

Similarly, some compilers do not ship their own supplementary utilities such as linkers, but provide a way to specify the location of the external toolchain which will be used by the compiler driver. The CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN variable can be set in a toolchain file to pass the path to the compiler driver.

Cross Compiling for QNX

As the Clang compiler the QNX QCC compile is inherently a cross compiler. And the CMAKE_<LANG>_COMPILER_TARGET can be set to pass a value to those supported compilers when compiling:

set(CMAKE_SYSTEM_NAME QNX)

set(arch gcc_ntoarmv7le)

set(CMAKE_C_COMPILER qcc)
set(CMAKE_C_COMPILER_TARGET ${arch})
set(CMAKE_CXX_COMPILER QCC)
set(CMAKE_CXX_COMPILER_TARGET ${arch})

Cross Compiling for Windows CE

Cross compiling for Windows CE requires the corresponding SDK being installed on your system. These SDKs are usually installed under C:/Program Files (x86)/Windows CE Tools/SDKs.

A toolchain file to configure a Visual Studio generator for Windows CE may look like this:

set(CMAKE_SYSTEM_NAME WindowsCE)

set(CMAKE_SYSTEM_VERSION 8.0)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_GENERATOR_TOOLSET CE800) # Can be omitted for 8.0
set(CMAKE_GENERATOR_PLATFORM SDK_AM335X_SK_WEC2013_V310)

The CMAKE_GENERATOR_PLATFORM tells the generator which SDK to use. Further CMAKE_SYSTEM_VERSION tells the generator what version of Windows CE to use. Currently version 8.0 (Windows Embedded Compact 2013) is supported out of the box. Other versions may require one to set CMAKE_GENERATOR_TOOLSET to the correct value.

Cross Compiling for Windows 10 Universal Applications

A toolchain file to configure a Visual Studio generator for a Windows 10 Universal Application may look like this:

set(CMAKE_SYSTEM_NAME WindowsStore)
set(CMAKE_SYSTEM_VERSION 10.0)

A Windows 10 Universal Application targets both Windows Store and Windows Phone. Specify the CMAKE_SYSTEM_VERSION variable to be 10.0 to build with the latest available Windows 10 SDK. Specify a more specific version (e.g. 10.0.10240.0 for RTM) to build with the corresponding SDK.

Cross Compiling for Windows Phone

A toolchain file to configure a Visual Studio generator for Windows Phone may look like this:

set(CMAKE_SYSTEM_NAME WindowsPhone)
set(CMAKE_SYSTEM_VERSION 8.1)

Cross Compiling for Windows Store

A toolchain file to configure a Visual Studio generator for Windows Store may look like this:

set(CMAKE_SYSTEM_NAME WindowsStore)
set(CMAKE_SYSTEM_VERSION 8.1)

Cross Compiling for Android

A toolchain file may configure cross-compiling for Android by setting the CMAKE_SYSTEM_NAME variable to Android. Further configuration is specific to the Android development environment to be used.

For Visual Studio Generators, CMake expects NVIDIA Nsight Tegra Visual Studio Edition to be installed. See that section for further configuration details.

For Makefile Generators and the Ninja generator, CMake expects one of these environments:

  • NDK
  • Standalone Toolchain

CMake uses the following steps to select one of the environments:

  • If the CMAKE_ANDROID_NDK variable is set, the NDK at the specified location will be used.
  • Else, if the CMAKE_ANDROID_STANDALONE_TOOLCHAIN variable is set, the Standalone Toolchain at the specified location will be used.
  • Else, if the CMAKE_SYSROOT variable is set to a directory of the form <ndk>/platforms/android-<api>/arch-<arch>, the <ndk> part will be used as the value of CMAKE_ANDROID_NDK and the NDK will be used.
  • Else, if the CMAKE_SYSROOT variable is set to a directory of the form <standalone-toolchain>/sysroot, the <standalone-toolchain> part will be used as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAIN and the Standalone Toolchain will be used.
  • Else, if a cmake variable ANDROID_NDK is set it will be used as the value of CMAKE_ANDROID_NDK, and the NDK will be used.
  • Else, if a cmake variable ANDROID_STANDALONE_TOOLCHAIN is set, it will be used as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAIN, and the Standalone Toolchain will be used.
  • Else, if an environment variable ANDROID_NDK_ROOT or ANDROID_NDK is set, it will be used as the value of CMAKE_ANDROID_NDK, and the NDK will be used.
  • Else, if an environment variable ANDROID_STANDALONE_TOOLCHAIN is set then it will be used as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAIN, and the Standalone Toolchain will be used.
  • Else, an error diagnostic will be issued that neither the NDK or Standalone Toolchain can be found.

Cross Compiling for Android with the NDK

A toolchain file may configure Makefile Generators or the Ninja generator to target Android for cross-compiling.

Configure use of an Android NDK with the following variables:

CMAKE_SYSTEM_NAME
Set to Android. Must be specified to enable cross compiling for Android.
CMAKE_SYSTEM_VERSION

Set to the Android API level. If not specified, the value is determined as follows:

  • If the CMAKE_ANDROID_API variable is set, its value is used as the API level.
  • If the CMAKE_SYSROOT variable is set, the API level is detected from the NDK directory structure containing the sysroot.
  • Otherwise, the latest API level available in the NDK is used.
CMAKE_ANDROID_ARCH_ABI
Set to the Android ABI (architecture). If not specified, this variable will default to armeabi. The CMAKE_ANDROID_ARCH variable will be computed from CMAKE_ANDROID_ARCH_ABI automatically. Also see the CMAKE_ANDROID_ARM_MODE and CMAKE_ANDROID_ARM_NEON variables.
CMAKE_ANDROID_NDK
Set to the absolute path to the Android NDK root directory. A ${CMAKE_ANDROID_NDK}/platforms directory must exist. If not specified, a default for this variable will be chosen as specified above.
CMAKE_ANDROID_NDK_DEPRECATED_HEADERS
Set to a true value to use the deprecated per-api-level headers instead of the unified headers. If not specified, the default will be false unless using a NDK that does not provide unified headers.
CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION
Set to the version of the NDK toolchain to be selected as the compiler. If not specified, the default will be the latest available GCC toolchain.
CMAKE_ANDROID_STL_TYPE
Set to specify which C++ standard library to use. If not specified, a default will be selected as described in the variable documentation.

The following variables will be computed and provided automatically:

CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX
The absolute path prefix to the binutils in the NDK toolchain.
CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX
The host platform suffix of the binutils in the NDK toolchain.

For example, a toolchain file might contain:

set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSTEM_VERSION 21) # API level
set(CMAKE_ANDROID_ARCH_ABI arm64-v8a)
set(CMAKE_ANDROID_NDK /path/to/android-ndk)
set(CMAKE_ANDROID_STL_TYPE gnustl_static)

Alternatively one may specify the values without a toolchain file:

$ cmake ../src \
  -DCMAKE_SYSTEM_NAME=Android \
  -DCMAKE_SYSTEM_VERSION=21 \
  -DCMAKE_ANDROID_ARCH_ABI=arm64-v8a \
  -DCMAKE_ANDROID_NDK=/path/to/android-ndk \
  -DCMAKE_ANDROID_STL_TYPE=gnustl_static

Cross Compiling for Android with a Standalone Toolchain

A toolchain file may configure Makefile Generators or the Ninja generator to target Android for cross-compiling using a standalone toolchain.

Configure use of an Android standalone toolchain with the following variables:

CMAKE_SYSTEM_NAME
Set to Android. Must be specified to enable cross compiling for Android.
CMAKE_ANDROID_STANDALONE_TOOLCHAIN
Set to the absolute path to the standalone toolchain root directory. A ${CMAKE_ANDROID_STANDALONE_TOOLCHAIN}/sysroot directory must exist. If not specified, a default for this variable will be chosen as specified above.
CMAKE_ANDROID_ARM_MODE
When the standalone toolchain targets ARM, optionally set this to ON to target 32-bit ARM instead of 16-bit Thumb. See variable documentation for details.
CMAKE_ANDROID_ARM_NEON
When the standalone toolchain targets ARM v7, optionally set thisto ON to target ARM NEON devices. See variable documentation for details.

The following variables will be computed and provided automatically:

CMAKE_SYSTEM_VERSION
The Android API level detected from the standalone toolchain.
CMAKE_ANDROID_ARCH_ABI
The Android ABI detected from the standalone toolchain.
CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX
The absolute path prefix to the binutils in the standalone toolchain.
CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX
The host platform suffix of the binutils in the standalone toolchain.

For example, a toolchain file might contain:

set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_ANDROID_STANDALONE_TOOLCHAIN /path/to/android-toolchain)

Alternatively one may specify the values without a toolchain file:

$ cmake ../src \
  -DCMAKE_SYSTEM_NAME=Android \
  -DCMAKE_ANDROID_STANDALONE_TOOLCHAIN=/path/to/android-toolchain

Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio Edition

A toolchain file to configure one of the Visual Studio Generators to build using NVIDIA Nsight Tegra targeting Android may look like this:

set(CMAKE_SYSTEM_NAME Android)

The CMAKE_GENERATOR_TOOLSET may be set to select the Nsight Tegra “Toolchain Version” value.

See also target properties:

  • ANDROID_ANT_ADDITIONAL_OPTIONS
  • ANDROID_API_MIN
  • ANDROID_API
  • ANDROID_ARCH
  • ANDROID_ASSETS_DIRECTORIES
  • ANDROID_GUI
  • ANDROID_JAR_DEPENDENCIES
  • ANDROID_JAR_DIRECTORIES
  • ANDROID_JAVA_SOURCE_DIR
  • ANDROID_NATIVE_LIB_DEPENDENCIES
  • ANDROID_NATIVE_LIB_DIRECTORIES
  • ANDROID_PROCESS_MAX
  • ANDROID_PROGUARD_CONFIG_PATH
  • ANDROID_PROGUARD
  • ANDROID_SECURE_PROPS_PATH
  • ANDROID_SKIP_ANT_STEP
  • ANDROID_STL_TYPE

Cross Compiling for iOS, tvOS, or watchOS

For cross-compiling to iOS, tvOS, or watchOS, the Xcode generator is recommended. The Unix Makefiles or Ninja generators can also be used, but they require the project to handle more areas like target CPU selection and code signing.

Any of the three systems can be targetted by setting the CMAKE_SYSTEM_NAME variable to a value from the table below. By default, the latest Device SDK is chosen. As for all Apple platforms, a different SDK (e.g. a simulator) can be selected by setting the CMAKE_OSX_SYSROOT variable, although this should rarely be necessary (see Switching Between Device and Simulator below). A list of available SDKs can be obtained by running xcodebuild -showsdks.

OS | CMAKE_SYSTEM_NAME | Device SDK (default) | Simulator SDK
iOS | iOS | iphoneos | iphonesimulator
tvOS | tvOS | appletvos | appletvsimulator
watchOS | watchOS | watchos | watchsimulator

For example, to create a CMake configuration for iOS, the following command is sufficient:

cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS

Variable CMAKE_OSX_ARCHITECTURES can be used to set architectures for both device and simulator. Variable CMAKE_OSX_DEPLOYMENT_TARGET can be used to set an iOS/tvOS/watchOS deployment target.

Next configuration will install fat 5 architectures iOS library and add the -miphoneos-version-min=9.3/-mios-simulator-version-min=9.3 flags to the compiler:

$ cmake -S. -B_builds -GXcode \
    -DCMAKE_SYSTEM_NAME=iOS \
    "-DCMAKE_OSX_ARCHITECTURES=armv7;armv7s;arm64;i386;x86_64" \
    -DCMAKE_OSX_DEPLOYMENT_TARGET=9.3 \
    -DCMAKE_INSTALL_PREFIX=`pwd`/_install \
    -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \
    -DCMAKE_IOS_INSTALL_COMBINED=YES

Example:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(foo)
add_library(foo foo.cpp)
install(TARGETS foo DESTINATION lib)

Install:

$ cmake --build _builds --config Release --target install

Check library:

$ lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: i386 armv7 armv7s x86_64 arm64

$ otool -l _install/lib/libfoo.a | grep -A2 LC_VERSION_MIN_IPHONEOS
      cmd LC_VERSION_MIN_IPHONEOS
  cmdsize 16
  version 9.3

Code Signing

Some build artifacts for the embedded Apple platforms require mandatory code signing. If the Xcode generator is being used and code signing is required or desired, the developmemt team ID can be specified via the CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM CMake variable. This team ID will then be included in the generated Xcode project. By default, CMake avoids the need for code signing during the internal configuration phase (i.e compiler ID and feature detection).

Switching Between Device and Simulator

When configuring for any of the embedded platforms, one can target either real devices or the simulator. Both have their own separate SDK, but CMake only supports specifying a single SDK for the configuration phase. This means the developer must select one or the other at configuration time. When using the Xcode generator, this is less of a limitation because Xcode still allows you to build for either a device or a simulator, even though configuration was only performed for one of the two. From within the Xcode IDE, builds are performed for the selected “destination” platform. When building from the command line, the desired sdk can be specified directly by passing a -sdk option to the underlying build tool (xcodebuild). For example:

$ cmake --build ... -- -sdk iphonesimulator

Please note that checks made during configuration were performed against the configure-time SDK and might not hold true for other SDKs. Commands like find_package(), find_library(), etc. store and use details only for the configured SDK/platform, so they can be problematic if wanting to switch between device and simulator builds. You can follow the next rules to make device + simulator configuration work:

  • Use explicit -l linker flag, e.g. target_link_libraries(foo PUBLIC "-lz")
  • Use explicit -framework linker flag, e.g. target_link_libraries(foo PUBLIC "-framework CoreFoundation")
  • Use find_package() only for libraries installed with CMAKE_IOS_INSTALL_COMBINED feature


cmake-variables(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cmake-variables(7)

Contents

  • cmake-variables(7)
    • Variables that Provide Information
    • Variables that Change Behavior
    • Variables that Describe the System
    • Variables that Control the Build
    • Variables for Languages
    • Variables for CTest
    • Variables for CPack
    • Variable Expansion Operators
    • Internal Variables

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

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

Variables that Provide Information

  • CMAKE_AR
  • CMAKE_ARGC
  • CMAKE_ARGV0
  • CMAKE_BINARY_DIR
  • CMAKE_BUILD_TOOL
  • CMAKE_CACHEFILE_DIR
  • CMAKE_CACHE_MAJOR_VERSION
  • CMAKE_CACHE_MINOR_VERSION
  • CMAKE_CACHE_PATCH_VERSION
  • CMAKE_CFG_INTDIR
  • CMAKE_COMMAND
  • CMAKE_CPACK_COMMAND
  • CMAKE_CROSSCOMPILING
  • CMAKE_CROSSCOMPILING_EMULATOR
  • CMAKE_CTEST_COMMAND
  • CMAKE_CURRENT_BINARY_DIR
  • CMAKE_CURRENT_LIST_DIR
  • CMAKE_CURRENT_LIST_FILE
  • CMAKE_CURRENT_LIST_LINE
  • CMAKE_CURRENT_SOURCE_DIR
  • CMAKE_DIRECTORY_LABELS
  • CMAKE_DL_LIBS
  • CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION
  • CMAKE_EDIT_COMMAND
  • CMAKE_EXECUTABLE_SUFFIX
  • CMAKE_EXTRA_GENERATOR
  • CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES
  • CMAKE_FIND_PACKAGE_NAME
  • CMAKE_FIND_PACKAGE_SORT_DIRECTION
  • CMAKE_FIND_PACKAGE_SORT_ORDER
  • CMAKE_GENERATOR
  • CMAKE_GENERATOR_INSTANCE
  • CMAKE_GENERATOR_PLATFORM
  • CMAKE_GENERATOR_TOOLSET
  • CMAKE_IMPORT_LIBRARY_PREFIX
  • CMAKE_IMPORT_LIBRARY_SUFFIX
  • CMAKE_JOB_POOL_COMPILE
  • CMAKE_JOB_POOL_LINK
  • CMAKE_JOB_POOLS
  • CMAKE_<LANG>_COMPILER_AR
  • CMAKE_<LANG>_COMPILER_RANLIB
  • CMAKE_LINK_LIBRARY_SUFFIX
  • CMAKE_LINK_SEARCH_END_STATIC
  • CMAKE_LINK_SEARCH_START_STATIC
  • CMAKE_MAJOR_VERSION
  • CMAKE_MAKE_PROGRAM
  • CMAKE_MATCH_COUNT
  • CMAKE_MATCH_<n>
  • CMAKE_MINIMUM_REQUIRED_VERSION
  • CMAKE_MINOR_VERSION
  • CMAKE_NETRC
  • CMAKE_NETRC_FILE
  • CMAKE_PARENT_LIST_FILE
  • CMAKE_PATCH_VERSION
  • CMAKE_PROJECT_DESCRIPTION
  • CMAKE_PROJECT_HOMEPAGE_URL
  • CMAKE_PROJECT_NAME
  • CMAKE_PROJECT_VERSION
  • CMAKE_PROJECT_VERSION_MAJOR
  • CMAKE_PROJECT_VERSION_MINOR
  • CMAKE_PROJECT_VERSION_PATCH
  • CMAKE_PROJECT_VERSION_TWEAK
  • CMAKE_RANLIB
  • CMAKE_ROOT
  • CMAKE_RULE_MESSAGES
  • CMAKE_SCRIPT_MODE_FILE
  • CMAKE_SHARED_LIBRARY_PREFIX
  • CMAKE_SHARED_LIBRARY_SUFFIX
  • CMAKE_SHARED_MODULE_PREFIX
  • CMAKE_SHARED_MODULE_SUFFIX
  • CMAKE_SIZEOF_VOID_P
  • CMAKE_SKIP_INSTALL_RULES
  • CMAKE_SKIP_RPATH
  • CMAKE_SOURCE_DIR
  • CMAKE_STATIC_LIBRARY_PREFIX
  • CMAKE_STATIC_LIBRARY_SUFFIX
  • CMAKE_TOOLCHAIN_FILE
  • CMAKE_TWEAK_VERSION
  • CMAKE_VERBOSE_MAKEFILE
  • CMAKE_VERSION
  • CMAKE_VS_DEVENV_COMMAND
  • CMAKE_VS_MSBUILD_COMMAND
  • CMAKE_VS_NsightTegra_VERSION
  • CMAKE_VS_PLATFORM_NAME
  • CMAKE_VS_PLATFORM_TOOLSET
  • CMAKE_VS_PLATFORM_TOOLSET_CUDA
  • CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE
  • CMAKE_VS_PLATFORM_TOOLSET_VERSION
  • CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
  • CMAKE_XCODE_GENERATE_SCHEME
  • CMAKE_XCODE_PLATFORM_TOOLSET
  • <PROJECT-NAME>_BINARY_DIR
  • <PROJECT-NAME>_DESCRIPTION
  • <PROJECT-NAME>_HOMEPAGE_URL
  • <PROJECT-NAME>_SOURCE_DIR
  • <PROJECT-NAME>_VERSION
  • <PROJECT-NAME>_VERSION_MAJOR
  • <PROJECT-NAME>_VERSION_MINOR
  • <PROJECT-NAME>_VERSION_PATCH
  • <PROJECT-NAME>_VERSION_TWEAK
  • PROJECT_BINARY_DIR
  • PROJECT_DESCRIPTION
  • PROJECT_HOMEPAGE_URL
  • PROJECT_NAME
  • PROJECT_SOURCE_DIR
  • PROJECT_VERSION
  • PROJECT_VERSION_MAJOR
  • PROJECT_VERSION_MINOR
  • PROJECT_VERSION_PATCH
  • PROJECT_VERSION_TWEAK

Variables that Change Behavior

  • BUILD_SHARED_LIBS
  • CMAKE_ABSOLUTE_DESTINATION_FILES
  • CMAKE_APPBUNDLE_PATH
  • CMAKE_AUTOMOC_RELAXED_MODE
  • CMAKE_BACKWARDS_COMPATIBILITY
  • CMAKE_BUILD_TYPE
  • CMAKE_CODEBLOCKS_COMPILER_ID
  • CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES
  • CMAKE_CODELITE_USE_TARGETS
  • CMAKE_COLOR_MAKEFILE
  • CMAKE_CONFIGURATION_TYPES
  • CMAKE_DEBUG_TARGET_PROPERTIES
  • CMAKE_DEPENDS_IN_PROJECT_ONLY
  • CMAKE_DISABLE_FIND_PACKAGE_<PackageName>
  • CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES
  • CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT
  • CMAKE_ECLIPSE_MAKE_ARGUMENTS
  • CMAKE_ECLIPSE_VERSION
  • CMAKE_ERROR_DEPRECATED
  • CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
  • CMAKE_EXPORT_COMPILE_COMMANDS
  • CMAKE_EXPORT_NO_PACKAGE_REGISTRY
  • CMAKE_FIND_APPBUNDLE
  • CMAKE_FIND_FRAMEWORK
  • CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX
  • CMAKE_FIND_LIBRARY_PREFIXES
  • CMAKE_FIND_LIBRARY_SUFFIXES
  • CMAKE_FIND_NO_INSTALL_PREFIX
  • CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY
  • CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY
  • CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS
  • CMAKE_FIND_PACKAGE_WARN_NO_MODULE
  • CMAKE_FIND_ROOT_PATH
  • CMAKE_FIND_ROOT_PATH_MODE_INCLUDE
  • CMAKE_FIND_ROOT_PATH_MODE_LIBRARY
  • CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
  • CMAKE_FIND_ROOT_PATH_MODE_PROGRAM
  • CMAKE_FRAMEWORK_PATH
  • CMAKE_IGNORE_PATH
  • CMAKE_INCLUDE_DIRECTORIES_BEFORE
  • CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE
  • CMAKE_INCLUDE_PATH
  • CMAKE_INSTALL_DEFAULT_COMPONENT_NAME
  • CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
  • CMAKE_INSTALL_MESSAGE
  • CMAKE_INSTALL_PREFIX
  • CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT
  • CMAKE_LIBRARY_PATH
  • CMAKE_LINK_DIRECTORIES_BEFORE
  • CMAKE_MFC_FLAG
  • CMAKE_MAXIMUM_RECURSION_DEPTH
  • CMAKE_MODULE_PATH
  • CMAKE_POLICY_DEFAULT_CMP<NNNN>
  • CMAKE_POLICY_WARNING_CMP<NNNN>
  • CMAKE_PREFIX_PATH
  • CMAKE_PROGRAM_PATH
  • CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE
  • CMAKE_SKIP_INSTALL_ALL_DEPENDENCY
  • CMAKE_STAGING_PREFIX
  • CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS
  • CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE
  • CMAKE_SUPPRESS_REGENERATION
  • CMAKE_SYSROOT
  • CMAKE_SYSROOT_COMPILE
  • CMAKE_SYSROOT_LINK
  • CMAKE_SYSTEM_APPBUNDLE_PATH
  • CMAKE_SYSTEM_FRAMEWORK_PATH
  • CMAKE_SYSTEM_IGNORE_PATH
  • CMAKE_SYSTEM_INCLUDE_PATH
  • CMAKE_SYSTEM_LIBRARY_PATH
  • CMAKE_SYSTEM_PREFIX_PATH
  • CMAKE_SYSTEM_PROGRAM_PATH
  • CMAKE_USER_MAKE_RULES_OVERRIDE
  • CMAKE_WARN_DEPRECATED
  • CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
  • CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY
  • CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER
  • CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
  • CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
  • CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
  • CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
  • CMAKE_XCODE_SCHEME_GUARD_MALLOC
  • CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP
  • CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES
  • CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE
  • CMAKE_XCODE_SCHEME_MALLOC_STACK
  • CMAKE_XCODE_SCHEME_THREAD_SANITIZER
  • CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP
  • CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER
  • CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP
  • CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS
  • <PackageName>_ROOT

Variables that Describe the System

  • ANDROID
  • APPLE
  • BORLAND
  • CMAKE_CL_64
  • CMAKE_COMPILER_2005
  • CMAKE_HOST_APPLE
  • CMAKE_HOST_SOLARIS
  • CMAKE_HOST_SYSTEM
  • CMAKE_HOST_SYSTEM_NAME
  • CMAKE_HOST_SYSTEM_PROCESSOR
  • CMAKE_HOST_SYSTEM_VERSION
  • CMAKE_HOST_UNIX
  • CMAKE_HOST_WIN32
  • CMAKE_LIBRARY_ARCHITECTURE
  • CMAKE_LIBRARY_ARCHITECTURE_REGEX
  • CMAKE_OBJECT_PATH_MAX
  • CMAKE_SYSTEM
  • CMAKE_SYSTEM_NAME
  • CMAKE_SYSTEM_PROCESSOR
  • CMAKE_SYSTEM_VERSION
  • CYGWIN
  • GHS-MULTI
  • IOS
  • MINGW
  • MSVC
  • MSVC10
  • MSVC11
  • MSVC12
  • MSVC14
  • MSVC60
  • MSVC70
  • MSVC71
  • MSVC80
  • MSVC90
  • MSVC_IDE
  • MSVC_TOOLSET_VERSION
  • MSVC_VERSION
  • MSYS
  • UNIX
  • WIN32
  • WINCE
  • WINDOWS_PHONE
  • WINDOWS_STORE
  • XCODE
  • XCODE_VERSION

Variables that Control the Build

  • CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS
  • CMAKE_ANDROID_API
  • CMAKE_ANDROID_API_MIN
  • CMAKE_ANDROID_ARCH
  • CMAKE_ANDROID_ARCH_ABI
  • CMAKE_ANDROID_ARM_MODE
  • CMAKE_ANDROID_ARM_NEON
  • CMAKE_ANDROID_ASSETS_DIRECTORIES
  • CMAKE_ANDROID_GUI
  • CMAKE_ANDROID_JAR_DEPENDENCIES
  • CMAKE_ANDROID_JAR_DIRECTORIES
  • CMAKE_ANDROID_JAVA_SOURCE_DIR
  • CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES
  • CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES
  • CMAKE_ANDROID_NDK
  • CMAKE_ANDROID_NDK_DEPRECATED_HEADERS
  • CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG
  • CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION
  • CMAKE_ANDROID_PROCESS_MAX
  • CMAKE_ANDROID_PROGUARD
  • CMAKE_ANDROID_PROGUARD_CONFIG_PATH
  • CMAKE_ANDROID_SECURE_PROPS_PATH
  • CMAKE_ANDROID_SKIP_ANT_STEP
  • CMAKE_ANDROID_STANDALONE_TOOLCHAIN
  • CMAKE_ANDROID_STL_TYPE
  • CMAKE_ARCHIVE_OUTPUT_DIRECTORY
  • CMAKE_ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>
  • CMAKE_AUTOGEN_ORIGIN_DEPENDS
  • CMAKE_AUTOGEN_PARALLEL
  • CMAKE_AUTOGEN_VERBOSE
  • CMAKE_AUTOMOC
  • CMAKE_AUTOMOC_COMPILER_PREDEFINES
  • CMAKE_AUTOMOC_DEPEND_FILTERS
  • CMAKE_AUTOMOC_MACRO_NAMES
  • CMAKE_AUTOMOC_MOC_OPTIONS
  • CMAKE_AUTORCC
  • CMAKE_AUTORCC_OPTIONS
  • CMAKE_AUTOUIC
  • CMAKE_AUTOUIC_OPTIONS
  • CMAKE_AUTOUIC_SEARCH_PATHS
  • CMAKE_BUILD_RPATH
  • CMAKE_BUILD_RPATH_USE_ORIGIN
  • CMAKE_BUILD_WITH_INSTALL_NAME_DIR
  • CMAKE_BUILD_WITH_INSTALL_RPATH
  • CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY
  • CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>
  • CMAKE_<CONFIG>_POSTFIX
  • CMAKE_CUDA_SEPARABLE_COMPILATION
  • CMAKE_DEBUG_POSTFIX
  • CMAKE_ENABLE_EXPORTS
  • CMAKE_EXE_LINKER_FLAGS
  • CMAKE_EXE_LINKER_FLAGS_<CONFIG>
  • CMAKE_EXE_LINKER_FLAGS_<CONFIG>_INIT
  • CMAKE_EXE_LINKER_FLAGS_INIT
  • CMAKE_FOLDER
  • CMAKE_Fortran_FORMAT
  • CMAKE_Fortran_MODULE_DIRECTORY
  • CMAKE_GHS_NO_SOURCE_GROUP_FILE
  • CMAKE_GLOBAL_AUTOGEN_TARGET
  • CMAKE_GLOBAL_AUTOGEN_TARGET_NAME
  • CMAKE_GLOBAL_AUTORCC_TARGET
  • CMAKE_GLOBAL_AUTORCC_TARGET_NAME
  • CMAKE_GNUtoMS
  • CMAKE_INCLUDE_CURRENT_DIR
  • CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE
  • CMAKE_INSTALL_NAME_DIR
  • CMAKE_INSTALL_RPATH
  • CMAKE_INSTALL_RPATH_USE_LINK_PATH
  • CMAKE_INTERPROCEDURAL_OPTIMIZATION
  • CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
  • CMAKE_IOS_INSTALL_COMBINED
  • CMAKE_<LANG>_CLANG_TIDY
  • CMAKE_<LANG>_COMPILER_LAUNCHER
  • CMAKE_<LANG>_CPPCHECK
  • CMAKE_<LANG>_CPPLINT
  • CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE
  • CMAKE_<LANG>_VISIBILITY_PRESET
  • CMAKE_LIBRARY_OUTPUT_DIRECTORY
  • CMAKE_LIBRARY_OUTPUT_DIRECTORY_<CONFIG>
  • CMAKE_LIBRARY_PATH_FLAG
  • CMAKE_LINK_DEF_FILE_FLAG
  • CMAKE_LINK_DEPENDS_NO_SHARED
  • CMAKE_LINK_INTERFACE_LIBRARIES
  • CMAKE_LINK_LIBRARY_FILE_FLAG
  • CMAKE_LINK_LIBRARY_FLAG
  • CMAKE_LINK_WHAT_YOU_USE
  • CMAKE_MACOSX_BUNDLE
  • CMAKE_MACOSX_RPATH
  • CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>
  • CMAKE_MODULE_LINKER_FLAGS
  • CMAKE_MODULE_LINKER_FLAGS_<CONFIG>
  • CMAKE_MODULE_LINKER_FLAGS_<CONFIG>_INIT
  • CMAKE_MODULE_LINKER_FLAGS_INIT
  • CMAKE_MSVCIDE_RUN_PATH
  • CMAKE_NINJA_OUTPUT_PATH_PREFIX
  • CMAKE_NO_BUILTIN_CHRPATH
  • CMAKE_NO_SYSTEM_FROM_IMPORTED
  • CMAKE_OSX_ARCHITECTURES
  • CMAKE_OSX_DEPLOYMENT_TARGET
  • CMAKE_OSX_SYSROOT
  • CMAKE_PDB_OUTPUT_DIRECTORY
  • CMAKE_PDB_OUTPUT_DIRECTORY_<CONFIG>
  • CMAKE_POSITION_INDEPENDENT_CODE
  • CMAKE_RUNTIME_OUTPUT_DIRECTORY
  • CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG>
  • CMAKE_SHARED_LINKER_FLAGS
  • CMAKE_SHARED_LINKER_FLAGS_<CONFIG>
  • CMAKE_SHARED_LINKER_FLAGS_<CONFIG>_INIT
  • CMAKE_SHARED_LINKER_FLAGS_INIT
  • CMAKE_SKIP_BUILD_RPATH
  • CMAKE_SKIP_INSTALL_RPATH
  • CMAKE_STATIC_LINKER_FLAGS
  • CMAKE_STATIC_LINKER_FLAGS_<CONFIG>
  • CMAKE_STATIC_LINKER_FLAGS_<CONFIG>_INIT
  • CMAKE_STATIC_LINKER_FLAGS_INIT
  • CMAKE_TRY_COMPILE_CONFIGURATION
  • CMAKE_TRY_COMPILE_PLATFORM_VARIABLES
  • CMAKE_TRY_COMPILE_TARGET_TYPE
  • CMAKE_USE_RELATIVE_PATHS
  • CMAKE_VISIBILITY_INLINES_HIDDEN
  • CMAKE_VS_GLOBALS
  • CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD
  • CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD
  • CMAKE_VS_SDK_EXCLUDE_DIRECTORIES
  • CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES
  • CMAKE_VS_SDK_INCLUDE_DIRECTORIES
  • CMAKE_VS_SDK_LIBRARY_DIRECTORIES
  • CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES
  • CMAKE_VS_SDK_REFERENCE_DIRECTORIES
  • CMAKE_VS_SDK_SOURCE_DIRECTORIES
  • CMAKE_VS_WINRT_BY_DEFAULT
  • CMAKE_WIN32_EXECUTABLE
  • CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS
  • CMAKE_XCODE_ATTRIBUTE_<an-attribute>
  • EXECUTABLE_OUTPUT_PATH
  • LIBRARY_OUTPUT_PATH

Variables for Languages

  • CMAKE_COMPILER_IS_GNUCC
  • CMAKE_COMPILER_IS_GNUCXX
  • CMAKE_COMPILER_IS_GNUG77
  • CMAKE_CUDA_HOST_COMPILER
  • CMAKE_CUDA_EXTENSIONS
  • CMAKE_CUDA_STANDARD
  • CMAKE_CUDA_STANDARD_REQUIRED
  • CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES
  • CMAKE_CXX_COMPILE_FEATURES
  • CMAKE_CXX_EXTENSIONS
  • CMAKE_CXX_STANDARD
  • CMAKE_CXX_STANDARD_REQUIRED
  • CMAKE_C_COMPILE_FEATURES
  • CMAKE_C_EXTENSIONS
  • CMAKE_C_STANDARD
  • CMAKE_C_STANDARD_REQUIRED
  • CMAKE_Fortran_MODDIR_DEFAULT
  • CMAKE_Fortran_MODDIR_FLAG
  • CMAKE_Fortran_MODOUT_FLAG
  • CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE
  • CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX
  • CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX
  • CMAKE_<LANG>_ARCHIVE_APPEND
  • CMAKE_<LANG>_ARCHIVE_CREATE
  • CMAKE_<LANG>_ARCHIVE_FINISH
  • CMAKE_<LANG>_COMPILER
  • CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN
  • CMAKE_<LANG>_COMPILER_ID
  • CMAKE_<LANG>_COMPILER_LOADED
  • CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND
  • CMAKE_<LANG>_COMPILER_TARGET
  • CMAKE_<LANG>_COMPILER_VERSION
  • CMAKE_<LANG>_COMPILE_OBJECT
  • CMAKE_<LANG>_CREATE_SHARED_LIBRARY
  • CMAKE_<LANG>_CREATE_SHARED_MODULE
  • CMAKE_<LANG>_CREATE_STATIC_LIBRARY
  • CMAKE_<LANG>_FLAGS
  • CMAKE_<LANG>_FLAGS_<CONFIG>
  • CMAKE_<LANG>_FLAGS_<CONFIG>_INIT
  • CMAKE_<LANG>_FLAGS_DEBUG
  • CMAKE_<LANG>_FLAGS_DEBUG_INIT
  • CMAKE_<LANG>_FLAGS_INIT
  • CMAKE_<LANG>_FLAGS_MINSIZEREL
  • CMAKE_<LANG>_FLAGS_MINSIZEREL_INIT
  • CMAKE_<LANG>_FLAGS_RELEASE
  • CMAKE_<LANG>_FLAGS_RELEASE_INIT
  • CMAKE_<LANG>_FLAGS_RELWITHDEBINFO
  • CMAKE_<LANG>_FLAGS_RELWITHDEBINFO_INIT
  • CMAKE_<LANG>_IGNORE_EXTENSIONS
  • CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES
  • CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
  • CMAKE_<LANG>_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES
  • CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
  • CMAKE_<LANG>_LIBRARY_ARCHITECTURE
  • CMAKE_<LANG>_LINKER_PREFERENCE
  • CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES
  • CMAKE_<LANG>_LINKER_WRAPPER_FLAG
  • CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP
  • CMAKE_<LANG>_LINK_EXECUTABLE
  • CMAKE_<LANG>_OUTPUT_EXTENSION
  • CMAKE_<LANG>_SIMULATE_ID
  • CMAKE_<LANG>_SIMULATE_VERSION
  • CMAKE_<LANG>_SIZEOF_DATA_PTR
  • CMAKE_<LANG>_SOURCE_FILE_EXTENSIONS
  • CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES
  • CMAKE_<LANG>_STANDARD_LIBRARIES
  • CMAKE_Swift_LANGUAGE_VERSION
  • CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>

Variables for CTest

  • CTEST_BINARY_DIRECTORY
  • CTEST_BUILD_COMMAND
  • CTEST_BUILD_NAME
  • CTEST_BZR_COMMAND
  • CTEST_BZR_UPDATE_OPTIONS
  • CTEST_CHANGE_ID
  • CTEST_CHECKOUT_COMMAND
  • CTEST_CONFIGURATION_TYPE
  • CTEST_CONFIGURE_COMMAND
  • CTEST_COVERAGE_COMMAND
  • CTEST_COVERAGE_EXTRA_FLAGS
  • CTEST_CURL_OPTIONS
  • CTEST_CUSTOM_COVERAGE_EXCLUDE
  • CTEST_CUSTOM_ERROR_EXCEPTION
  • CTEST_CUSTOM_ERROR_MATCH
  • CTEST_CUSTOM_ERROR_POST_CONTEXT
  • CTEST_CUSTOM_ERROR_PRE_CONTEXT
  • CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE
  • CTEST_CUSTOM_MAXIMUM_NUMBER_OF_ERRORS
  • CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS
  • CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE
  • CTEST_CUSTOM_MEMCHECK_IGNORE
  • CTEST_CUSTOM_POST_MEMCHECK
  • CTEST_CUSTOM_POST_TEST
  • CTEST_CUSTOM_PRE_MEMCHECK
  • CTEST_CUSTOM_PRE_TEST
  • CTEST_CUSTOM_TESTS_IGNORE
  • CTEST_CUSTOM_WARNING_EXCEPTION
  • CTEST_CUSTOM_WARNING_MATCH
  • CTEST_CVS_CHECKOUT
  • CTEST_CVS_COMMAND
  • CTEST_CVS_UPDATE_OPTIONS
  • CTEST_DROP_LOCATION
  • CTEST_DROP_METHOD
  • CTEST_DROP_SITE
  • CTEST_DROP_SITE_CDASH
  • CTEST_DROP_SITE_PASSWORD
  • CTEST_DROP_SITE_USER
  • CTEST_EXTRA_COVERAGE_GLOB
  • CTEST_GIT_COMMAND
  • CTEST_GIT_INIT_SUBMODULES
  • CTEST_GIT_UPDATE_CUSTOM
  • CTEST_GIT_UPDATE_OPTIONS
  • CTEST_HG_COMMAND
  • CTEST_HG_UPDATE_OPTIONS
  • CTEST_LABELS_FOR_SUBPROJECTS
  • CTEST_MEMORYCHECK_COMMAND
  • CTEST_MEMORYCHECK_COMMAND_OPTIONS
  • CTEST_MEMORYCHECK_SANITIZER_OPTIONS
  • CTEST_MEMORYCHECK_SUPPRESSIONS_FILE
  • CTEST_MEMORYCHECK_TYPE
  • CTEST_NIGHTLY_START_TIME
  • CTEST_P4_CLIENT
  • CTEST_P4_COMMAND
  • CTEST_P4_OPTIONS
  • CTEST_P4_UPDATE_OPTIONS
  • CTEST_RUN_CURRENT_SCRIPT
  • CTEST_SCP_COMMAND
  • CTEST_SITE
  • CTEST_SUBMIT_URL
  • CTEST_SOURCE_DIRECTORY
  • CTEST_SVN_COMMAND
  • CTEST_SVN_OPTIONS
  • CTEST_SVN_UPDATE_OPTIONS
  • CTEST_TEST_LOAD
  • CTEST_TEST_TIMEOUT
  • CTEST_TRIGGER_SITE
  • CTEST_UPDATE_COMMAND
  • CTEST_UPDATE_OPTIONS
  • CTEST_UPDATE_VERSION_ONLY
  • CTEST_USE_LAUNCHERS

Variables for CPack

  • CPACK_ABSOLUTE_DESTINATION_FILES
  • CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY
  • CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
  • CPACK_INCLUDE_TOPLEVEL_DIRECTORY
  • CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
  • CPACK_INSTALL_SCRIPT
  • CPACK_PACKAGING_INSTALL_PREFIX
  • CPACK_SET_DESTDIR
  • CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION

Variable Expansion Operators

  • CACHE
  • ENV

Internal Variables

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

  • CMAKE_HOME_DIRECTORY
  • CMAKE_INTERNAL_PLATFORM_ABI
  • CMAKE_<LANG>_COMPILER_ABI
  • CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID
  • CMAKE_<LANG>_COMPILER_VERSION_INTERNAL
  • CMAKE_<LANG>_PLATFORM_ID
  • CMAKE_NOT_USING_CONFIG_FLAGS
  • CMAKE_VS_INTEL_Fortran_PROJECT_VERSION


CMAKE_AR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_AR

Name of archiving tool for static libraries.

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

  • cmake-variables(7) »


CMAKE_ARGC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_ARGV0 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_BINARY_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_BINARY_DIR

The path to the top level of the build tree.

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

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

  • cmake-variables(7) »


CMAKE_BUILD_TOOL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_BUILD_TOOL

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

  • cmake-variables(7) »


CMAKE_CACHEFILE_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CACHEFILE_DIR

The directory with the CMakeCache.txt file.

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

  • cmake-variables(7) »


CMAKE_CACHE_MAJOR_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_CACHE_MINOR_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_CACHE_PATCH_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_CFG_INTDIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CFG_INTDIR

Build-time reference to per-configuration output subdirectory.

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

$(ConfigurationName) = Visual Studio 9
$(Configuration)     = Visual Studio 10
$(CONFIGURATION)     = Xcode
.                    = Make-based tools

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-variables(7) »


CMAKE_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_CPACK_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CPACK_COMMAND

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

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

  • cmake-variables(7) »


CMAKE_CROSSCOMPILING — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CROSSCOMPILING

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

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

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

  • cmake-variables(7) »


CMAKE_CROSSCOMPILING_EMULATOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CROSSCOMPILING_EMULATOR

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.

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

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

  • cmake-variables(7) »


CMAKE_CTEST_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CTEST_COMMAND

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

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

  • cmake-variables(7) »


CMAKE_CURRENT_BINARY_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CURRENT_BINARY_DIR

The path to the binary directory currently being processed.

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

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

  • cmake-variables(7) »


CMAKE_CURRENT_LIST_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_CURRENT_LIST_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_CURRENT_LIST_LINE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


CMAKE_CURRENT_SOURCE_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CURRENT_SOURCE_DIR

The path to the source directory currently being processed.

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

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

  • cmake-variables(7) »


CMAKE_DIRECTORY_LABELS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_DIRECTORY_LABELS

Specify labels for the current directory.

This is used to initialize the LABELS directory property.

  • cmake-variables(7) »


CMAKE_DL_LIBS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION

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.

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-variables(7) »


CMAKE_EDIT_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_EDIT_COMMAND

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

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

  • cmake-variables(7) »


CMAKE_EXECUTABLE_SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_EXECUTABLE_SUFFIX

The suffix for executables on this platform.

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

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

  • cmake-variables(7) »


CMAKE_EXTRA_GENERATOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_EXTRA_GENERATOR

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

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

  • cmake-variables(7) »


CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_FIND_PACKAGE_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_PACKAGE_NAME

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

  • cmake-variables(7) »


CMAKE_FIND_PACKAGE_SORT_DIRECTION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_PACKAGE_SORT_DIRECTION

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

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

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

  • cmake-variables(7) »


CMAKE_FIND_PACKAGE_SORT_ORDER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_PACKAGE_SORT_ORDER

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

NONE
Default. No attempt is done to sort packages. The first valid package found will be selected.
NAME
Sort packages lexicographically before selecting one.
NATURAL
Sort packages using natural order (see strverscmp(3) manual), i.e. such that contiguous digits are compared as whole numbers.

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

  • libX-1.1.0
  • libX-1.2.9
  • libX-1.2.10

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

set(CMAKE_FIND_PACKAGE_SORT_ORDER NATURAL)
find_package(libX CONFIG)

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

  • cmake-variables(7) »


CMAKE_GENERATOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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

  • cmake-variables(7) »


CMAKE_GENERATOR_INSTANCE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_GENERATOR_INSTANCE

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 after a default instance is chosen when a build tree is first configured, the value will be available in this variable.

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

Instance specification is supported only on specific generators:

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

See native build system documentation for allowed instance values.

  • cmake-variables(7) »


CMAKE_GENERATOR_PLATFORM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_GENERATOR_PLATFORM

Generator-specific target platform specification provided by user.

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

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

Platform specification is supported only on specific generators:

  • For Visual Studio Generators with VS 2005 and above this specifies the target architecture.
  • For Green Hills MULTI this specifies the target architecture.

See native build system documentation for allowed platform names.

Visual Studio Platform Selection

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

  • cmake-variables(7) »


CMAKE_GENERATOR_TOOLSET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_GENERATOR_TOOLSET

Native build system toolset specification provided by user.

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

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

Toolset specification is supported only on specific generators:

  • Visual Studio Generators for VS 2010 and above
  • The Xcode generator for Xcode 3.0 and above
  • The Green Hills MULTI generator

See native build system documentation for allowed toolset names.

Visual Studio Toolset Selection

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

  • toolset
  • toolset[,key=value]*
  • key=value[,key=value]*

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

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

cuda=<version>
Specify the CUDA toolkit version to use. Supported by VS 2010 and above with the CUDA toolkit VS integration installed. See the CMAKE_VS_PLATFORM_TOOLSET_CUDA variable.
host=<arch>
Specify the host tools architecture as x64 or x86. Supported by VS 2013 and above. See the CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE variable.
version=<version>
Specify the toolset version to use. Supported by VS 2017 and above with the specified toolset installed. See the CMAKE_VS_PLATFORM_TOOLSET_VERSION variable.

  • cmake-variables(7) »


CMAKE_IMPORT_LIBRARY_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_IMPORT_LIBRARY_SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_JOB_POOL_COMPILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_JOB_POOL_LINK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_JOB_POOLS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_JOB_POOLS

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-variables(7) »


CMAKE_<LANG>_COMPILER_AR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_AR

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

See also CMAKE_AR.

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_RANLIB — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_RANLIB

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

See also CMAKE_RANLIB.

  • cmake-variables(7) »


CMAKE_LINK_LIBRARY_SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_LINK_SEARCH_END_STATIC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_LINK_SEARCH_END_STATIC

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, it’s value is also used by the try_compile() command.

See also CMAKE_LINK_SEARCH_START_STATIC.

  • cmake-variables(7) »


CMAKE_LINK_SEARCH_START_STATIC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_LINK_SEARCH_START_STATIC

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, it’s value is also used by the try_compile() command.

See also CMAKE_LINK_SEARCH_END_STATIC.

  • cmake-variables(7) »


CMAKE_MAJOR_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MAJOR_VERSION

First version number component of the CMAKE_VERSION variable.

  • cmake-variables(7) »


CMAKE_MAKE_PROGRAM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MAKE_PROGRAM

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

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

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

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

  • The Ninja generator sets this to ninja.

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

  • The Xcode generator sets this to xcodebuild (or possibly an otherwise undocumented cmakexbuild wrapper implementing some workarounds).

    This generator prefers to lookup the build tool at build time rather than to store CMAKE_MAKE_PROGRAM in the CMake cache ahead of time. This is because xcodebuild is easy to find, the cmakexbuild wrapper is needed only for older Xcode versions, and the path to cmakexbuild may be outdated if CMake itself moves.

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

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

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

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

  • The Green Hills MULTI generator sets this to the full path to gbuild.exe based upon the toolset being used.

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

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

  • cmake-variables(7) »


CMAKE_MATCH_COUNT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MATCH_COUNT

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-variables(7) »


CMAKE_MATCH_<n> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_MINIMUM_REQUIRED_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MINIMUM_REQUIRED_VERSION

The <min> version of CMake given to the most recent call to the cmake_minimum_required(VERSION) command.

  • cmake-variables(7) »


CMAKE_MINOR_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MINOR_VERSION

Second version number component of the CMAKE_VERSION variable.

  • cmake-variables(7) »


CMAKE_NETRC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_NETRC

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

The local option takes precedence over this variable.

  • cmake-variables(7) »


CMAKE_NETRC_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_NETRC_FILE

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

The local option takes precedence over this variable.

  • cmake-variables(7) »


CMAKE_PARENT_LIST_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_PATCH_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PATCH_VERSION

Third version number component of the CMAKE_VERSION variable.

  • cmake-variables(7) »


CMAKE_PROJECT_DESCRIPTION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PROJECT_DESCRIPTION

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-variables(7) »


CMAKE_PROJECT_HOMEPAGE_URL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PROJECT_HOMEPAGE_URL

The homepage URL of the top level project.

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

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

And sub/CMakeLists.txt with the following contents:

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

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

CMAKE_PROJECT_HOMEPAGE_URL = http://second.example.com

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

  • cmake-variables(7) »


CMAKE_PROJECT_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_PROJECT_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PROJECT_VERSION

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-variables(7) »


CMAKE_PROJECT_VERSION_MAJOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PROJECT_VERSION_MAJOR

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-variables(7) »


CMAKE_PROJECT_VERSION_MINOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PROJECT_VERSION_MINOR

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-variables(7) »


CMAKE_PROJECT_VERSION_PATCH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PROJECT_VERSION_PATCH

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-variables(7) »


CMAKE_PROJECT_VERSION_TWEAK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PROJECT_VERSION_TWEAK

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-variables(7) »


CMAKE_RANLIB — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_ROOT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_RULE_MESSAGES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_RULE_MESSAGES

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-variables(7) »


CMAKE_SCRIPT_MODE_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SCRIPT_MODE_FILE

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

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

  • cmake-variables(7) »


CMAKE_SHARED_LIBRARY_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SHARED_LIBRARY_SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SHARED_MODULE_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SHARED_MODULE_SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SIZEOF_VOID_P — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SIZEOF_VOID_P

Size of a void pointer.

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

  • cmake-variables(7) »


CMAKE_SKIP_INSTALL_RULES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SKIP_INSTALL_RULES

Whether to disable generation of installation rules.

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

  • cmake-variables(7) »


CMAKE_SKIP_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SKIP_RPATH

If true, do not add run time path information.

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

  • cmake-variables(7) »


CMAKE_SOURCE_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SOURCE_DIR

The path to the top level of the source tree.

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

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

  • cmake-variables(7) »


CMAKE_STATIC_LIBRARY_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_STATIC_LIBRARY_SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_TOOLCHAIN_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_TOOLCHAIN_FILE

Path to toolchain file supplied to cmake(1).

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

  • cmake-variables(7) »


CMAKE_TWEAK_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_TWEAK_VERSION

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

Note

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

  • cmake-variables(7) »


CMAKE_VERBOSE_MAKEFILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VERSION

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

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

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

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

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

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

Individual component values are also available in variables:

  • CMAKE_MAJOR_VERSION
  • CMAKE_MINOR_VERSION
  • CMAKE_PATCH_VERSION
  • CMAKE_TWEAK_VERSION

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

Note

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

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

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

  • cmake-variables(7) »


CMAKE_VS_DEVENV_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_DEVENV_COMMAND

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

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

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

  • cmake-variables(7) »


CMAKE_VS_MSBUILD_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_MSBUILD_COMMAND

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

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

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

  • cmake-variables(7) »


CMAKE_VS_NsightTegra_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_NsightTegra_VERSION

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-variables(7) »


CMAKE_VS_PLATFORM_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_PLATFORM_NAME

Visual Studio target platform name.

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

  • cmake-variables(7) »


CMAKE_VS_PLATFORM_TOOLSET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_VS_PLATFORM_TOOLSET_CUDA — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_PLATFORM_TOOLSET_CUDA

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. 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-variables(7) »


CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE

Visual Studio preferred tool architecture.

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

  • cmake-variables(7) »


CMAKE_VS_PLATFORM_TOOLSET_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_PLATFORM_TOOLSET_VERSION

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.

  • cmake-variables(7) »


CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION

Visual Studio Windows Target Platform Version.

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

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

  • cmake-variables(7) »


CMAKE_XCODE_GENERATE_SCHEME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_GENERATE_SCHEME

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.

The following target properties overwrite the default of the corresponding settings on the “Diagnostic” tab for each schema file. Each of those is initialized by the respective CMAKE_ variable at target creation time.

  • XCODE_SCHEME_ADDRESS_SANITIZER
  • XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
  • XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
  • XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
  • XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
  • XCODE_SCHEME_GUARD_MALLOC
  • XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP
  • XCODE_SCHEME_MALLOC_GUARD_EDGES
  • XCODE_SCHEME_MALLOC_SCRIBBLE
  • XCODE_SCHEME_MALLOC_STACK
  • XCODE_SCHEME_THREAD_SANITIZER
  • XCODE_SCHEME_THREAD_SANITIZER_STOP
  • XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER
  • XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP
  • XCODE_SCHEME_ZOMBIE_OBJECTS

The following target properties will be applied on the “Info” and “Arguments” tab:

  • XCODE_SCHEME_ARGUMENTS
  • XCODE_SCHEME_ENVIRONMENT
  • XCODE_SCHEME_EXECUTABLE

  • cmake-variables(7) »


CMAKE_XCODE_PLATFORM_TOOLSET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_PLATFORM_TOOLSET

Xcode compiler selection.

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

  • cmake-variables(7) »


<PROJECT-NAME>_BINARY_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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

  • cmake-variables(7) »


<PROJECT-NAME>_DESCRIPTION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

<PROJECT-NAME>_DESCRIPTION

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

  • cmake-variables(7) »


<PROJECT-NAME>_HOMEPAGE_URL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

<PROJECT-NAME>_HOMEPAGE_URL

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

  • cmake-variables(7) »


<PROJECT-NAME>_SOURCE_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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

  • cmake-variables(7) »


<PROJECT-NAME>_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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

  • cmake-variables(7) »


<PROJECT-NAME>_VERSION_MAJOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

<PROJECT-NAME>_VERSION_MAJOR

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

  • cmake-variables(7) »


<PROJECT-NAME>_VERSION_MINOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

<PROJECT-NAME>_VERSION_MINOR

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

  • cmake-variables(7) »


<PROJECT-NAME>_VERSION_PATCH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

<PROJECT-NAME>_VERSION_PATCH

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

  • cmake-variables(7) »


<PROJECT-NAME>_VERSION_TWEAK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

<PROJECT-NAME>_VERSION_TWEAK

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

  • cmake-variables(7) »


PROJECT_BINARY_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

PROJECT_BINARY_DIR

Full path to build directory for project.

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

  • cmake-variables(7) »


PROJECT_DESCRIPTION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

PROJECT_DESCRIPTION

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.

  • cmake-variables(7) »


PROJECT_HOMEPAGE_URL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

PROJECT_HOMEPAGE_URL

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.

  • cmake-variables(7) »


PROJECT_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


PROJECT_SOURCE_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

PROJECT_SOURCE_DIR

Top level source directory for the current project.

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

  • cmake-variables(7) »


PROJECT_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


PROJECT_VERSION_MAJOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

PROJECT_VERSION_MAJOR

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

  • cmake-variables(7) »


PROJECT_VERSION_MINOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

PROJECT_VERSION_MINOR

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

  • cmake-variables(7) »


PROJECT_VERSION_PATCH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

PROJECT_VERSION_PATCH

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

  • cmake-variables(7) »


PROJECT_VERSION_TWEAK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

PROJECT_VERSION_TWEAK

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

  • cmake-variables(7) »


BUILD_SHARED_LIBS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

BUILD_SHARED_LIBS

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

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

  • cmake-variables(7) »


CMAKE_ABSOLUTE_DESTINATION_FILES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_APPBUNDLE_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_APPBUNDLE_PATH

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

  • cmake-variables(7) »


CMAKE_AUTOMOC_RELAXED_MODE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_AUTOMOC_RELAXED_MODE

Switch between strict and relaxed automoc mode.

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

Relaxed mode has to be enabled for KDE4 compatibility.

  • cmake-variables(7) »


CMAKE_BACKWARDS_COMPATIBILITY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_BACKWARDS_COMPATIBILITY

Deprecated. See CMake Policy CMP0001 documentation.

  • cmake-variables(7) »


CMAKE_BUILD_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_BUILD_TYPE

Specifies the build type on single-configuration generators.

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

  • cmake-variables(7) »


CMAKE_CODEBLOCKS_COMPILER_ID — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CODEBLOCKS_COMPILER_ID

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-variables(7) »


CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES

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-variables(7) »


CMAKE_CODELITE_USE_TARGETS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CODELITE_USE_TARGETS

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-variables(7) »


CMAKE_COLOR_MAKEFILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_COLOR_MAKEFILE

Enables color output when using the Makefile Generators.

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

  • cmake-variables(7) »


CMAKE_CONFIGURATION_TYPES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CONFIGURATION_TYPES

Specifies the available build types on multi-config generators.

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

  • cmake-variables(7) »


CMAKE_DEBUG_TARGET_PROPERTIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_DEBUG_TARGET_PROPERTIES

Enables tracing output for target properties.

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

  • AUTOUIC_OPTIONS
  • COMPILE_DEFINITIONS
  • COMPILE_FEATURES
  • COMPILE_OPTIONS
  • INCLUDE_DIRECTORIES
  • LINK_DIRECTORIES
  • LINK_OPTIONS
  • POSITION_INDEPENDENT_CODE
  • SOURCES

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

  • cmake-variables(7) »


CMAKE_DEPENDS_IN_PROJECT_ONLY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_DEPENDS_IN_PROJECT_ONLY

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-variables(7) »


CMAKE_DISABLE_FIND_PACKAGE_<PackageName> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_DISABLE_FIND_PACKAGE_<PackageName>

Variable for disabling find_package() calls.

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

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

  • cmake-variables(7) »


CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES

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-variables(7) »


CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT

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-variables(7) »


CMAKE_ECLIPSE_MAKE_ARGUMENTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ECLIPSE_MAKE_ARGUMENTS

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-variables(7) »


CMAKE_ECLIPSE_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ECLIPSE_VERSION

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-variables(7) »


CMAKE_ERROR_DEPRECATED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_EXPORT_COMPILE_COMMANDS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_EXPORT_COMPILE_COMMANDS

Enable/Disable output of compile commands during generation.

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

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

  ...

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

Note

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

  • cmake-variables(7) »


CMAKE_EXPORT_NO_PACKAGE_REGISTRY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_EXPORT_NO_PACKAGE_REGISTRY

Disable the export(PACKAGE) command.

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.

See also Disabling the Package Registry.

  • cmake-variables(7) »


CMAKE_FIND_APPBUNDLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_APPBUNDLE

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

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

FIRST
Try to find application bundles before standard programs. This is the default on Darwin.
LAST
Try to find application bundles after standard programs.
ONLY
Only try to find application bundles.
NEVER
Never try to find application bundles.

  • cmake-variables(7) »


CMAKE_FIND_FRAMEWORK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_FRAMEWORK

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

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

FIRST
Try to find frameworks before standard libraries or headers. This is the default on Darwin.
LAST
Try to find frameworks after standard libraries or headers.
ONLY
Only try to find frameworks.
NEVER
Never try to find frameworks.

  • cmake-variables(7) »


CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX

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

This overrides the behavior of related global properties:

  • FIND_LIBRARY_USE_LIB32_PATHS
  • FIND_LIBRARY_USE_LIB64_PATHS
  • FIND_LIBRARY_USE_LIBX32_PATHS

  • cmake-variables(7) »


CMAKE_FIND_LIBRARY_PREFIXES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_FIND_LIBRARY_SUFFIXES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_LIBRARY_SUFFIXES

Suffixes to append when looking for libraries.

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

  • cmake-variables(7) »


CMAKE_FIND_NO_INSTALL_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY

Skip User Package Registry in find_package() calls.

In some cases, for example to locate only system wide installations, it is not desirable to use the User Package Registry when searching for packages. If the CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY variable is enabled, 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.

  • cmake-variables(7) »


CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY

Skip System Package Registry in find_package() calls.

In some cases, it is not desirable to use the System Package Registry when searching for packages. If the CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY variable is enabled, 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.

  • cmake-variables(7) »


CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS

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-variables(7) »


CMAKE_FIND_PACKAGE_WARN_NO_MODULE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


CMAKE_FIND_ROOT_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_FIND_ROOT_PATH_MODE_INCLUDE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_FIND_ROOT_PATH_MODE_LIBRARY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_FIND_ROOT_PATH_MODE_PACKAGE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_FIND_ROOT_PATH_MODE_PROGRAM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_FRAMEWORK_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FRAMEWORK_PATH

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

  • cmake-variables(7) »


CMAKE_IGNORE_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_IGNORE_PATH

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

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

See also the CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and CMAKE_PROGRAM_PATH variables.

  • cmake-variables(7) »


CMAKE_INCLUDE_DIRECTORIES_BEFORE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_INCLUDE_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_INCLUDE_PATH

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

  • cmake-variables(7) »


CMAKE_INSTALL_DEFAULT_COMPONENT_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS

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-variables(7) »


CMAKE_INSTALL_MESSAGE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_INSTALL_MESSAGE

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

-- Installing: /some/destination/path

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

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

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

ALWAYS
Print both Installing and Up-to-date messages.
LAZY
Print Installing but not Up-to-date messages.
NEVER
Print neither Installing nor Up-to-date messages.

Other values have undefined behavior and may not be diagnosed.

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

  • cmake-variables(7) »


CMAKE_INSTALL_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_INSTALL_PREFIX

Install directory used by install().

If make install is invoked or INSTALL is built, this directory is prepended onto all install directories. This variable defaults to /usr/local on UNIX and c:/Program Files/${PROJECT_NAME} on Windows. See CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT for how a project might choose its own default.

On UNIX one can use the DESTDIR mechanism in order to relocate the whole installation. See DESTDIR for more information.

The installation prefix is also added to CMAKE_SYSTEM_PREFIX_PATH so that find_package(), find_program(), find_library(), find_path(), and find_file() will search the prefix for other software.

Note

Use the GNUInstallDirs module to provide GNU-style options for the layout of directories within the installation.

  • cmake-variables(7) »


CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT

CMake sets this variable to a TRUE value when the CMAKE_INSTALL_PREFIX has just been initialized to its default value, typically on the first run of CMake within a new build tree. This can be used by project code to change the default without overriding a user-provided value:

if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
  set(CMAKE_INSTALL_PREFIX "/my/default" CACHE PATH "..." FORCE)
endif()

  • cmake-variables(7) »


CMAKE_LIBRARY_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_LIBRARY_PATH

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

  • cmake-variables(7) »


CMAKE_LINK_DIRECTORIES_BEFORE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_LINK_DIRECTORIES_BEFORE

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-variables(7) »


CMAKE_MFC_FLAG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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

  • cmake-variables(7) »


CMAKE_MAXIMUM_RECURSION_DEPTH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MAXIMUM_RECURSION_DEPTH

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

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

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

Calling any of the following commands increases the recursion depth:

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

  • cmake-variables(7) »


CMAKE_MODULE_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MODULE_PATH

Semicolon-separated list of directories 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.

  • cmake-variables(7) »


CMAKE_POLICY_DEFAULT_CMP<NNNN> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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; use cmake_policy(SET) instead. Users running CMake may set this variable in the cache (e.g. -DCMAKE_POLICY_DEFAULT_CMP<NNNN>=<OLD|NEW>) to set a policy not otherwise set by the project. Set to OLD to quiet a policy warning while using old behavior or to NEW to try building the project with new behavior.

  • cmake-variables(7) »


CMAKE_POLICY_WARNING_CMP<NNNN> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_POLICY_WARNING_CMP<NNNN>

Explicitly enable or disable the warning when CMake Policy CMP<NNNN> is not set. This is meaningful only for the few policies that do not warn by default:

  • CMAKE_POLICY_WARNING_CMP0025 controls the warning for policy CMP0025.
  • CMAKE_POLICY_WARNING_CMP0047 controls the warning for policy CMP0047.
  • CMAKE_POLICY_WARNING_CMP0056 controls the warning for policy CMP0056.
  • CMAKE_POLICY_WARNING_CMP0060 controls the warning for policy CMP0060.
  • CMAKE_POLICY_WARNING_CMP0065 controls the warning for policy CMP0065.
  • CMAKE_POLICY_WARNING_CMP0066 controls the warning for policy CMP0066.
  • CMAKE_POLICY_WARNING_CMP0067 controls the warning for policy CMP0067.
  • CMAKE_POLICY_WARNING_CMP0082 controls the warning for policy CMP0082.

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-variables(7) »


CMAKE_PREFIX_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

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

  • cmake-variables(7) »


CMAKE_PROGRAM_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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. See also CMAKE_SYSTEM_PROGRAM_PATH and CMAKE_PREFIX_PATH.

  • cmake-variables(7) »


CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE

A CMake language file or module to be included by the project() command. This is intended for injecting custom code into project builds without modifying their source.

  • cmake-variables(7) »


CMAKE_SKIP_INSTALL_ALL_DEPENDENCY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


CMAKE_STAGING_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS

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-variables(7) »


CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE

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-variables(7) »


CMAKE_SUPPRESS_REGENERATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SUPPRESS_REGENERATION

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-variables(7) »


CMAKE_SYSROOT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SYSROOT_COMPILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SYSROOT_COMPILE

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-variables(7) »


CMAKE_SYSROOT_LINK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SYSROOT_LINK

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-variables(7) »


CMAKE_SYSTEM_APPBUNDLE_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SYSTEM_APPBUNDLE_PATH

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-variables(7) »


CMAKE_SYSTEM_FRAMEWORK_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SYSTEM_FRAMEWORK_PATH

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-variables(7) »


CMAKE_SYSTEM_IGNORE_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SYSTEM_IGNORE_PATH

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

By default this contains a list of directories containing incompatible binaries for the host system. See the CMAKE_IGNORE_PATH variable that is intended to be set by the project.

See also the CMAKE_SYSTEM_PREFIX_PATH, CMAKE_SYSTEM_LIBRARY_PATH, CMAKE_SYSTEM_INCLUDE_PATH, and CMAKE_SYSTEM_PROGRAM_PATH variables.

  • cmake-variables(7) »


CMAKE_SYSTEM_INCLUDE_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SYSTEM_LIBRARY_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SYSTEM_PREFIX_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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

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-variables(7) »


CMAKE_SYSTEM_PROGRAM_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_USER_MAKE_RULES_OVERRIDE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

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-variables(7) »


CMAKE_WARN_DEPRECATED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY

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-variables(7) »


CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_GUARD_MALLOC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_GUARD_MALLOC

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_MALLOC_STACK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_MALLOC_STACK

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_THREAD_SANITIZER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_THREAD_SANITIZER

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS

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 CMAKE_XCODE_GENERATE_SCHEME variable documentation to see all Xcode schema related properties.

  • cmake-variables(7) »


<PackageName>_ROOT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

<PackageName>_ROOT

Calls to find_package(<PackageName>) will search in prefixes specified by the <PackageName>_ROOT CMake variable, where <PackageName> is the 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.

  • cmake-variables(7) »


ANDROID — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

ANDROID

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

  • cmake-variables(7) »


APPLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

APPLE

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

  • cmake-variables(7) »


BORLAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

BORLAND

True if the Borland compiler is being used.

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

  • cmake-variables(7) »


CMAKE_CL_64 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_COMPILER_2005 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_COMPILER_2005

Using the Visual Studio 2005 compiler from Microsoft

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

  • cmake-variables(7) »


CMAKE_HOST_APPLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_HOST_APPLE

True for Apple macOS operating systems.

Set to true when the host system is Apple macOS.

  • cmake-variables(7) »


CMAKE_HOST_SOLARIS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_HOST_SOLARIS

True for Oracle Solaris operating systems.

Set to true when the host system is Oracle Solaris.

  • cmake-variables(7) »


CMAKE_HOST_SYSTEM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_HOST_SYSTEM_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


CMAKE_HOST_SYSTEM_PROCESSOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_HOST_SYSTEM_PROCESSOR

The name of the CPU CMake is running on.

On systems that support uname, this variable is set to the output of uname -p. On Windows it is set to the value of the environment variable PROCESSOR_ARCHITECTURE.

  • cmake-variables(7) »


CMAKE_HOST_SYSTEM_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_HOST_UNIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_HOST_WIN32 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_HOST_WIN32

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

Set to false on Cygwin.

  • cmake-variables(7) »


CMAKE_LIBRARY_ARCHITECTURE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_LIBRARY_ARCHITECTURE_REGEX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_OBJECT_PATH_MAX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SYSTEM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_SYSTEM_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


CMAKE_SYSTEM_PROCESSOR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SYSTEM_PROCESSOR

The name of the CPU CMake is building for.

This variable is the same as CMAKE_HOST_SYSTEM_PROCESSOR if you build for the host system instead of the target system when cross compiling.

  • cmake-variables(7) »


CMAKE_SYSTEM_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


CYGWIN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CYGWIN

True for Cygwin.

Set to true when using Cygwin.

  • cmake-variables(7) »


GHS-MULTI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

GHS-MULTI

True when using Green Hills MULTI generator.

  • cmake-variables(7) »


IOS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

IOS

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

  • cmake-variables(7) »


MINGW — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MINGW

True when using MinGW

Set to true when the compiler is some version of MinGW.

  • cmake-variables(7) »


MSVC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC

Set to true when the compiler is some version of Microsoft Visual C++ or another compiler simulating Visual C++. Any compiler defining _MSC_VER is considered simulating Visual C++.

See also the MSVC_VERSION variable.

  • cmake-variables(7) »


MSVC10 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC10

Discouraged. Use the MSVC_VERSION variable instead.

True when using the Microsoft Visual Studio v100 toolset (cl version 16) or another compiler that simulates it.

  • cmake-variables(7) »


MSVC11 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC11

Discouraged. Use the MSVC_VERSION variable instead.

True when using the Microsoft Visual Studio v110 toolset (cl version 17) or another compiler that simulates it.

  • cmake-variables(7) »


MSVC12 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC12

Discouraged. Use the MSVC_VERSION variable instead.

True when using the Microsoft Visual Studio v120 toolset (cl version 18) or another compiler that simulates it.

  • cmake-variables(7) »


MSVC14 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC14

Discouraged. Use the MSVC_VERSION variable instead.

True when using the Microsoft Visual Studio v140 or v141 toolset (cl version 19) or another compiler that simulates it.

  • cmake-variables(7) »


MSVC60 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC60

Discouraged. Use the MSVC_VERSION variable instead.

True when using Microsoft Visual C++ 6.0.

Set to true when the compiler is version 6.0 of Microsoft Visual C++.

  • cmake-variables(7) »


MSVC70 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC70

Discouraged. Use the MSVC_VERSION variable instead.

True when using Microsoft Visual C++ 7.0.

Set to true when the compiler is version 7.0 of Microsoft Visual C++.

  • cmake-variables(7) »


MSVC71 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC71

Discouraged. Use the MSVC_VERSION variable instead.

True when using Microsoft Visual C++ 7.1.

Set to true when the compiler is version 7.1 of Microsoft Visual C++.

  • cmake-variables(7) »


MSVC80 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC80

Discouraged. Use the MSVC_VERSION variable instead.

True when using the Microsoft Visual Studio v80 toolset (cl version 14) or another compiler that simulates it.

  • cmake-variables(7) »


MSVC90 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC90

Discouraged. Use the MSVC_VERSION variable instead.

True when using the Microsoft Visual Studio v90 toolset (cl version 15) or another compiler that simulates it.

  • cmake-variables(7) »


MSVC_IDE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


MSVC_TOOLSET_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSVC_TOOLSET_VERSION

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)

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

See also the MSVC_VERSION variable.

  • cmake-variables(7) »


MSVC_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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)

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

  • cmake-variables(7) »


MSYS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

MSYS

True when using the MSYS Makefiles generator.

  • cmake-variables(7) »


UNIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


WIN32 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

WIN32

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

  • cmake-variables(7) »


WINCE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

WINCE

True when the CMAKE_SYSTEM_NAME variable is set to WindowsCE.

  • cmake-variables(7) »


WINDOWS_PHONE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

WINDOWS_PHONE

True when the CMAKE_SYSTEM_NAME variable is set to WindowsPhone.

  • cmake-variables(7) »


WINDOWS_STORE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

WINDOWS_STORE

True when the CMAKE_SYSTEM_NAME variable is set to WindowsStore.

  • cmake-variables(7) »


XCODE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

XCODE

True when using Xcode generator.

  • cmake-variables(7) »


XCODE_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS

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

  • cmake-variables(7) »


CMAKE_ANDROID_API — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_API

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.

Otherwise, when Cross Compiling for Android, this variable provides the Android API version number targeted. This will be the same value as the CMAKE_SYSTEM_VERSION variable for Android platforms.

  • cmake-variables(7) »


CMAKE_ANDROID_API_MIN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_API_MIN

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

  • cmake-variables(7) »


CMAKE_ANDROID_ARCH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_ARCH

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:

  • arm
  • arm64
  • mips
  • mips64
  • x86
  • x86_64

  • cmake-variables(7) »


CMAKE_ANDROID_ARCH_ABI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_ARCH_ABI

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

  • arm64-v8a
  • armeabi-v7a
  • armeabi-v6
  • armeabi
  • mips
  • mips64
  • x86
  • x86_64

See also the CMAKE_ANDROID_ARM_MODE and CMAKE_ANDROID_ARM_NEON variables.

  • cmake-variables(7) »


CMAKE_ANDROID_ARM_MODE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_ARM_MODE

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-variables(7) »


CMAKE_ANDROID_ARM_NEON — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_ARM_NEON

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-variables(7) »


CMAKE_ANDROID_ASSETS_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_ASSETS_DIRECTORIES

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

  • cmake-variables(7) »


CMAKE_ANDROID_GUI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_GUI

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

  • cmake-variables(7) »


CMAKE_ANDROID_JAR_DEPENDENCIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_JAR_DEPENDENCIES

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

  • cmake-variables(7) »


CMAKE_ANDROID_JAR_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_JAR_DIRECTORIES

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

  • cmake-variables(7) »


CMAKE_ANDROID_JAVA_SOURCE_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_JAVA_SOURCE_DIR

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

  • cmake-variables(7) »


CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES

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

  • cmake-variables(7) »


CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES

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

  • cmake-variables(7) »


CMAKE_ANDROID_NDK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_NDK

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-variables(7) »


CMAKE_ANDROID_NDK_DEPRECATED_HEADERS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_NDK_DEPRECATED_HEADERS

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-variables(7) »


CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG

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-variables(7) »


CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION

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. The variable must be set to one of these forms:

  • <major>.<minor>: GCC of specified version
  • clang<major>.<minor>: Clang of specified version
  • clang: Clang of most recent available version

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-variables(7) »


CMAKE_ANDROID_PROCESS_MAX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_PROCESS_MAX

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

  • cmake-variables(7) »


CMAKE_ANDROID_PROGUARD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_PROGUARD

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

  • cmake-variables(7) »


CMAKE_ANDROID_PROGUARD_CONFIG_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_PROGUARD_CONFIG_PATH

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

  • cmake-variables(7) »


CMAKE_ANDROID_SECURE_PROPS_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_SECURE_PROPS_PATH

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

  • cmake-variables(7) »


CMAKE_ANDROID_SKIP_ANT_STEP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_SKIP_ANT_STEP

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

  • cmake-variables(7) »


CMAKE_ANDROID_STANDALONE_TOOLCHAIN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_STANDALONE_TOOLCHAIN

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-variables(7) »


CMAKE_ANDROID_STL_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ANDROID_STL_TYPE

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:

none
No C++ Support
system
Minimal C++ without STL
gabi++_static
GAbi++ Static
gabi++_shared
GAbi++ Shared
gnustl_static
GNU libstdc++ Static
gnustl_shared
GNU libstdc++ Shared
c++_static
LLVM libc++ Static
c++_shared
LLVM libc++ Shared
stlport_static
STLport Static
stlport_shared
STLport Shared

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-variables(7) »


CMAKE_ARCHIVE_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_ARCHIVE_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>

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-variables(7) »


CMAKE_AUTOGEN_ORIGIN_DEPENDS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_AUTOGEN_ORIGIN_DEPENDS

Switch for forwarding origin target dependencies to the corresponding _autogen 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-variables(7) »


CMAKE_AUTOGEN_PARALLEL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_AUTOGEN_PARALLEL

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-variables(7) »


CMAKE_AUTOGEN_VERBOSE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_AUTOGEN_VERBOSE

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-variables(7) »


CMAKE_AUTOMOC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_AUTOMOC_COMPILER_PREDEFINES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_AUTOMOC_COMPILER_PREDEFINES

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-variables(7) »


CMAKE_AUTOMOC_DEPEND_FILTERS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_AUTOMOC_DEPEND_FILTERS

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-variables(7) »


CMAKE_AUTOMOC_MACRO_NAMES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_AUTOMOC_MACRO_NAMES

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.

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-variables(7) »


CMAKE_AUTOMOC_MOC_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_AUTORCC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_AUTORCC_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_AUTOUIC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_AUTOUIC_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_AUTOUIC_SEARCH_PATHS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_AUTOUIC_SEARCH_PATHS

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-variables(7) »


CMAKE_BUILD_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_BUILD_RPATH

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-variables(7) »


CMAKE_BUILD_RPATH_USE_ORIGIN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_BUILD_RPATH_USE_ORIGIN

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-variables(7) »


CMAKE_BUILD_WITH_INSTALL_NAME_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_BUILD_WITH_INSTALL_NAME_DIR

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-variables(7) »


CMAKE_BUILD_WITH_INSTALL_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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.

  • cmake-variables(7) »


CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY

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-variables(7) »


CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>

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-variables(7) »


CMAKE_<CONFIG>_POSTFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_CUDA_SEPARABLE_COMPILATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CUDA_SEPARABLE_COMPILATION

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

  • cmake-variables(7) »


CMAKE_DEBUG_POSTFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_ENABLE_EXPORTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_ENABLE_EXPORTS

Specify whether an executable exports symbols for loadable modules.

Normally an executable does not export any symbols because it is the final program. It is possible for an executable to export symbols to be used by loadable modules. When this property is set to true CMake will allow other targets to link to the executable with the TARGET_LINK_LIBRARIES() command. On all platforms a target-level dependency on the executable is created for targets that link to it. For DLL platforms an import library will be created for the exported symbols and then used for linking. All Windows-based systems including Cygwin are DLL platforms. For non-DLL platforms that require all symbols to be resolved at link time, such as macOS, the module will link to the executable using a flag like -bundle_loader. For other non-DLL platforms the link rule is simply ignored since the dynamic loader will automatically bind symbols when the module is loaded.

This variable is used to initialize the target property ENABLE_EXPORTS for executable targets.

  • cmake-variables(7) »


CMAKE_EXE_LINKER_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_EXE_LINKER_FLAGS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_EXE_LINKER_FLAGS_<CONFIG>_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_EXE_LINKER_FLAGS_<CONFIG>_INIT

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-variables(7) »


CMAKE_EXE_LINKER_FLAGS_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_EXE_LINKER_FLAGS_INIT

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-variables(7) »


CMAKE_FOLDER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_FOLDER

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-variables(7) »


CMAKE_Fortran_FORMAT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_Fortran_MODULE_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_GHS_NO_SOURCE_GROUP_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_GHS_NO_SOURCE_GROUP_FILE

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-variables(7) »


CMAKE_GLOBAL_AUTOGEN_TARGET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_GLOBAL_AUTOGEN_TARGET

Switch to enable generation of a global autogen target.

When CMAKE_GLOBAL_AUTORCC_TARGET is enabled, a custom target autogen is generated. This target depends on all AUTOMOC and AUTOUIC generated <ORIGIN>_autogen 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

<ORIGIN>_autogen targets by default inherit their origin target’s dependencies. This might result in unintended dependency target builds when only <ORIGIN>_autogen targets are built. A solution is to disable AUTOGEN_ORIGIN_DEPENDS on the respective origin targets.

  • cmake-variables(7) »


CMAKE_GLOBAL_AUTOGEN_TARGET_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_GLOBAL_AUTOGEN_TARGET_NAME

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-variables(7) »


CMAKE_GLOBAL_AUTORCC_TARGET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_GLOBAL_AUTORCC_TARGET

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-variables(7) »


CMAKE_GLOBAL_AUTORCC_TARGET_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_GLOBAL_AUTORCC_TARGET_NAME

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_AUTOGEN_TARGET_NAME is unset.

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

  • cmake-variables(7) »


CMAKE_GNUtoMS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_INCLUDE_CURRENT_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_INSTALL_NAME_DIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_INSTALL_NAME_DIR

macOS directory name for installed targets.

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

  • cmake-variables(7) »


CMAKE_INSTALL_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_INSTALL_RPATH_USE_LINK_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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 directories in the linker search path and outside the project to the INSTALL_RPATH. This is used to initialize the target property INSTALL_RPATH_USE_LINK_PATH for all targets.

  • cmake-variables(7) »


CMAKE_INTERPROCEDURAL_OPTIMIZATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_INTERPROCEDURAL_OPTIMIZATION

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-variables(7) »


CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>

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-variables(7) »


CMAKE_IOS_INSTALL_COMBINED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_IOS_INSTALL_COMBINED

Default value for IOS_INSTALL_COMBINED of targets.

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

  • cmake-variables(7) »


CMAKE_<LANG>_CLANG_TIDY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_CLANG_TIDY

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

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-variables(7) »


CMAKE_<LANG>_COMPILER_LAUNCHER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_LAUNCHER

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, or CUDA.

  • cmake-variables(7) »


CMAKE_<LANG>_CPPCHECK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_CPPCHECK

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-variables(7) »


CMAKE_<LANG>_CPPLINT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_CPPLINT

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-variables(7) »


CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE

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-variables(7) »


CMAKE_<LANG>_VISIBILITY_PRESET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_VISIBILITY_PRESET

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

  • cmake-variables(7) »


CMAKE_LIBRARY_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_LIBRARY_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_LIBRARY_OUTPUT_DIRECTORY_<CONFIG>

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-variables(7) »


CMAKE_LIBRARY_PATH_FLAG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_LINK_DEF_FILE_FLAG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_LINK_DEPENDS_NO_SHARED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_LINK_INTERFACE_LIBRARIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_LINK_LIBRARY_FILE_FLAG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_LINK_LIBRARY_FLAG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

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-variables(7) »


CMAKE_LINK_WHAT_YOU_USE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_LINK_WHAT_YOU_USE

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

  • cmake-variables(7) »


CMAKE_MACOSX_BUNDLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MACOSX_BUNDLE

Default value for MACOSX_BUNDLE of targets.

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

This variable is set to ON by default if CMAKE_SYSTEM_NAME equals to iOS, tvOS or watchOS.

  • cmake-variables(7) »


CMAKE_MACOSX_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MACOSX_RPATH

Whether to use rpaths on macOS and iOS.

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

  • cmake-variables(7) »


CMAKE_MAP_IMPORTED_CONFIG_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>

Default value for MAP_IMPORTED_CONFIG_<CONFIG> of targets.

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

  • cmake-variables(7) »


CMAKE_MODULE_LINKER_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MODULE_LINKER_FLAGS

Linker flags to be used to create modules.

These flags will be used by the linker when creating a module.

  • cmake-variables(7) »


CMAKE_MODULE_LINKER_FLAGS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MODULE_LINKER_FLAGS_<CONFIG>

Flags to be used when linking a module.

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

  • cmake-variables(7) »


CMAKE_MODULE_LINKER_FLAGS_<CONFIG>_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MODULE_LINKER_FLAGS_<CONFIG>_INIT

Value used to initialize the CMAKE_MODULE_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_MODULE_LINKER_FLAGS_INIT.

  • cmake-variables(7) »


CMAKE_MODULE_LINKER_FLAGS_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MODULE_LINKER_FLAGS_INIT

Value used to initialize the CMAKE_MODULE_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_MODULE_LINKER_FLAGS_<CONFIG>_INIT.

  • cmake-variables(7) »


CMAKE_MSVCIDE_RUN_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_MSVCIDE_RUN_PATH

Extra PATH locations that should be used when executing add_custom_command() or add_custom_target() when using the Visual Studio 9 2008 (or above) generator. This allows for running commands and using dll’s that the IDE environment is not aware of.

If not set explicitly the value is initialized by the CMAKE_MSVCIDE_RUN_PATH environment variable, if set, and otherwise left empty.

  • cmake-variables(7) »


CMAKE_NINJA_OUTPUT_PATH_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_NINJA_OUTPUT_PATH_PREFIX

Set output files path prefix for the Ninja generator.

Every output files listed in the generated build.ninja will be prefixed by the contents of this variable (a trailing slash is appended if missing). This is useful when the generated ninja file is meant to be embedded as a subninja file into a super ninja project. For example, a ninja build file generated with a command like:

cd top-build-dir/sub &&
cmake -G Ninja -DCMAKE_NINJA_OUTPUT_PATH_PREFIX=sub/ path/to/source

can be embedded in top-build-dir/build.ninja with a directive like this:

subninja sub/build.ninja

The auto-regeneration rule in top-build-dir/build.ninja must have an order-only dependency on sub/build.ninja.

Note

When CMAKE_NINJA_OUTPUT_PATH_PREFIX is set, the project generated by CMake cannot be used as a standalone project. No default targets are specified.

  • cmake-variables(7) »


CMAKE_NO_BUILTIN_CHRPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_NO_BUILTIN_CHRPATH

Do not use the builtin ELF editor to fix RPATHs on installation.

When an ELF binary needs to have a different RPATH after installation than it does in the build tree, CMake uses a builtin editor to change the RPATH in the installed copy. If this variable is set to true then CMake will relink the binary before installation instead of using its builtin editor.

  • cmake-variables(7) »


CMAKE_NO_SYSTEM_FROM_IMPORTED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_NO_SYSTEM_FROM_IMPORTED

Default value for NO_SYSTEM_FROM_IMPORTED of targets.

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

  • cmake-variables(7) »


CMAKE_OSX_ARCHITECTURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_OSX_ARCHITECTURES

Target specific architectures for macOS and iOS.

This variable is used to initialize the OSX_ARCHITECTURES property on each target as it is created. See that target property for additional information.

The value of this variable should be set prior to the first project() or enable_language() command invocation because it may influence configuration of the toolchain and flags. It is intended to be set locally by the user creating a build tree. This variable should be set as a CACHE entry (or else CMake may remove it while initializing a cache entry of the same name).

Despite the OSX part in the variable name(s) they apply also to other SDKs than macOS like iOS, tvOS, or watchOS.

This variable is ignored on platforms other than Apple.

  • cmake-variables(7) »


CMAKE_OSX_DEPLOYMENT_TARGET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_OSX_DEPLOYMENT_TARGET

Specify the minimum version of the target platform (e.g. macOS or iOS) on which the target binaries are to be deployed. CMake uses this variable value for the -mmacosx-version-min flag or their respective target platform equivalents. For older Xcode versions that shipped multiple macOS SDKs this variable also helps to choose the SDK in case CMAKE_OSX_SYSROOT is unset.

If not set explicitly the value is initialized by the MACOSX_DEPLOYMENT_TARGET environment variable, if set, and otherwise computed based on the host platform.

The value of this variable should be set prior to the first project() or enable_language() command invocation because it may influence configuration of the toolchain and flags. It is intended to be set locally by the user creating a build tree. This variable should be set as a CACHE entry (or else CMake may remove it while initializing a cache entry of the same name).

Despite the OSX part in the variable name(s) they apply also to other SDKs than macOS like iOS, tvOS, or watchOS.

This variable is ignored on platforms other than Apple.

  • cmake-variables(7) »


CMAKE_OSX_SYSROOT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_OSX_SYSROOT

Specify the location or name of the macOS platform SDK to be used. CMake uses this value to compute the value of the -isysroot flag or equivalent and to help the find_* commands locate files in the SDK.

If not set explicitly the value is initialized by the SDKROOT environment variable, if set, and otherwise computed based on the CMAKE_OSX_DEPLOYMENT_TARGET or the host platform.

The value of this variable should be set prior to the first project() or enable_language() command invocation because it may influence configuration of the toolchain and flags. It is intended to be set locally by the user creating a build tree. This variable should be set as a CACHE entry (or else CMake may remove it while initializing a cache entry of the same name).

Despite the OSX part in the variable name(s) they apply also to other SDKs than macOS like iOS, tvOS, or watchOS.

This variable is ignored on platforms other than Apple.

  • cmake-variables(7) »


CMAKE_PDB_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PDB_OUTPUT_DIRECTORY

Output directory for MS debug symbol .pdb files generated by the linker for executable and shared library targets.

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

  • cmake-variables(7) »


CMAKE_PDB_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_PDB_OUTPUT_DIRECTORY_<CONFIG>

Per-configuration output directory for MS debug symbol .pdb files generated by the linker for executable and shared library targets.

This is a per-configuration version of CMAKE_PDB_OUTPUT_DIRECTORY. This variable is used to initialize the PDB_OUTPUT_DIRECTORY_<CONFIG> property on all the targets. See that target property for additional information.

  • cmake-variables(7) »


CMAKE_POSITION_INDEPENDENT_CODE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_POSITION_INDEPENDENT_CODE

Default value for POSITION_INDEPENDENT_CODE of targets.

This variable is used to initialize the POSITION_INDEPENDENT_CODE property on all the targets. See that target property for additional information. If set, it’s value is also used by the try_compile() command.

  • cmake-variables(7) »


CMAKE_RUNTIME_OUTPUT_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_RUNTIME_OUTPUT_DIRECTORY

Where to put all the RUNTIME target files when built.

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

  • cmake-variables(7) »


CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG>

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

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

  • cmake-variables(7) »


CMAKE_SHARED_LINKER_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SHARED_LINKER_FLAGS

Linker flags to be used to create shared libraries.

These flags will be used by the linker when creating a shared library.

  • cmake-variables(7) »


CMAKE_SHARED_LINKER_FLAGS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SHARED_LINKER_FLAGS_<CONFIG>

Flags to be used when linking a shared library.

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

  • cmake-variables(7) »


CMAKE_SHARED_LINKER_FLAGS_<CONFIG>_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SHARED_LINKER_FLAGS_<CONFIG>_INIT

Value used to initialize the CMAKE_SHARED_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_SHARED_LINKER_FLAGS_INIT.

  • cmake-variables(7) »


CMAKE_SHARED_LINKER_FLAGS_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SHARED_LINKER_FLAGS_INIT

Value used to initialize the CMAKE_SHARED_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_SHARED_LINKER_FLAGS_<CONFIG>_INIT.

  • cmake-variables(7) »


CMAKE_SKIP_BUILD_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SKIP_BUILD_RPATH

Do not include RPATHs in the build tree.

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

  • cmake-variables(7) »


CMAKE_SKIP_INSTALL_RPATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_SKIP_INSTALL_RPATH

Do not include RPATHs in the install tree.

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 installed without RPATH, even if RPATH is enabled when building. This can be useful for example to allow running tests from the build directory with RPATH enabled before the installation step. To omit RPATH in both the build and install steps, use CMAKE_SKIP_RPATH instead.

  • cmake-variables(7) »


CMAKE_STATIC_LINKER_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_STATIC_LINKER_FLAGS

Linker flags to be used to create static libraries.

These flags will be used by the linker when creating a static library.

  • cmake-variables(7) »


CMAKE_STATIC_LINKER_FLAGS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_STATIC_LINKER_FLAGS_<CONFIG>

Flags to be used when linking a static library.

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

  • cmake-variables(7) »


CMAKE_STATIC_LINKER_FLAGS_<CONFIG>_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_STATIC_LINKER_FLAGS_<CONFIG>_INIT

Value used to initialize the CMAKE_STATIC_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_STATIC_LINKER_FLAGS_INIT.

  • cmake-variables(7) »


CMAKE_STATIC_LINKER_FLAGS_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_STATIC_LINKER_FLAGS_INIT

Value used to initialize the CMAKE_STATIC_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_STATIC_LINKER_FLAGS_<CONFIG>_INIT.

  • cmake-variables(7) »


CMAKE_TRY_COMPILE_CONFIGURATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_TRY_COMPILE_CONFIGURATION

Build configuration used for try_compile() and try_run() projects.

Projects built by try_compile() and try_run() are built synchronously during the CMake configuration step. Therefore a specific build configuration must be chosen even if the generated build system supports multiple configurations.

  • cmake-variables(7) »


CMAKE_TRY_COMPILE_PLATFORM_VARIABLES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_TRY_COMPILE_PLATFORM_VARIABLES

List of variables that the try_compile() command source file signature must propagate into the test project in order to target the same platform as the host project.

This variable should not be set by project code. It is meant to be set by CMake’s platform information modules for the current toolchain, or by a toolchain file when used with CMAKE_TOOLCHAIN_FILE.

Variables meaningful to CMake, such as CMAKE_<LANG>_FLAGS, are propagated automatically. The CMAKE_TRY_COMPILE_PLATFORM_VARIABLES variable may be set to pass custom variables meaningful to a toolchain file. For example, a toolchain file may contain:

set(CMAKE_SYSTEM_NAME ...)
set(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES MY_CUSTOM_VARIABLE)
# ... use MY_CUSTOM_VARIABLE ...

If a user passes -DMY_CUSTOM_VARIABLE=SomeValue to CMake then this setting will be made visible to the toolchain file both for the main project and for test projects generated by the try_compile() command source file signature.

  • cmake-variables(7) »


CMAKE_TRY_COMPILE_TARGET_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_TRY_COMPILE_TARGET_TYPE

Type of target generated for try_compile() calls using the source file signature. Valid values are:

EXECUTABLE
Use add_executable() to name the source file in the generated project. This is the default if no value is given.
STATIC_LIBRARY
Use add_library() with the STATIC option to name the source file in the generated project. This avoids running the linker and is intended for use with cross-compiling toolchains that cannot link without custom flags or linker scripts.

  • cmake-variables(7) »


CMAKE_USE_RELATIVE_PATHS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_USE_RELATIVE_PATHS

This variable has no effect. The partially implemented effect it had in previous releases was removed in CMake 3.4.

  • cmake-variables(7) »


CMAKE_VISIBILITY_INLINES_HIDDEN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VISIBILITY_INLINES_HIDDEN

Default value for the VISIBILITY_INLINES_HIDDEN target property when a target is created.

  • cmake-variables(7) »


CMAKE_VS_GLOBALS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_GLOBALS

List of Key=Value records to be set per target as target properties VS_GLOBAL_<variable> with variable=Key and value Value.

For example:

set(CMAKE_VS_GLOBALS
  "DefaultLanguage=en-US"
  "MinimumVisualStudioVersion=14.0"
  )

will set properties VS_GLOBAL_DefaultLanguage to en-US and VS_GLOBAL_MinimumVisualStudioVersion to 14.0 for all targets (except for INTERFACE libraries).

This variable is meant to be set by a toolchain file.

  • cmake-variables(7) »


CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD

Include INSTALL target to default build.

In Visual Studio solution, by default the INSTALL target will not be part of the default build. Setting this variable will enable the INSTALL target to be part of the default build.

  • cmake-variables(7) »


CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD

Include PACKAGE target to default build.

In Visual Studio solution, by default the PACKAGE target will not be part of the default build. Setting this variable will enable the PACKAGE target to be part of the default build.

  • cmake-variables(7) »


CMAKE_VS_SDK_EXCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_SDK_EXCLUDE_DIRECTORIES

This variable allows to override Visual Studio default Exclude Directories.

  • cmake-variables(7) »


CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES

This variable allows to override Visual Studio default Executable Directories.

  • cmake-variables(7) »


CMAKE_VS_SDK_INCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_SDK_INCLUDE_DIRECTORIES

This variable allows to override Visual Studio default Include Directories.

  • cmake-variables(7) »


CMAKE_VS_SDK_LIBRARY_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_SDK_LIBRARY_DIRECTORIES

This variable allows to override Visual Studio default Library Directories.

  • cmake-variables(7) »


CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES

This variable allows to override Visual Studio default Library WinRT Directories.

  • cmake-variables(7) »


CMAKE_VS_SDK_REFERENCE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_SDK_REFERENCE_DIRECTORIES

This variable allows to override Visual Studio default Reference Directories.

  • cmake-variables(7) »


CMAKE_VS_SDK_SOURCE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_SDK_SOURCE_DIRECTORIES

This variable allows to override Visual Studio default Source Directories.

  • cmake-variables(7) »


CMAKE_VS_WINRT_BY_DEFAULT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_WINRT_BY_DEFAULT

Tell Visual Studio Generators for VS 2010 and above that the target platform compiles as WinRT by default (compiles with /ZW).

This variable is meant to be set by a toolchain file for such platforms.

  • cmake-variables(7) »


CMAKE_WIN32_EXECUTABLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_WIN32_EXECUTABLE

Default value for WIN32_EXECUTABLE of targets.

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

  • cmake-variables(7) »


CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS

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

  • cmake-variables(7) »


CMAKE_XCODE_ATTRIBUTE_<an-attribute> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_XCODE_ATTRIBUTE_<an-attribute>

Set Xcode target attributes directly.

Tell the Xcode generator to set ‘<an-attribute>’ to a given value in the generated Xcode project. Ignored on other generators.

See the XCODE_ATTRIBUTE_<an-attribute> target property to set attributes on a specific target.

Contents of CMAKE_XCODE_ATTRIBUTE_<an-attribute> may use “generator expressions” with the syntax $<...>. See the cmake-generator-expressions(7) manual for available expressions. See the cmake-buildsystem(7) manual for more on defining buildsystem properties.

  • cmake-variables(7) »


EXECUTABLE_OUTPUT_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

EXECUTABLE_OUTPUT_PATH

Old executable location variable.

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

  • cmake-variables(7) »


LIBRARY_OUTPUT_PATH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

LIBRARY_OUTPUT_PATH

Old library location variable.

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

  • cmake-variables(7) »


CMAKE_COMPILER_IS_GNUCC — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_COMPILER_IS_GNUCC

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

  • cmake-variables(7) »


CMAKE_COMPILER_IS_GNUCXX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_COMPILER_IS_GNUCXX

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

  • cmake-variables(7) »


CMAKE_COMPILER_IS_GNUG77 — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_COMPILER_IS_GNUG77

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

  • cmake-variables(7) »


CMAKE_CUDA_HOST_COMPILER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CUDA_HOST_COMPILER

Executable to use when compiling host code when compiling CUDA language files. Maps to the nvcc -ccbin option. Will only be used by CMake on the first configuration to determine a valid host compiler for CUDA. After a valid host compiler has been found, this value is read-only.

  • cmake-variables(7) »


CMAKE_CUDA_EXTENSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CUDA_EXTENSIONS

Default value for CUDA_EXTENSIONS property of targets.

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

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

  • cmake-variables(7) »


CMAKE_CUDA_STANDARD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CUDA_STANDARD

Default value for CUDA_STANDARD property of targets.

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

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

  • cmake-variables(7) »


CMAKE_CUDA_STANDARD_REQUIRED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CUDA_STANDARD_REQUIRED

Default value for CUDA_STANDARD_REQUIRED property of targets.

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

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

  • cmake-variables(7) »


CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES

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

  • cmake-variables(7) »


CMAKE_CXX_COMPILE_FEATURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CXX_COMPILE_FEATURES

List of features known to the C++ compiler

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

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

  • cmake-variables(7) »


CMAKE_CXX_EXTENSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CXX_EXTENSIONS

Default value for CXX_EXTENSIONS property of targets.

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

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

  • cmake-variables(7) »


CMAKE_CXX_STANDARD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CXX_STANDARD

Default value for CXX_STANDARD property of targets.

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

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

  • cmake-variables(7) »


CMAKE_CXX_STANDARD_REQUIRED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_CXX_STANDARD_REQUIRED

Default value for CXX_STANDARD_REQUIRED property of targets.

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

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

  • cmake-variables(7) »


CMAKE_C_COMPILE_FEATURES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_C_COMPILE_FEATURES

List of features known to the C compiler

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

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

  • cmake-variables(7) »


CMAKE_C_EXTENSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_C_EXTENSIONS

Default value for C_EXTENSIONS property of targets.

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

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

  • cmake-variables(7) »


CMAKE_C_STANDARD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_C_STANDARD

Default value for C_STANDARD property of targets.

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

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

  • cmake-variables(7) »


CMAKE_C_STANDARD_REQUIRED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_C_STANDARD_REQUIRED

Default value for C_STANDARD_REQUIRED property of targets.

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

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

  • cmake-variables(7) »


CMAKE_Fortran_MODDIR_DEFAULT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_Fortran_MODDIR_DEFAULT

Fortran default module output directory.

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

  • cmake-variables(7) »


CMAKE_Fortran_MODDIR_FLAG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_Fortran_MODDIR_FLAG

Fortran flag for module output directory.

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

  • cmake-variables(7) »


CMAKE_Fortran_MODOUT_FLAG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_Fortran_MODOUT_FLAG

Fortran flag to enable module output.

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

  • cmake-variables(7) »


CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE

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

See also CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX and CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX.

  • cmake-variables(7) »


CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX

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

See also CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX and CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE.

For example, the path to the linker is:

${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}ld${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}

  • cmake-variables(7) »


CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX

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

See also CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX and CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE.

  • cmake-variables(7) »


CMAKE_<LANG>_ARCHIVE_APPEND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_ARCHIVE_APPEND

Rule variable to append to a static archive.

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

  • cmake-variables(7) »


CMAKE_<LANG>_ARCHIVE_CREATE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_ARCHIVE_CREATE

Rule variable to create a new static archive.

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

  • cmake-variables(7) »


CMAKE_<LANG>_ARCHIVE_FINISH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_ARCHIVE_FINISH

Rule variable to finish an existing static archive.

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

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER

The full path to the compiler for LANG.

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

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN

The external toolchain for cross-compiling, if supported.

Some compiler toolchains do not ship their own auxiliary utilities such as archivers and linkers. The compiler driver may support a command-line argument to specify the location of such tools. CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN may be set to a path to the external toolchain and will be passed to the compiler driver if supported.

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

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_ID — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_ID

Compiler identification string.

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

Absoft = Absoft Fortran (absoft.com)
ADSP = Analog VisualDSP++ (analog.com)
AppleClang = Apple Clang (apple.com)
ARMCC = ARM Compiler (arm.com)
Bruce = Bruce C Compiler
CCur = Concurrent Fortran (ccur.com)
Clang = LLVM Clang (clang.llvm.org)
Cray = Cray Compiler (cray.com)
Embarcadero, Borland = Embarcadero (embarcadero.com)
Flang = Flang LLVM Fortran Compiler
G95 = G95 Fortran (g95.org)
GNU = GNU Compiler Collection (gcc.gnu.org)
GHS = Green Hills Software (www.ghs.com)
HP = Hewlett-Packard Compiler (hp.com)
IAR = IAR Systems (iar.com)
Intel = Intel Compiler (intel.com)
MIPSpro = SGI MIPSpro (sgi.com)
MSVC = Microsoft Visual Studio (microsoft.com)
NVIDIA = NVIDIA CUDA Compiler (nvidia.com)
OpenWatcom = Open Watcom (openwatcom.org)
PGI = The Portland Group (pgroup.com)
PathScale = PathScale (pathscale.com)
SDCC = Small Device C Compiler (sdcc.sourceforge.net)
SunPro = Oracle Solaris Studio (oracle.com)
TI = Texas Instruments (ti.com)
TinyCC = Tiny C Compiler (tinycc.org)
XL, VisualAge, zOS = IBM XL (ibm.com)

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

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_LOADED — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_LOADED

Defined to true if the language is enabled.

When language <LANG> is enabled by project() or enable_language() this variable is defined to 1.

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND

Command that outputs the compiler pre definitions.

See AUTOMOC which uses CMAKE_CXX_COMPILER_PREDEFINES_COMMAND to generate the AUTOMOC_COMPILER_PREDEFINES.

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_TARGET — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_TARGET

The target for cross-compiling, if supported.

Some compiler drivers are inherently cross-compilers, such as clang and QNX qcc. These compiler drivers support a command-line argument to specify the target to cross-compile for.

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

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_VERSION

Compiler version string.

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

For example CMAKE_C_COMPILER_VERSION and CMAKE_CXX_COMPILER_VERSION might indicate the respective C and C++ compiler version.

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILE_OBJECT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILE_OBJECT

Rule variable to compile a single object file.

This is a rule variable that tells CMake how to compile a single object file for the language <LANG>.

  • cmake-variables(7) »


CMAKE_<LANG>_CREATE_SHARED_LIBRARY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_CREATE_SHARED_LIBRARY

Rule variable to create a shared library.

This is a rule variable that tells CMake how to create a shared library for the language <LANG>. This rule variable is a ; delimited list of commands to run to perform the linking step.

  • cmake-variables(7) »


CMAKE_<LANG>_CREATE_SHARED_MODULE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_CREATE_SHARED_MODULE

Rule variable to create a shared module.

This is a rule variable that tells CMake how to create a shared library for the language <LANG>. This rule variable is a ; delimited list of commands to run.

  • cmake-variables(7) »


CMAKE_<LANG>_CREATE_STATIC_LIBRARY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_CREATE_STATIC_LIBRARY

Rule variable to create a static library.

This is a rule variable that tells CMake how to create a static library for the language <LANG>.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS

Flags for all build types.

<LANG> flags used regardless of the value of CMAKE_BUILD_TYPE.

This is initialized for each language from environment variables:

  • CMAKE_C_FLAGS: Initialized by the CFLAGS environment variable.
  • CMAKE_CXX_FLAGS: Initialized by the CXXFLAGS environment variable.
  • CMAKE_CUDA_FLAGS: Initialized by the CUDAFLAGS environment variable.
  • CMAKE_Fortran_FLAGS: Initialized by the FFLAGS environment variable.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_<CONFIG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_<CONFIG>

Flags for language <LANG> when building for the <CONFIG> configuration.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_<CONFIG>_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_<CONFIG>_INIT

Value used to initialize the CMAKE_<LANG>_FLAGS_<CONFIG> cache entry the first time a build tree is configured for language <LANG>. This variable is meant to be set by a toolchain file. CMake may prepend or append content to the value based on the environment and target platform.

See also CMAKE_<LANG>_FLAGS_INIT.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_DEBUG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_DEBUG

This variable is the Debug variant of the CMAKE_<LANG>_FLAGS_<CONFIG> variable.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_DEBUG_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_DEBUG_INIT

This variable is the Debug variant of the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_INIT

Value used to initialize the CMAKE_<LANG>_FLAGS cache entry the first time a build tree is configured for language <LANG>. This variable is meant to be set by a toolchain file. CMake may prepend or append content to the value based on the environment and target platform.

See also the configuration-specific CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_MINSIZEREL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_MINSIZEREL

This variable is the MinSizeRel variant of the CMAKE_<LANG>_FLAGS_<CONFIG> variable.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_MINSIZEREL_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_MINSIZEREL_INIT

This variable is the MinSizeRel variant of the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_RELEASE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_RELEASE

This variable is the Release variant of the CMAKE_<LANG>_FLAGS_<CONFIG> variable.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_RELEASE_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_RELEASE_INIT

This variable is the Release variant of the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_RELWITHDEBINFO — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_RELWITHDEBINFO

This variable is the RelWithDebInfo variant of the CMAKE_<LANG>_FLAGS_<CONFIG> variable.

  • cmake-variables(7) »


CMAKE_<LANG>_FLAGS_RELWITHDEBINFO_INIT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_FLAGS_RELWITHDEBINFO_INIT

This variable is the RelWithDebInfo variant of the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variable.

  • cmake-variables(7) »


CMAKE_<LANG>_IGNORE_EXTENSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_IGNORE_EXTENSIONS

File extensions that should be ignored by the build.

This is a list of file extensions that may be part of a project for a given language but are not compiled.

  • cmake-variables(7) »


CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES

Directories implicitly searched by the compiler for header files.

CMake does not explicitly specify these directories on compiler command lines for language <LANG>. This prevents system include directories from being treated as user include directories on some compilers, which is important for C, CXX, and CUDA to avoid overriding standard library headers.

This value is not used for Fortran because it has no standard library headers and some compilers do not search their implicit include directories for module .mod files.

  • cmake-variables(7) »


CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES

Implicit linker search path detected for language <LANG>.

Compilers typically pass directories containing language runtime libraries and default library search paths when they invoke a linker. These paths are implicit linker search directories for the compiler’s language. CMake automatically detects these directories for each language and reports the results in this variable.

Some toolchains read implicit directories from an environment variable such as LIBRARY_PATH. If using such an environment variable, keep its value consistent when operating in a given build tree because CMake saves the value detected when first creating a build tree.

If policy CMP0060 is not set to NEW, then when a library in one of these directories is given by full path to target_link_libraries() CMake will generate the -l<name> form on link lines for historical purposes.

  • cmake-variables(7) »


CMAKE_<LANG>_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES

Implicit linker framework search path detected for language <LANG>.

These paths are implicit linker framework search directories for the compiler’s language. CMake automatically detects these directories for each language and reports the results in this variable.

  • cmake-variables(7) »


CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES

Implicit link libraries and flags detected for language <LANG>.

Compilers typically pass language runtime library names and other flags when they invoke a linker. These flags are implicit link options for the compiler’s language. CMake automatically detects these libraries and flags for each language and reports the results in this variable.

  • cmake-variables(7) »


CMAKE_<LANG>_LIBRARY_ARCHITECTURE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_LIBRARY_ARCHITECTURE

Target architecture library directory name detected for <LANG>.

If the <LANG> compiler passes to the linker an architecture-specific system library search directory such as <prefix>/lib/<arch> this variable contains the <arch> name if/as detected by CMake.

  • cmake-variables(7) »


CMAKE_<LANG>_LINKER_PREFERENCE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_LINKER_PREFERENCE

Preference value for linker language selection.

The “linker language” for executable, shared library, and module targets is the language whose compiler will invoke the linker. The LINKER_LANGUAGE target property sets the language explicitly. Otherwise, the linker language is that whose linker preference value is highest among languages compiled and linked into the target. See also the CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES variable.

  • cmake-variables(7) »


CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES

True if CMAKE_<LANG>_LINKER_PREFERENCE propagates across targets.

This is used when CMake selects a linker language for a target. Languages compiled directly into the target are always considered. A language compiled into static libraries linked by the target is considered if this variable is true.

  • cmake-variables(7) »


CMAKE_<LANG>_LINKER_WRAPPER_FLAG — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_LINKER_WRAPPER_FLAG

Defines the syntax of compiler driver option to pass options to the linker tool. It will be used to translate the LINKER: prefix in the link options (see add_link_options() and target_link_options()).

This variable holds a semicolon-separated list of tokens. If a space (i.e. ” “) is specified as last token, flag and LINKER: arguments will be specified as separate arguments to the compiler driver. The CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP variable can be specified to manage concatenation of arguments.

For example, for Clang we have:

set (CMAKE_C_LINKER_WRAPPER_FLAG "-Xlinker" " ")

Specifying "LINKER:-z,defs" will be transformed in -Xlinker -z -Xlinker defs.

For GNU GCC:

set (CMAKE_C_LINKER_WRAPPER_FLAG "-Wl,")
set (CMAKE_C_LINKER_WRAPPER_FLAG_SEP ",")

Specifying "LINKER:-z,defs" will be transformed in -Wl,-z,defs.

And for SunPro:

set (CMAKE_C_LINKER_WRAPPER_FLAG "-Qoption" "ld" " ")
set (CMAKE_C_LINKER_WRAPPER_FLAG_SEP ",")

Specifying "LINKER:-z,defs" will be transformed in -Qoption ld -z,defs.

  • cmake-variables(7) »


CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP

This variable is used with CMAKE_<LANG>_LINKER_WRAPPER_FLAG variable to format LINKER: prefix in the link options (see add_link_options() and target_link_options()).

When specified, arguments of the LINKER: prefix will be concatenated using this value as separator.

  • cmake-variables(7) »


CMAKE_<LANG>_LINK_EXECUTABLE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_LINK_EXECUTABLE

Rule variable to link an executable.

Rule variable to link an executable for the given language.

  • cmake-variables(7) »


CMAKE_<LANG>_OUTPUT_EXTENSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_OUTPUT_EXTENSION

Extension for the output of a compile for a single file.

This is the extension for an object file for the given <LANG>. For example .obj for C on Windows.

  • cmake-variables(7) »


CMAKE_<LANG>_SIMULATE_ID — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_SIMULATE_ID

Identification string of “simulated” compiler.

Some compilers simulate other compilers to serve as drop-in replacements. When CMake detects such a compiler it sets this variable to what would have been the CMAKE_<LANG>_COMPILER_ID for the simulated compiler.

  • cmake-variables(7) »


CMAKE_<LANG>_SIMULATE_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_SIMULATE_VERSION

Version string of “simulated” compiler.

Some compilers simulate other compilers to serve as drop-in replacements. When CMake detects such a compiler it sets this variable to what would have been the CMAKE_<LANG>_COMPILER_VERSION for the simulated compiler.

  • cmake-variables(7) »


CMAKE_<LANG>_SIZEOF_DATA_PTR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_SIZEOF_DATA_PTR

Size of pointer-to-data types for language <LANG>.

This holds the size (in bytes) of pointer-to-data types in the target platform ABI. It is defined for languages C and CXX (C++).

  • cmake-variables(7) »


CMAKE_<LANG>_SOURCE_FILE_EXTENSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_SOURCE_FILE_EXTENSIONS

Extensions of source files for the given language.

This is the list of extensions for a given language’s source files.

  • cmake-variables(7) »


CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES

Include directories to be used for every source file compiled with the <LANG> compiler. This is meant for specification of system include directories needed by the language for the current platform. The directories always appear at the end of the include path passed to the compiler.

This variable should not be set by project code. It is meant to be set by CMake’s platform information modules for the current toolchain, or by a toolchain file when used with CMAKE_TOOLCHAIN_FILE.

See also CMAKE_<LANG>_STANDARD_LIBRARIES.

  • cmake-variables(7) »


CMAKE_<LANG>_STANDARD_LIBRARIES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_STANDARD_LIBRARIES

Libraries linked into every executable and shared library linked for language <LANG>. This is meant for specification of system libraries needed by the language for the current platform.

This variable should not be set by project code. It is meant to be set by CMake’s platform information modules for the current toolchain, or by a toolchain file when used with CMAKE_TOOLCHAIN_FILE.

See also CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES.

  • cmake-variables(7) »


CMAKE_Swift_LANGUAGE_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_Swift_LANGUAGE_VERSION

Set to the Swift language version number. If not set, the oldest legacy version known to be available in the host Xcode version is assumed:

  • Swift 4.0 for Xcode 10.2 and above.
  • Swift 3.0 for Xcode 8.3 and above.
  • Swift 2.3 for Xcode 8.2 and below.

  • cmake-variables(7) »


CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG> — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>

Specify a CMake file that overrides platform information for <LANG>.

This is a language-specific version of CMAKE_USER_MAKE_RULES_OVERRIDE loaded only when enabling language <LANG>.

  • cmake-variables(7) »


CTEST_BINARY_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_BINARY_DIRECTORY

Specify the CTest BuildDirectory setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_BUILD_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_BUILD_COMMAND

Specify the CTest MakeCommand setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_BUILD_NAME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_BUILD_NAME

Specify the CTest BuildName setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_BZR_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_BZR_COMMAND

Specify the CTest BZRCommand setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_BZR_UPDATE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_BZR_UPDATE_OPTIONS

Specify the CTest BZRUpdateOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_CHANGE_ID — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CHANGE_ID

Specify the CTest ChangeId setting in a ctest(1) dashboard client script.

This setting allows CTest to pass arbitrary information about this build up to CDash. One use of this feature is to allow CDash to post comments on your pull request if anything goes wrong with your build.

  • cmake-variables(7) »


CTEST_CHECKOUT_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CHECKOUT_COMMAND

Tell the ctest_start() command how to checkout or initialize the source directory in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_CONFIGURATION_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CONFIGURATION_TYPE

Specify the CTest DefaultCTestConfigurationType setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_CONFIGURE_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CONFIGURE_COMMAND

Specify the CTest ConfigureCommand setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_COVERAGE_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_COVERAGE_COMMAND

Specify the CTest CoverageCommand setting in a ctest(1) dashboard client script.

Cobertura

Using Cobertura as the coverage generation within your multi-module Java project can generate a series of XML files.

The Cobertura Coverage parser expects to read the coverage data from a single XML file which contains the coverage data for all modules. Cobertura has a program with the ability to merge given cobertura.ser files and then another program to generate a combined XML file from the previous merged file. For command line testing, this can be done by hand prior to CTest looking for the coverage files. For script builds, set the CTEST_COVERAGE_COMMAND variable to point to a file which will perform these same steps, such as a .sh or .bat file.

set(CTEST_COVERAGE_COMMAND .../run-coverage-and-consolidate.sh)

where the run-coverage-and-consolidate.sh script is perhaps created by the configure_file() command and might contain the following code:

#!/usr/bin/env bash
CoberturaFiles="$(find "/path/to/source" -name "cobertura.ser")"
SourceDirs="$(find "/path/to/source" -name "java" -type d)"
cobertura-merge --datafile coberturamerge.ser $CoberturaFiles
cobertura-report --datafile coberturamerge.ser --destination . \
                 --format xml $SourceDirs

The script uses find to capture the paths to all of the cobertura.ser files found below the project’s source directory. It keeps the list of files and supplies it as an argument to the cobertura-merge program. The --datafile argument signifies where the result of the merge will be kept.

The combined coberturamerge.ser file is then used to generate the XML report using the cobertura-report program. The call to the cobertura-report program requires some named arguments.

--datafila
path to the merged .ser file
--destination
path to put the output files(s)
--format
file format to write output in: xml or html

The rest of the supplied arguments consist of the full paths to the /src/main/java directories of each module within the source tree. These directories are needed and should not be forgotten.

  • cmake-variables(7) »


CTEST_COVERAGE_EXTRA_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_COVERAGE_EXTRA_FLAGS

Specify the CTest CoverageExtraFlags setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_CURL_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CURL_OPTIONS

Specify the CTest CurlOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_CUSTOM_COVERAGE_EXCLUDE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_COVERAGE_EXCLUDE

A list of regular expressions which will be used to exclude files by their path from coverage output by the ctest_coverage() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_ERROR_EXCEPTION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_ERROR_EXCEPTION

A list of regular expressions which will be used to exclude when detecting error messages in build outputs by the ctest_test() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_ERROR_MATCH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_ERROR_MATCH

A list of regular expressions which will be used to detect error messages in build outputs by the ctest_test() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_ERROR_POST_CONTEXT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_ERROR_POST_CONTEXT

The number of lines to include as context which follow an error message by the ctest_test() command. The default is 10.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_ERROR_PRE_CONTEXT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_ERROR_PRE_CONTEXT

The number of lines to include as context which precede an error message by the ctest_test() command. The default is 10.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE

When saving a failing test’s output, this is the maximum size, in bytes, that will be collected by the ctest_test() command. Defaults to 307200 (300 KiB).

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_MAXIMUM_NUMBER_OF_ERRORS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_MAXIMUM_NUMBER_OF_ERRORS

The maximum number of errors in a single build step which will be detected. After this, the ctest_test() command will truncate the output. Defaults to 50.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS

The maximum number of warnings in a single build step which will be detected. After this, the ctest_test() command will truncate the output. Defaults to 50.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE

When saving a passing test’s output, this is the maximum size, in bytes, that will be collected by the ctest_test() command. Defaults to 1024 (1 KiB).

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_MEMCHECK_IGNORE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_MEMCHECK_IGNORE

A list of regular expressions to use to exclude tests during the ctest_memcheck() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_POST_MEMCHECK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_POST_MEMCHECK

A list of commands to run at the end of the ctest_memcheck() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_POST_TEST — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_POST_TEST

A list of commands to run at the end of the ctest_test() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_PRE_MEMCHECK — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_PRE_MEMCHECK

A list of commands to run at the start of the ctest_memcheck() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_PRE_TEST — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_PRE_TEST

A list of commands to run at the start of the ctest_test() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_TESTS_IGNORE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_TESTS_IGNORE

A list of regular expressions to use to exclude tests during the ctest_test() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_WARNING_EXCEPTION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_WARNING_EXCEPTION

A list of regular expressions which will be used to exclude when detecting warning messages in build outputs by the ctest_test() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CUSTOM_WARNING_MATCH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CUSTOM_WARNING_MATCH

A list of regular expressions which will be used to detect warning messages in build outputs by the ctest_test() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_CVS_CHECKOUT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CVS_CHECKOUT

Deprecated. Use CTEST_CHECKOUT_COMMAND instead.

  • cmake-variables(7) »


CTEST_CVS_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CVS_COMMAND

Specify the CTest CVSCommand setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_CVS_UPDATE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_CVS_UPDATE_OPTIONS

Specify the CTest CVSUpdateOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_DROP_LOCATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_DROP_LOCATION

Specify the CTest DropLocation setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_DROP_METHOD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_DROP_METHOD

Specify the CTest DropMethod setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_DROP_SITE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_DROP_SITE

Specify the CTest DropSite setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_DROP_SITE_CDASH — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_DROP_SITE_CDASH

Specify the CTest IsCDash setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_DROP_SITE_PASSWORD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_DROP_SITE_PASSWORD

Specify the CTest DropSitePassword setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_DROP_SITE_USER — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_DROP_SITE_USER

Specify the CTest DropSiteUser setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_EXTRA_COVERAGE_GLOB — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_EXTRA_COVERAGE_GLOB

A list of regular expressions which will be used to find files which should be covered by the ctest_coverage() command.

It is initialized by ctest(1), but may be edited in a CTestCustom file. See ctest_read_custom_files() documentation.

  • cmake-variables(7) »


CTEST_GIT_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_GIT_COMMAND

Specify the CTest GITCommand setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_GIT_INIT_SUBMODULES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_GIT_INIT_SUBMODULES

Specify the CTest GITInitSubmodules setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_GIT_UPDATE_CUSTOM — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_GIT_UPDATE_CUSTOM

Specify the CTest GITUpdateCustom setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_GIT_UPDATE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_GIT_UPDATE_OPTIONS

Specify the CTest GITUpdateOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_HG_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_HG_COMMAND

Specify the CTest HGCommand setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_HG_UPDATE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_HG_UPDATE_OPTIONS

Specify the CTest HGUpdateOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_LABELS_FOR_SUBPROJECTS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_LABELS_FOR_SUBPROJECTS

Specify the CTest LabelsForSubprojects setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_MEMORYCHECK_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_MEMORYCHECK_COMMAND

Specify the CTest MemoryCheckCommand setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_MEMORYCHECK_COMMAND_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_MEMORYCHECK_COMMAND_OPTIONS

Specify the CTest MemoryCheckCommandOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_MEMORYCHECK_SANITIZER_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_MEMORYCHECK_SANITIZER_OPTIONS

Specify the CTest MemoryCheckSanitizerOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_MEMORYCHECK_SUPPRESSIONS_FILE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_MEMORYCHECK_SUPPRESSIONS_FILE

Specify the CTest MemoryCheckSuppressionFile setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_MEMORYCHECK_TYPE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_MEMORYCHECK_TYPE

Specify the CTest MemoryCheckType setting in a ctest(1) dashboard client script. Valid values are Valgrind, Purify, BoundsChecker, and ThreadSanitizer, AddressSanitizer, LeakSanitizer, MemorySanitizer, and UndefinedBehaviorSanitizer.

  • cmake-variables(7) »


CTEST_NIGHTLY_START_TIME — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_NIGHTLY_START_TIME

Specify the CTest NightlyStartTime setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_P4_CLIENT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_P4_CLIENT

Specify the CTest P4Client setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_P4_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_P4_COMMAND

Specify the CTest P4Command setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_P4_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_P4_OPTIONS

Specify the CTest P4Options setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_P4_UPDATE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_P4_UPDATE_OPTIONS

Specify the CTest P4UpdateOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_RUN_CURRENT_SCRIPT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_RUN_CURRENT_SCRIPT

Setting this to 0 prevents ctest(1) from being run again when it reaches the end of a script run by calling ctest -S.

  • cmake-variables(7) »


CTEST_SCP_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_SCP_COMMAND

Legacy option. Not used.

  • cmake-variables(7) »


CTEST_SITE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_SITE

Specify the CTest Site setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_SUBMIT_URL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_SUBMIT_URL

Specify the CTest SubmitURL setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_SOURCE_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_SOURCE_DIRECTORY

Specify the CTest SourceDirectory setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_SVN_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_SVN_COMMAND

Specify the CTest SVNCommand setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_SVN_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_SVN_OPTIONS

Specify the CTest SVNOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_SVN_UPDATE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_SVN_UPDATE_OPTIONS

Specify the CTest SVNUpdateOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_TEST_LOAD — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_TEST_LOAD

Specify the TestLoad setting in the CTest Test Step of a ctest(1) dashboard client script. This sets the default value for the TEST_LOAD option of the ctest_test() command.

  • cmake-variables(7) »


CTEST_TEST_TIMEOUT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_TEST_TIMEOUT

Specify the CTest TimeOut setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_TRIGGER_SITE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_TRIGGER_SITE

Legacy option. Not used.

  • cmake-variables(7) »


CTEST_UPDATE_COMMAND — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_UPDATE_COMMAND

Specify the CTest UpdateCommand setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_UPDATE_OPTIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_UPDATE_OPTIONS

Specify the CTest UpdateOptions setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_UPDATE_VERSION_ONLY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_UPDATE_VERSION_ONLY

Specify the CTest UpdateVersionOnly setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CTEST_USE_LAUNCHERS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CTEST_USE_LAUNCHERS

Specify the CTest UseLaunchers setting in a ctest(1) dashboard client script.

  • cmake-variables(7) »


CPACK_ABSOLUTE_DESTINATION_FILES — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CPACK_ABSOLUTE_DESTINATION_FILES

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

This variable is a Read-Only variable which is set internally by CPack during installation and before packaging using CMAKE_ABSOLUTE_DESTINATION_FILES defined in cmake_install.cmake scripts. The value can be used within CPack project configuration file and/or CPack<GEN>.cmake file of <GEN> generator.

  • cmake-variables(7) »


CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY

Boolean toggle to include/exclude top level directory (component case).

Similar usage as CPACK_INCLUDE_TOPLEVEL_DIRECTORY but for the component case. See CPACK_INCLUDE_TOPLEVEL_DIRECTORY documentation for the detail.

  • cmake-variables(7) »


CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION

Ask CPack to error out as soon as a file with absolute INSTALL DESTINATION is encountered.

The fatal error is emitted before the installation of the offending file takes place. Some CPack generators, like NSIS, enforce this internally. This variable triggers the definition of CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION when CPack runs.

  • cmake-variables(7) »


CPACK_INCLUDE_TOPLEVEL_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CPACK_INCLUDE_TOPLEVEL_DIRECTORY

Boolean toggle to include/exclude top level directory.

When preparing a package CPack installs the item under the so-called top level directory. The purpose of is to include (set to 1 or ON or TRUE) the top level directory in the package or not (set to 0 or OFF or FALSE).

Each CPack generator has a built-in default value for this variable. E.g. Archive generators (ZIP, TGZ, …) includes the top level whereas RPM or DEB don’t. The user may override the default value by setting this variable.

There is a similar variable CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY which may be used to override the behavior for the component packaging case which may have different default value for historical (now backward compatibility) reason.

  • cmake-variables(7) »


CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS

Default permissions for implicitly created directories during packaging.

This variable serves the same purpose during packaging as the CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS variable serves during installation (e.g. make install).

If include(CPack) is used then by default this variable is set to the content of CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS.

  • cmake-variables(7) »


CPACK_INSTALL_SCRIPT — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CPACK_INSTALL_SCRIPT

Extra CMake script provided by the user.

If set this CMake script will be executed by CPack during its local [CPack-private] installation which is done right before packaging the files. The script is not called by e.g.: make install.

  • cmake-variables(7) »


CPACK_PACKAGING_INSTALL_PREFIX — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CPACK_PACKAGING_INSTALL_PREFIX

The prefix used in the built package.

Each CPack generator has a default value (like /usr). This default value may be overwritten from the CMakeLists.txt or the cpack(1) command line by setting an alternative value. Example:

set(CPACK_PACKAGING_INSTALL_PREFIX "/opt")

This is not the same purpose as CMAKE_INSTALL_PREFIX which is used when installing from the build tree without building a package.

  • cmake-variables(7) »


CPACK_SET_DESTDIR — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CPACK_SET_DESTDIR

Boolean toggle to make CPack use DESTDIR mechanism when packaging.

DESTDIR means DESTination DIRectory. It is commonly used by makefile users in order to install software at non-default location. It is a basic relocation mechanism that should not be used on Windows (see CMAKE_INSTALL_PREFIX documentation). It is usually invoked like this:

make DESTDIR=/home/john install

which will install the concerned software using the installation prefix, e.g. /usr/local prepended with the DESTDIR value which finally gives /home/john/usr/local. When preparing a package, CPack first installs the items to be packaged in a local (to the build tree) directory by using the same DESTDIR mechanism. Nevertheless, if CPACK_SET_DESTDIR is set then CPack will set DESTDIR before doing the local install. The most noticeable difference is that without CPACK_SET_DESTDIR, CPack uses CPACK_PACKAGING_INSTALL_PREFIX as a prefix whereas with CPACK_SET_DESTDIR set, CPack will use CMAKE_INSTALL_PREFIX as a prefix.

Manually setting CPACK_SET_DESTDIR may help (or simply be necessary) if some install rules uses absolute DESTINATION (see CMake install() command). However, starting with CPack/CMake 2.8.3 RPM and DEB installers tries to handle DESTDIR automatically so that it is seldom necessary for the user to set it.

  • cmake-variables(7) »


CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION

Ask CPack to warn each time a file with absolute INSTALL DESTINATION is encountered.

This variable triggers the definition of CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION when CPack runs cmake_install.cmake scripts.

  • cmake-variables(7) »


CACHE — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CACHE

Operator to read cache variables.

Use the syntax $CACHE{VAR} to read cache entry VAR. See the cmake-language(7) variables documentation for more complete documentation of the interaction of normal variables and cache entries.

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

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

  • cmake-variables(7) »


ENV — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

ENV

Operator to read environment variables.

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

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

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

  • cmake-variables(7) »


CMAKE_HOME_DIRECTORY — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_HOME_DIRECTORY

Path to top of source tree. Same as CMAKE_SOURCE_DIR.

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

  • cmake-variables(7) »


CMAKE_INTERNAL_PLATFORM_ABI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_INTERNAL_PLATFORM_ABI

An internal variable subject to change.

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

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_ABI — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_ABI

An internal variable subject to change.

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

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID

An internal variable subject to change.

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

  • cmake-variables(7) »


CMAKE_<LANG>_COMPILER_VERSION_INTERNAL — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_COMPILER_VERSION_INTERNAL

An internal variable subject to change.

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

  • cmake-variables(7) »


CMAKE_<LANG>_PLATFORM_ID — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_<LANG>_PLATFORM_ID

An internal variable subject to change.

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

  • cmake-variables(7) »


CMAKE_NOT_USING_CONFIG_FLAGS — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_NOT_USING_CONFIG_FLAGS

Skip _BUILD_TYPE flags if true.

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

  • cmake-variables(7) »


CMAKE_VS_INTEL_Fortran_PROJECT_VERSION — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cmake-variables(7) »

CMAKE_VS_INTEL_Fortran_PROJECT_VERSION

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

  • cmake-variables(7) »


cpack-generators(7) — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

cpack-generators(7)

Contents

  • cpack-generators(7)
    • Generators

Generators

  • CPack Archive Generator
  • CPack Bundle Generator
  • CPack Cygwin Generator
  • CPack DEB Generator
  • CPack DragNDrop Generator
  • CPack External Generator
  • CPack FreeBSD Generator
  • CPack IFW Generator
  • CPack NSIS Generator
  • CPack NuGet Generator
  • CPack PackageMaker Generator
  • CPack productbuild Generator
  • CPack RPM Generator
  • CPack WIX Generator


CPack Archive Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack Archive Generator

Archive CPack generator that supports packaging of sources and binaries in different formats:

  • 7Z - 7zip - (.7z)
  • TBZ2 (.tar.bz2)
  • TGZ (.tar.gz)
  • TXZ (.tar.xz)
  • TZ (.tar.Z)
  • ZIP (.zip)

Variables specific to CPack Archive generator

CPACK_ARCHIVE_FILE_NAME
CPACK_ARCHIVE_<component>_FILE_NAME

Package file name without extension which is added automatically depending on the archive format.

  • Mandatory : YES

  • Default : <CPACK_PACKAGE_FILE_NAME>[-<component>].<extension> with

    spaces replaced by ‘-‘

CPACK_ARCHIVE_COMPONENT_INSTALL

Enable component packaging for CPackArchive

  • Mandatory : NO
  • Default : OFF

If enabled (ON) multiple packages are generated. By default a single package containing files of all components is generated.

  • cpack-generators(7) »


CPack Bundle Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack Bundle Generator

CPack Bundle generator (macOS) specific options

Variables specific to CPack Bundle generator

Installers built on macOS using the Bundle generator use the aforementioned DragNDrop (CPACK_DMG_xxx) variables, plus the following Bundle-specific parameters (CPACK_BUNDLE_xxx).

CPACK_BUNDLE_NAME

The name of the generated bundle. This appears in the OSX finder as the bundle name. Required.

CPACK_BUNDLE_PLIST

Path to an OSX plist file that will be used for the generated bundle. This assumes that the caller has generated or specified their own Info.plist file. Required.

CPACK_BUNDLE_ICON

Path to an OSX icon file that will be used as the icon for the generated bundle. This is the icon that appears in the OSX finder for the bundle, and in the OSX dock when the bundle is opened. Required.

CPACK_BUNDLE_STARTUP_COMMAND

Path to a startup script. This is a path to an executable or script that will be run whenever an end-user double-clicks the generated bundle in the OSX Finder. Optional.

CPACK_BUNDLE_APPLE_CERT_APP

The name of your Apple supplied code signing certificate for the application. The name usually takes the form Developer ID Application: [Name] or 3rd Party Mac Developer Application: [Name]. If this variable is not set the application will not be signed.

CPACK_BUNDLE_APPLE_ENTITLEMENTS

The name of the Plist file that contains your apple entitlements for sandboxing your application. This file is required for submission to the Mac App Store.

CPACK_BUNDLE_APPLE_CODESIGN_FILES

A list of additional files that you wish to be signed. You do not need to list the main application folder, or the main executable. You should list any frameworks and plugins that are included in your app bundle.

CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER

Additional parameter that will passed to codesign. Default value: --deep -f

CPACK_COMMAND_CODESIGN

Path to the codesign(1) command used to sign applications with an Apple cert. This variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it).

  • cpack-generators(7) »


CPack Cygwin Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack Cygwin Generator

Cygwin CPack generator (Cygwin).

Variables specific to CPack Cygwin generator

The following variable is specific to installers build on and/or for Cygwin:

CPACK_CYGWIN_PATCH_NUMBER

The Cygwin patch number. FIXME: This documentation is incomplete.

CPACK_CYGWIN_PATCH_FILE

The Cygwin patch file. FIXME: This documentation is incomplete.

CPACK_CYGWIN_BUILD_SCRIPT

The Cygwin build script. FIXME: This documentation is incomplete.

  • cpack-generators(7) »


CPack DEB Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack DEB Generator

The built in (binary) CPack DEB generator (Unix only)

Variables specific to CPack Debian (DEB) generator

The CPack DEB generator may be used to create DEB package using CPack. The CPack DEB generator is a CPack generator thus it uses the CPACK_XXX variables used by CPack.

The CPack DEB generator should work on any Linux host but it will produce better deb package when Debian specific tools dpkg-xxx are usable on the build system.

The CPack DEB generator has specific features which are controlled by the specifics CPACK_DEBIAN_XXX variables.

CPACK_DEBIAN_<COMPONENT>_XXXX variables may be used in order to have component specific values. Note however that <COMPONENT> refers to the grouping name written in upper case. It may be either a component name or a component GROUP name.

Here are some CPack DEB generator wiki resources that are here for historic reasons and are no longer maintained but may still prove useful:

  • https://gitlab.kitware.com/cmake/community/wikis/doc/cpack/Configuration
  • https://gitlab.kitware.com/cmake/community/wikis/doc/cpack/PackageGenerators#deb-unix-only

List of CPack DEB generator specific variables:

CPACK_DEB_COMPONENT_INSTALL

Enable component packaging for CPackDEB

  • Mandatory : NO
  • Default : OFF

If enabled (ON) multiple packages are generated. By default a single package containing files of all components is generated.

CPACK_DEBIAN_PACKAGE_NAME
CPACK_DEBIAN_<COMPONENT>_PACKAGE_NAME

Set Package control field (variable is automatically transformed to lower case).

  • Mandatory : YES
  • Default :
    • CPACK_PACKAGE_NAME for non-component based installations
    • CPACK_DEBIAN_PACKAGE_NAME suffixed with -<COMPONENT> for component-based installations.

See https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source

CPACK_DEBIAN_FILE_NAME
CPACK_DEBIAN_<COMPONENT>_FILE_NAME

Package file name.

  • Mandatory : YES
  • Default : <CPACK_PACKAGE_FILE_NAME>[-<component>].deb

This may be set to DEB-DEFAULT to allow the CPack DEB generator to generate package file name by itself in deb format:

<PackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb

Alternatively provided package file name must end with either .deb or .ipk suffix.

Note

Preferred setting of this variable is DEB-DEFAULT but for backward compatibility with the CPack DEB generator in CMake prior to version 3.6 this feature is disabled by default.

Note

By using non default filenames duplicate names may occur. Duplicate files get overwritten and it is up to the packager to set the variables in a manner that will prevent such errors.

CPACK_DEBIAN_PACKAGE_EPOCH

The Debian package epoch

  • Mandatory : No
  • Default : -

Optional number that should be incremented when changing versioning schemas or fixing mistakes in the version numbers of older packages.

CPACK_DEBIAN_PACKAGE_VERSION

The Debian package version

  • Mandatory : YES
  • Default : CPACK_PACKAGE_VERSION

This variable may contain only alphanumerics (A-Za-z0-9) and the characters . + - ~ (full stop, plus, hyphen, tilde) and should start with a digit. If CPACK_DEBIAN_PACKAGE_RELEASE is not set then hyphens are not allowed.

Note

For backward compatibility with CMake 3.9 and lower a failed test of this variable’s content is not a hard error when both CPACK_DEBIAN_PACKAGE_RELEASE and CPACK_DEBIAN_PACKAGE_EPOCH variables are not set. An author warning is reported instead.

CPACK_DEBIAN_PACKAGE_RELEASE

The Debian package release - Debian revision number.

  • Mandatory : No
  • Default : -

This is the numbering of the DEB package itself, i.e. the version of the packaging and not the version of the content (see CPACK_DEBIAN_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.

CPACK_DEBIAN_PACKAGE_ARCHITECTURE
CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE

The Debian package architecture

  • Mandatory : YES
  • Default : Output of dpkg --print-architecture (or i386 if dpkg is not found)
CPACK_DEBIAN_PACKAGE_DEPENDS
CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS

Sets the Debian dependencies of this package.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_DEPENDS for component-based installations.

Note

If CPACK_DEBIAN_PACKAGE_SHLIBDEPS or more specifically CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS is set for this component, the discovered dependencies will be appended to CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS instead of CPACK_DEBIAN_PACKAGE_DEPENDS. If CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS is an empty string, only the automatically discovered dependencies will be set for this component.

Example:

set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libc6 (< 2.4)")
CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS

Sets inter component dependencies if listed with CPACK_COMPONENT_<compName>_DEPENDS variables.

  • Mandatory : NO
  • Default : -
CPACK_DEBIAN_PACKAGE_MAINTAINER

The Debian package maintainer

  • Mandatory : YES
  • Default : CPACK_PACKAGE_CONTACT
CPACK_DEBIAN_PACKAGE_DESCRIPTION
CPACK_COMPONENT_<COMPONENT>_DESCRIPTION

The Debian package description

  • Mandatory : YES
  • Default :
    • CPACK_DEBIAN_PACKAGE_DESCRIPTION if set or
    • CPACK_PACKAGE_DESCRIPTION_SUMMARY
CPACK_DEBIAN_PACKAGE_SECTION
CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION

Set Section control field e.g. admin, devel, doc, …

  • Mandatory : YES
  • Default : “devel”

See https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections

CPACK_DEBIAN_ARCHIVE_TYPE

The archive format used for creating the Debian package.

  • Mandatory : YES
  • Default : “gnutar”

Possible value is:

  • gnutar

Note

This variable previously defaulted to the paxr value, but dpkg has never supported that tar format. For backwards compatibility the paxr value will be mapped to gnutar and a deprecation message will be emitted.

CPACK_DEBIAN_COMPRESSION_TYPE

The compression used for creating the Debian package.

  • Mandatory : YES
  • Default : “gzip”

Possible values are:

  • lzma
  • xz
  • bzip2
  • gzip
CPACK_DEBIAN_PACKAGE_PRIORITY
CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY

Set Priority control field e.g. required, important, standard, optional, extra

  • Mandatory : YES
  • Default : “optional”

See https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities

CPACK_DEBIAN_PACKAGE_HOMEPAGE

The URL of the web site for this package, preferably (when applicable) the site from which the original source can be obtained and any additional upstream documentation or information may be found.

  • Mandatory : NO
  • Default : CMAKE_PROJECT_HOMEPAGE_URL

Note

The content of this field is a simple URL without any surrounding characters such as <>.

CPACK_DEBIAN_PACKAGE_SHLIBDEPS
CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS

May be set to ON in order to use dpkg-shlibdeps to generate better package dependency list.

  • Mandatory : NO
  • Default :
    • CPACK_DEBIAN_PACKAGE_SHLIBDEPS if set or
    • OFF

Note

You may need set CMAKE_INSTALL_RPATH to an appropriate value if you use this feature, because if you don’t dpkg-shlibdeps may fail to find your own shared libs. See https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

CPACK_DEBIAN_PACKAGE_DEBUG

May be set when invoking cpack in order to trace debug information during the CPack DEB generator run.

  • Mandatory : NO
  • Default : -
CPACK_DEBIAN_PACKAGE_PREDEPENDS
CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS

Sets the Pre-Depends field of the Debian package. Like Depends, except that it also forces dpkg to complete installation of the packages named before even starting the installation of the package which declares the pre-dependency.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_PREDEPENDS for component-based installations.

See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

CPACK_DEBIAN_PACKAGE_ENHANCES
CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES

Sets the Enhances field of the Debian package. Similar to Suggests but works in the opposite direction: declares that a package can enhance the functionality of another package.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_ENHANCES for component-based installations.

See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

CPACK_DEBIAN_PACKAGE_BREAKS
CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS

Sets the Breaks field of the Debian package. When a binary package (P) declares that it breaks other packages (B), dpkg will not allow the package (P) which declares Breaks be unpacked unless the packages that will be broken (B) are deconfigured first. As long as the package (P) is configured, the previously deconfigured packages (B) cannot be reconfigured again.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_BREAKS for component-based installations.

See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks

CPACK_DEBIAN_PACKAGE_CONFLICTS
CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS

Sets the Conflicts field of the Debian package. When one binary package declares a conflict with another using a Conflicts field, dpkg will not allow them to be unpacked on the system at the same time.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_CONFLICTS for component-based installations.

See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

Note

This is a stronger restriction than Breaks, which prevents the broken package from being configured while the breaking package is in the “Unpacked” state but allows both packages to be unpacked at the same time.

CPACK_DEBIAN_PACKAGE_PROVIDES
CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES

Sets the Provides field of the Debian package. A virtual package is one which appears in the Provides control field of another package.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_PROVIDES for component-based installations.

See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual

CPACK_DEBIAN_PACKAGE_REPLACES
CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES

Sets the Replaces field of the Debian package. Packages can declare in their control file that they should overwrite files in certain other packages, or completely replace other packages.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_REPLACES for component-based installations.

See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

CPACK_DEBIAN_PACKAGE_RECOMMENDS
CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS

Sets the Recommends field of the Debian package. Allows packages to declare a strong, but not absolute, dependency on other packages.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_RECOMMENDS for component-based installations.

See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

CPACK_DEBIAN_PACKAGE_SUGGESTS
CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS

Sets the Suggests field of the Debian package. Allows packages to declare a suggested package install grouping.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_SUGGESTS for component-based installations.

See http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS
  • Mandatory : NO
  • Default : OFF

Allows to generate shlibs control file automatically. Compatibility is defined by CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY variable value.

Note

Libraries are only considered if they have both library name and version set. This can be done by setting SOVERSION property with set_target_properties() command.

CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY

Compatibility policy for auto-generated shlibs control file.

  • Mandatory : NO
  • Default : “=”

Defines compatibility policy for auto-generated shlibs control file. Possible values: “=”, “>=”

See https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps

CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_EXTRA

This variable allow advanced user to add custom script to the control.tar.gz. Typical usage is for conffiles, postinst, postrm, prerm.

  • Mandatory : NO
  • Default : -

Usage:

set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
    "${CMAKE_CURRENT_SOURCE_DIR}/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm")

Note

The original permissions of the files will be used in the final package unless the variable CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION is set. In particular, the scripts should have the proper executable flag prior to the generation of the package.

CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION
CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_STRICT_PERMISSION

This variable indicates if the Debian policy on control files should be strictly followed.

  • Mandatory : NO
  • Default : FALSE

Usage:

set(CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION TRUE)

Note

This overrides the permissions on the original files, following the rules set by Debian policy https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners

CPACK_DEBIAN_PACKAGE_SOURCE
CPACK_DEBIAN_<COMPONENT>_PACKAGE_SOURCE

Sets the Source field of the binary Debian package. When the binary package name is not the same as the source package name (in particular when several components/binaries are generated from one source) the source from which the binary has been generated should be indicated with the field Source.

  • Mandatory : NO
  • Default :
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_SOURCE for component-based installations.

See https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source

Note

This value is not interpreted. It is possible to pass an optional revision number of the referenced source package as well.

Packaging of debug information

Dbgsym packages contain debug symbols for debugging packaged binaries.

Dbgsym packaging has its own set of variables:

CPACK_DEBIAN_DEBUGINFO_PACKAGE
CPACK_DEBIAN_<component>_DEBUGINFO_PACKAGE

Enable generation of dbgsym .ddeb package(s).

  • Mandatory : NO
  • Default : OFF

Note

Binaries must contain debug symbols before packaging so use either Debug or RelWithDebInfo for CMAKE_BUILD_TYPE variable value.

Building Debian packages on Windows

To communicate UNIX file permissions from the install stage to the CPack DEB generator the “cmake_mode_t” NTFS alternate data stream (ADT) is used.

When a filesystem without ADT support is used only owner read/write permissions can be preserved.

Reproducible packages

The environment variable SOURCE_DATE_EPOCH may be set to a UNIX timestamp, defined as the number of seconds, excluding leap seconds, since 01 Jan 1970 00:00:00 UTC. If set, the CPack DEB generator will use its value for timestamps in the package.

  • cpack-generators(7) »


CPack DragNDrop Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack DragNDrop Generator

The DragNDrop CPack generator (macOS) creates a DMG image.

Variables specific to CPack DragNDrop generator

The following variables are specific to the DragNDrop installers built on macOS:

CPACK_DMG_VOLUME_NAME

The volume name of the generated disk image. Defaults to CPACK_PACKAGE_FILE_NAME.

CPACK_DMG_FORMAT

The disk image format. Common values are UDRO (UDIF read-only), UDZO (UDIF zlib-compressed) or UDBZ (UDIF bzip2-compressed). Refer to hdiutil(1) for more information on other available formats. Defaults to UDZO.

CPACK_DMG_DS_STORE

Path to a custom .DS_Store file. This .DS_Store file can be used to specify the Finder window position/geometry and layout (such as hidden toolbars, placement of the icons etc.). This file has to be generated by the Finder (either manually or through AppleScript) using a normal folder from which the .DS_Store file can then be extracted.

CPACK_DMG_DS_STORE_SETUP_SCRIPT

Path to a custom AppleScript file. This AppleScript is used to generate a .DS_Store file which specifies the Finder window position/geometry and layout (such as hidden toolbars, placement of the icons etc.). By specifying a custom AppleScript there is no need to use CPACK_DMG_DS_STORE, as the .DS_Store that is generated by the AppleScript will be packaged.

CPACK_DMG_BACKGROUND_IMAGE

Path to an image file to be used as the background. This file will be copied to .background/background.<ext>, where <ext> is the original image file extension. The background image is installed into the image before CPACK_DMG_DS_STORE_SETUP_SCRIPT is executed or CPACK_DMG_DS_STORE is installed. By default no background image is set.

CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK

Default behaviour is to include a symlink to /Applications in the DMG. Set this option to ON to avoid adding the symlink.

CPACK_DMG_SLA_DIR

Directory where license and menu files for different languages are stored. Setting this causes CPack to look for a <language>.menu.txt and <language>.license.txt file for every language defined in CPACK_DMG_SLA_LANGUAGES. If both this variable and CPACK_RESOURCE_FILE_LICENSE are set, CPack will only look for the menu files and use the same license file for all languages.

CPACK_DMG_SLA_LANGUAGES

Languages for which a license agreement is provided when mounting the generated DMG. A menu file consists of 9 lines of text. The first line is is the name of the language itself, uppercase, in English (e.g. German). The other lines are translations of the following strings:

  • Agree
  • Disagree
  • Print
  • Save…
  • You agree to the terms of the License Agreement when you click the “Agree” button.
  • Software License Agreement
  • This text cannot be saved. The disk may be full or locked, or the file may be locked.
  • Unable to print. Make sure you have selected a printer.

For every language in this list, CPack will try to find files <language>.menu.txt and <language>.license.txt in the directory specified by the CPACK_DMG_SLA_DIR variable.

CPACK_COMMAND_HDIUTIL

Path to the hdiutil(1) command used to operate on disk image files on macOS. This variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it).

CPACK_COMMAND_SETFILE

Path to the SetFile(1) command used to set extended attributes on files and directories on macOS. This variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it).

CPACK_COMMAND_REZ

Path to the Rez(1) command used to compile resources on macOS. This variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it).

  • cpack-generators(7) »


CPack External Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack External Generator

CPack provides many generators to create packages for a variety of platforms and packaging systems. The intention is for CMake/CPack to be a complete end-to-end solution for building and packaging a software project. However, it may not always be possible to use CPack for the entire packaging process, due to either technical limitations or policies that require the use of certain tools. For this reason, CPack provides the “External” generator, which allows external packaging software to take advantage of some of the functionality provided by CPack, such as component installation and the dependency graph.

Integration with External Packaging Tools

The CPack External generator generates a .json file containing the CPack internal metadata, which gives external software information on how to package the software. External packaging software may itself invoke CPack, consume the generated metadata, install and package files as required.

Alternatively CPack can invoke an external packaging software through an optional custom CMake script in CPACK_EXTERNAL_PACKAGE_SCRIPT instead.

Staging of installation files may also optionally be taken care of by the generator when enabled through the CPACK_EXTERNAL_ENABLE_STAGING variable.

JSON Format

The JSON metadata file contains a list of CPack components and component groups, the various options passed to cpack_add_component() and cpack_add_component_group(), the dependencies between the components and component groups, and various other options passed to CPack.

The JSON’s root object will always provide two fields: formatVersionMajor and formatVersionMinor, which are always integers that describe the output format of the generator. Backwards-compatible changes to the output format (for example, adding a new field that didn’t exist before) cause the minor version to be incremented, and backwards-incompatible changes (for example, deleting a field or changing its meaning) cause the major version to be incremented and the minor version reset to 0. The format version is always of the format major.minor. In other words, it always has exactly two parts, separated by a period.

You can request one or more specific versions of the output format as described below with CPACK_EXTERNAL_REQUESTED_VERSIONS. The output format will have a major version that exactly matches the requested major version, and a minor version that is greater than or equal to the requested minor version. If no version is requested with CPACK_EXTERNAL_REQUESTED_VERSIONS, the latest known major version is used by default. Currently, the only supported format is 1.0, which is described below.

Version 1.0

In addition to the standard format fields, format version 1.0 provides the following fields in the root:

components

The components field is an object with component names as the keys and objects describing the components as the values. The component objects have the following fields:

name
The name of the component. This is always the same as the key in the components object.
displayName
The value of the DISPLAY_NAME field passed to cpack_add_component().
description
The value of the DESCRIPTION field passed to cpack_add_component().
isHidden
True if HIDDEN was passed to cpack_add_component(), false if it was not.
isRequired
True if REQUIRED was passed to cpack_add_component(), false if it was not.
isDisabledByDefault
True if DISABLED was passed to cpack_add_component(), false if it was not.
group
Only present if GROUP was passed to cpack_add_component(). If so, this field is a string value containing the component’s group.
dependencies
An array of components the component depends on. This contains the values in the DEPENDS argument passed to cpack_add_component(). If no DEPENDS argument was passed, this is an empty list.
installationTypes
An array of installation types the component is part of. This contains the values in the INSTALL_TYPES argument passed to cpack_add_component(). If no INSTALL_TYPES argument was passed, this is an empty list.
isDownloaded
True if DOWNLOADED was passed to cpack_add_component(), false if it was not.
archiveFile
The name of the archive file passed with the ARCHIVE_FILE argument to cpack_add_component(). If no ARCHIVE_FILE argument was passed, this is an empty string.
componentGroups

The componentGroups field is an object with component group names as the keys and objects describing the component groups as the values. The component group objects have the following fields:

name
The name of the component group. This is always the same as the key in the componentGroups object.
displayName
The value of the DISPLAY_NAME field passed to cpack_add_component_group().
description
The value of the DESCRIPTION field passed to cpack_add_component_group().
parentGroup
Only present if PARENT_GROUP was passed to cpack_add_component_group(). If so, this field is a string value containing the component group’s parent group.
isExpandedByDefault
True if EXPANDED was passed to cpack_add_component_group(), false if it was not.
isBold
True if BOLD_TITLE was passed to cpack_add_component_group(), false if it was not.
components
An array of names of components that are direct members of the group (components that have this group as their GROUP). Components of subgroups are not included.
subgroups
An array of names of component groups that are subgroups of the group (groups that have this group as their PARENT_GROUP).
installationTypes

The installationTypes field is an object with installation type names as the keys and objects describing the installation types as the values. The installation type objects have the following fields:

name
The name of the installation type. This is always the same as the key in the installationTypes object.
displayName
The value of the DISPLAY_NAME field passed to cpack_add_install_type().
index
The integer index of the installation type in the list.
projects

The projects field is an array of objects describing CMake projects which comprise the CPack project. The values in this field are derived from CPACK_INSTALL_CMAKE_PROJECTS. In most cases, this will be only a single project. The project objects have the following fields:

projectName
The project name passed to CPACK_INSTALL_CMAKE_PROJECTS.
component
The name of the component or component set which comprises the project.
directory
The build directory of the CMake project. This is the directory which contains the cmake_install.cmake script.
subDirectory
The subdirectory to install the project into inside the CPack package.
packageName
The package name given in CPACK_PACKAGE_NAME. Only present if this option is set.
packageVersion
The package version given in CPACK_PACKAGE_VERSION. Only present if this option is set.
packageDescriptionFile
The package description file given in CPACK_PACKAGE_DESCRIPTION_FILE. Only present if this option is set.
packageDescriptionSummary
The package description summary given in CPACK_PACKAGE_DESCRIPTION_SUMMARY. Only present if this option is set.
buildConfig
The build configuration given to CPack with the -C option. Only present if this option is set.
defaultDirectoryPermissions
The default directory permissions given in CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS. Only present if this option is set.
setDestdir
True if CPACK_SET_DESTDIR is true, false if it is not.
packagingInstallPrefix
The install prefix given in CPACK_PACKAGING_INSTALL_PREFIX. Only present if CPACK_SET_DESTDIR is true.
stripFiles
True if CPACK_STRIP_FILES is true, false if it is not.
warnOnAbsoluteInstallDestination
True if CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION is true, false if it is not.
errorOnAbsoluteInstallDestination
True if CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION is true, false if it is not.

Variables specific to CPack External generator

CPACK_EXTERNAL_REQUESTED_VERSIONS

This variable is used to request a specific version of the CPack External generator. It is a list of major.minor values, separated by semicolons.

If this variable is set to a non-empty value, the CPack External generator will iterate through each item in the list to search for a version that it knows how to generate. Requested versions should be listed in order of descending preference by the client software, as the first matching version in the list will be generated.

The generator knows how to generate the version if it has a versioned generator whose major version exactly matches the requested major version, and whose minor version is greater than or equal to the requested minor version. For example, if CPACK_EXTERNAL_REQUESTED_VERSIONS contains 1.0, and the CPack External generator knows how to generate 1.1, it will generate 1.1. If the generator doesn’t know how to generate a version in the list, it skips the version and looks at the next one. If it doesn’t know how to generate any of the requested versions, an error is thrown.

If this variable is not set, or is empty, the CPack External generator will generate the highest major and minor version that it knows how to generate.

If an invalid version is encountered in CPACK_EXTERNAL_REQUESTED_VERSIONS (one that doesn’t match major.minor, where major and minor are integers), it is ignored.

CPACK_EXTERNAL_ENABLE_STAGING

This variable can be set to true to enable optional installation into a temporary staging area which can then be picked up and packaged by an external packaging tool. The top level directory used by CPack for the current packaging task is contained in CPACK_TOPLEVEL_DIRECTORY. It is automatically cleaned up on each run before packaging is initiated and can be used for custom temporary files required by the external packaging tool. It also contains the staging area CPACK_TEMPORARY_DIRECTORY into which CPack performs the installation when staging is enabled.

CPACK_EXTERNAL_PACKAGE_SCRIPT

This variable can optionally specify the full path to a CMake script file to be run as part of the CPack invocation. It is invoked after (optional) staging took place and may run an external packaging tool. The script has access to the variables defined by the CPack config file.

  • cpack-generators(7) »


CPack FreeBSD Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack FreeBSD Generator

The built in (binary) CPack FreeBSD (pkg) generator (Unix only)

Variables specific to CPack FreeBSD (pkg) generator

The CPack FreeBSD generator may be used to create pkg(8) packages – these may be used on FreeBSD, DragonflyBSD, NetBSD, OpenBSD, but also on Linux or OSX, depending on the installed package-management tools – using CPack.

The CPack FreeBSD generator is a CPack generator and uses the CPACK_XXX variables used by CPack. It tries to re-use packaging information that may already be specified for Debian packages for the CPack DEB Generator. It also tries to re-use RPM packaging information when Debian does not specify.

The CPack FreeBSD generator should work on any host with libpkg installed. The packages it produces are specific to the host architecture and ABI.

The CPack FreeBSD generator sets package-metadata through CPACK_FREEBSD_XXX variables. The CPack FreeBSD generator, unlike the CPack Deb generator, does not specially support componentized packages; a single package is created from all the software artifacts created through CMake.

All of the variables can be set specifically for FreeBSD packaging in the CPackConfig file or in CMakeLists.txt, but most of them have defaults that use general settings (e.g. CMAKE_PROJECT_NAME) or Debian-specific variables when those make sense (e.g. the homepage of an upstream project is usually unchanged by the flavor of packaging). When there is no Debian information to fall back on, but the RPM packaging has it, fall back to the RPM information (e.g. package license).

CPACK_FREEBSD_PACKAGE_NAME

Sets the package name (in the package manifest, but also affects the output filename).

  • Mandatory: YES
  • Default:
    • CPACK_PACKAGE_NAME (this is always set by CPack itself, based on CMAKE_PROJECT_NAME).
CPACK_FREEBSD_PACKAGE_COMMENT

Sets the package comment. This is the short description displayed by pkg(8) in standard “pkg info” output.

  • Mandatory: YES
  • Default:
    • CPACK_PACKAGE_DESCRIPTION_SUMMARY (this is always set by CPack itself, if nothing else sets it explicitly).
    • PROJECT_DESCRIPTION (this can be set with the DESCRIPTION parameter for project()).
CPACK_FREEBSD_PACKAGE_DESCRIPTION

Sets the package description. This is the long description of the package, given by “pkg info” with a specific package as argument.

  • Mandatory: YES
  • Default:
    • CPACK_DEBIAN_PACKAGE_DESCRIPTION (this may be set already for Debian packaging, so we may as well re-use it).
CPACK_FREEBSD_PACKAGE_WWW

The URL of the web site for this package, preferably (when applicable) the site from which the original source can be obtained and any additional upstream documentation or information may be found.

  • Mandatory: YES
  • Default:
  • CMAKE_PROJECT_HOMEPAGE_URL, or if that is not set, CPACK_DEBIAN_PACKAGE_HOMEPAGE (this may be set already for Debian packaging, so we may as well re-use it).
CPACK_FREEBSD_PACKAGE_LICENSE

The license, or licenses, which apply to this software package. This must be one or more license-identifiers that pkg recognizes as acceptable license identifiers (e.g. “GPLv2”).

  • Mandatory: YES
  • Default:
    • CPACK_RPM_PACKAGE_LICENSE
CPACK_FREEBSD_PACKAGE_LICENSE_LOGIC

This variable is only of importance if there is more than one license. The default is “single”, which is only applicable to a single license. Other acceptable values are determined by pkg – those are “dual” or “multi” – meaning choice (OR) or simultaneous (AND) application of the licenses.

  • Mandatory: NO
  • Default: single
CPACK_FREEBSD_PACKAGE_MAINTAINER

The FreeBSD maintainer (e.g. kde@freebsd.org) of this package.

  • Mandatory: YES
  • Default: none
CPACK_FREEBSD_PACKAGE_ORIGIN

The origin (ports label) of this package; for packages built by CPack outside of the ports system this is of less importance. The default puts the package somewhere under misc/, as a stopgap.

  • Mandatory: YES
  • Default: misc/<package name>
CPACK_FREEBSD_PACKAGE_CATEGORIES

The ports categories where this package lives (if it were to be built from ports). If none is set a single category is determined based on the package origin.

  • Mandatory: YES
  • Default: derived from ORIGIN
CPACK_FREEBSD_PACKAGE_DEPS

A list of package origins that should be added as package dependencies. These are in the form <category>/<packagename>, e.g. x11/libkonq. No version information needs to be provided (this is not included in the manifest).

  • Mandatory: NO
  • Default: empty

  • cpack-generators(7) »


CPack IFW Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack IFW Generator

See CPackIFW for details on the CPackIFW module.

Overview

CPack IFW generator helps you to create online and offline binary cross-platform installers with a graphical user interface.

CPack IFW generator prepares project installation and generates configuration and meta information for QtIFW tools.

The QtIFW provides a set of tools and utilities to create installers for the supported desktop Qt platforms: Linux, Microsoft Windows, and macOS.

You should also install QtIFW to use CPack IFW generator.

Hints

Generally, the CPack IFW generator automatically finds QtIFW tools, but if you don’t use a default path for installation of the QtIFW tools, the path may be specified in either a CMake or an environment variable:

CPACK_IFW_ROOT

An CMake variable which specifies the location of the QtIFW tool suite.

The variable will be cached in the CPackConfig.cmake file and used at CPack runtime.

QTIFWDIR

An environment variable which specifies the location of the QtIFW tool suite.

Note

The specified path should not contain “bin” at the end (for example: “D:\DevTools\QtIFW2.0.5”).

The CPACK_IFW_ROOT variable has a higher priority and overrides the value of the QTIFWDIR variable.

Internationalization

Some variables and command arguments support internationalization via CMake script. This is an optional feature.

Installers created by QtIFW tools have built-in support for internationalization and many phrases are localized to many languages, but this does not apply to the description of the your components and groups that will be distributed.

Localization of the description of your components and groups is useful for users of your installers.

A localized variable or argument can contain a single default value, and a set of pairs the name of the locale and the localized value.

For example:

set(LOCALIZABLE_VARIABLE "Default value"
  en "English value"
  en_US "American value"
  en_GB "Great Britain value"
  )

Variables

You can use the following variables to change behavior of CPack IFW generator.

Debug

CPACK_IFW_VERBOSE

Set to ON to enable addition debug output. By default is OFF.

Package

CPACK_IFW_PACKAGE_TITLE

Name of the installer as displayed on the title bar. By default used CPACK_PACKAGE_DESCRIPTION_SUMMARY.

CPACK_IFW_PACKAGE_PUBLISHER

Publisher of the software (as shown in the Windows Control Panel). By default used CPACK_PACKAGE_VENDOR.

CPACK_IFW_PRODUCT_URL

URL to a page that contains product information on your web site.

CPACK_IFW_PACKAGE_ICON

Filename for a custom installer icon. The actual file is ‘.icns’ (macOS), ‘.ico’ (Windows). No functionality on Unix.

CPACK_IFW_PACKAGE_WINDOW_ICON

Filename for a custom window icon in PNG format for the Installer application.

CPACK_IFW_PACKAGE_LOGO

Filename for a logo is used as QWizard::LogoPixmap.

CPACK_IFW_PACKAGE_WATERMARK

Filename for a watermark is used as QWizard::WatermarkPixmap.

CPACK_IFW_PACKAGE_BANNER

Filename for a banner is used as QWizard::BannerPixmap.

CPACK_IFW_PACKAGE_BACKGROUND

Filename for an image used as QWizard::BackgroundPixmap (only used by MacStyle).

CPACK_IFW_PACKAGE_WIZARD_STYLE

Wizard style to be used (“Modern”, “Mac”, “Aero” or “Classic”).

CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH

Default width of the wizard in pixels. Setting a banner image will override this.

CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT

Default height of the wizard in pixels. Setting a watermark image will override this.

CPACK_IFW_PACKAGE_TITLE_COLOR

Color of the titles and subtitles (takes an HTML color code, such as “#88FF33”).

CPACK_IFW_PACKAGE_START_MENU_DIRECTORY

Name of the default program group for the product in the Windows Start menu.

By default used CPACK_IFW_PACKAGE_NAME.

CPACK_IFW_TARGET_DIRECTORY

Default target directory for installation. By default used “@ApplicationsDir@/ CPACK_PACKAGE_INSTALL_DIRECTORY”

You can use predefined variables.

CPACK_IFW_ADMIN_TARGET_DIRECTORY

Default target directory for installation with administrator rights.

You can use predefined variables.

CPACK_IFW_PACKAGE_GROUP

The group, which will be used to configure the root package

CPACK_IFW_PACKAGE_NAME

The root package name, which will be used if configuration group is not specified

CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_NAME

Filename of the generated maintenance tool. The platform-specific executable file extension is appended.

By default used QtIFW defaults (maintenancetool).

CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR

Set to OFF if the target directory should not be deleted when uninstalling.

Is ON by default

CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_INI_FILE

Filename for the configuration of the generated maintenance tool.

By default used QtIFW defaults (maintenancetool.ini).

CPACK_IFW_PACKAGE_ALLOW_NON_ASCII_CHARACTERS

Set to ON if the installation path can contain non-ASCII characters.

Is ON for QtIFW less 2.0 tools.

CPACK_IFW_PACKAGE_ALLOW_SPACE_IN_PATH

Set to OFF if the installation path cannot contain space characters.

Is ON for QtIFW less 2.0 tools.

CPACK_IFW_PACKAGE_CONTROL_SCRIPT

Filename for a custom installer control script.

CPACK_IFW_PACKAGE_RESOURCES

List of additional resources (‘.qrc’ files) to include in the installer binary.

You can use cpack_ifw_add_package_resources() command to resolve relative paths.

CPACK_IFW_PACKAGE_FILE_EXTENSION

The target binary extension.

On Linux, the name of the target binary is automatically extended with ‘.run’, if you do not specify the extension.

On Windows, the target is created as an application with the extension ‘.exe’, which is automatically added, if not supplied.

On Mac, the target is created as an DMG disk image with the extension ‘.dmg’, which is automatically added, if not supplied.

CPACK_IFW_REPOSITORIES_ALL

The list of remote repositories.

The default value of this variable is computed by CPack and contains all repositories added with command cpack_ifw_add_repository() or updated with command cpack_ifw_update_repository().

CPACK_IFW_DOWNLOAD_ALL

If this is ON all components will be downloaded. By default is OFF or used value from CPACK_DOWNLOAD_ALL if set

Components

CPACK_IFW_RESOLVE_DUPLICATE_NAMES

Resolve duplicate names when installing components with groups.

CPACK_IFW_PACKAGES_DIRECTORIES

Additional prepared packages dirs that will be used to resolve dependent components.

CPACK_IFW_REPOSITORIES_DIRECTORIES

Additional prepared repository dirs that will be used to resolve and repack dependent components. This feature available only since QtIFW 3.1.

Tools

CPACK_IFW_FRAMEWORK_VERSION

The version of used QtIFW tools.

CPACK_IFW_BINARYCREATOR_EXECUTABLE

The path to “binarycreator” command line client.

This variable is cached and may be configured if needed.

CPACK_IFW_REPOGEN_EXECUTABLE

The path to “repogen” command line client.

This variable is cached and may be configured if needed.

CPACK_IFW_INSTALLERBASE_EXECUTABLE

The path to “installerbase” installer executable base.

This variable is cached and may be configured if needed.

CPACK_IFW_DEVTOOL_EXECUTABLE

The path to “devtool” command line client.

This variable is cached and may be configured if needed.

Online installer

By default CPack IFW generator makes offline installer. This means that all components will be packaged into a binary file.

To make a component downloaded, you must set the DOWNLOADED option in cpack_add_component().

Then you would use the command cpack_configure_downloads(). If you set ALL option all components will be downloaded.

You also can use command cpack_ifw_add_repository() and variable CPACK_IFW_DOWNLOAD_ALL for more specific configuration.

CPack IFW generator creates “repository” dir in current binary dir. You would copy content of this dir to specified site (url).

See Also

Qt Installer Framework Manual:

  • Index page: http://doc.qt.io/qtinstallerframework/index.html
  • Component Scripting: http://doc.qt.io/qtinstallerframework/scripting.html
  • Predefined Variables: http://doc.qt.io/qtinstallerframework/scripting.html#predefined-variables
  • Promoting Updates: http://doc.qt.io/qtinstallerframework/ifw-updates.html
Download Qt Installer Framework for you platform from Qt site:
http://download.qt.io/official_releases/qt-installer-framework

  • cpack-generators(7) »


CPack NSIS Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack NSIS Generator

CPack NSIS generator specific options

Variables specific to CPack NSIS generator

The following variables are specific to the graphical installers built on Windows using the Nullsoft Installation System.

CPACK_NSIS_INSTALL_ROOT

The default installation directory presented to the end user by the NSIS installer is under this root dir. The full directory presented to the end user is: ${CPACK_NSIS_INSTALL_ROOT}/${CPACK_PACKAGE_INSTALL_DIRECTORY}

CPACK_NSIS_MUI_ICON

An icon filename. The name of a *.ico file used as the main icon for the generated install program.

CPACK_NSIS_MUI_UNIICON

An icon filename. The name of a *.ico file used as the main icon for the generated uninstall program.

CPACK_NSIS_INSTALLER_MUI_ICON_CODE

undocumented.

CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP

The filename of a bitmap to use as the NSIS MUI_WELCOMEFINISHPAGE_BITMAP.

CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP

The filename of a bitmap to use as the NSIS MUI_UNWELCOMEFINISHPAGE_BITMAP.

CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS

Extra NSIS commands that will be added to the beginning of the install Section, before your install tree is available on the target system.

CPACK_NSIS_EXTRA_INSTALL_COMMANDS

Extra NSIS commands that will be added to the end of the install Section, after your install tree is available on the target system.

CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS

Extra NSIS commands that will be added to the uninstall Section, before your install tree is removed from the target system.

CPACK_NSIS_COMPRESSOR

The arguments that will be passed to the NSIS SetCompressor command.

CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL

Ask about uninstalling previous versions first. If this is set to “ON”, then an installer will look for previous installed versions and if one is found, ask the user whether to uninstall it before proceeding with the install.

CPACK_NSIS_MODIFY_PATH

Modify PATH toggle. If this is set to “ON”, then an extra page will appear in the installer that will allow the user to choose whether the program directory should be added to the system PATH variable.

CPACK_NSIS_DISPLAY_NAME

The display name string that appears in the Windows Add/Remove Program control panel

CPACK_NSIS_PACKAGE_NAME

The title displayed at the top of the installer.

CPACK_NSIS_INSTALLED_ICON_NAME

A path to the executable that contains the installer icon.

CPACK_NSIS_HELP_LINK

URL to a web site providing assistance in installing your application.

CPACK_NSIS_URL_INFO_ABOUT

URL to a web site providing more information about your application.

CPACK_NSIS_CONTACT

Contact information for questions and comments about the installation process.

CPACK_NSIS_<compName>_INSTALL_DIRECTORY

Custom install directory for the specified component <compName> instead of $INSTDIR.

CPACK_NSIS_CREATE_ICONS_EXTRA

Additional NSIS commands for creating start menu shortcuts.

CPACK_NSIS_DELETE_ICONS_EXTRA

Additional NSIS commands to uninstall start menu shortcuts.

CPACK_NSIS_EXECUTABLES_DIRECTORY

Creating NSIS start menu links assumes that they are in ‘bin’ unless this variable is set. For example, you would set this to ‘exec’ if your executables are in an exec directory.

CPACK_NSIS_MUI_FINISHPAGE_RUN

Specify an executable to add an option to run on the finish page of the NSIS installer.

CPACK_NSIS_MENU_LINKS

Specify links in [application] menu. This should contain a list of pair “link” “link name”. The link may be a URL or a path relative to installation prefix. Like:

set(CPACK_NSIS_MENU_LINKS
    "doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake.html"
    "CMake Help" "https://cmake.org" "CMake Web Site")

  • cpack-generators(7) »


CPack NuGet Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack NuGet Generator

When build a NuGet package there is no direct way to control an output filename due a lack of the corresponding CLI option of NuGet, so there is no CPACK_NUGET_PACKAGE_FILENAME variable. To form the output filename NuGet uses the package name and the version according to its built-in rules.

Also, be aware that including a top level directory (CPACK_INCLUDE_TOPLEVEL_DIRECTORY) is ignored by this generator.

Variables specific to CPack NuGet generator

The CPack NuGet generator may be used to create NuGet packages using CPack. The CPack NuGet generator is a CPack generator thus it uses the CPACK_XXX variables used by CPack.

The CPack NuGet generator has specific features which are controlled by the specifics CPACK_NUGET_XXX variables. In the “one per group” mode (see CPACK_COMPONENTS_GROUPING), <compName> placeholder in the variables below would contain a group name (uppercased and turned into a “C” identifier).

List of CPack NuGet generator specific variables:

CPACK_NUGET_COMPONENT_INSTALL

Enable component packaging for CPack NuGet generator

  • Mandatory : NO
  • Default : OFF
CPACK_NUGET_PACKAGE_NAME
CPACK_NUGET_<compName>_PACKAGE_NAME

The NUGET package name.

  • Mandatory : YES
  • Default : CPACK_PACKAGE_NAME
CPACK_NUGET_PACKAGE_VERSION
CPACK_NUGET_<compName>_PACKAGE_VERSION

The NuGet package version.

  • Mandatory : YES
  • Default : CPACK_PACKAGE_VERSION
CPACK_NUGET_PACKAGE_DESCRIPTION
CPACK_NUGET_<compName>_PACKAGE_DESCRIPTION

A long description of the package for UI display.

  • Mandatory : YES
  • Default :
    • CPACK_COMPONENT_<compName>_DESCRIPTION,
    • CPACK_COMPONENT_GROUP_<groupName>_DESCRIPTION,
    • CPACK_PACKAGE_DESCRIPTION
CPACK_NUGET_PACKAGE_AUTHORS
CPACK_NUGET_<compName>_PACKAGE_AUTHORS

A comma-separated list of packages authors, matching the profile names on nuget.org. These are displayed in the NuGet Gallery on nuget.org and are used to cross-reference packages by the same authors.

  • Mandatory : YES
  • Default : CPACK_PACKAGE_VENDOR
CPACK_NUGET_PACKAGE_TITLE
CPACK_NUGET_<compName>_PACKAGE_TITLE

A human-friendly title of the package, typically used in UI displays as on nuget.org and the Package Manager in Visual Studio. If not specified, the package ID is used.

  • Mandatory : NO
  • Default :
    • CPACK_COMPONENT_<compName>_DISPLAY_NAME,
    • CPACK_COMPONENT_GROUP_<groupName>_DISPLAY_NAME
CPACK_NUGET_PACKAGE_OWNERS
CPACK_NUGET_<compName>_PACKAGE_OWNERS

A comma-separated list of the package creators using profile names on nuget.org. This is often the same list as in authors, and is ignored when uploading the package to nuget.org.

  • Mandatory : NO
  • Default : -
CPACK_NUGET_PACKAGE_HOMEPAGE_URL
CPACK_NUGET_<compName>_PACKAGE_HOMEPAGE_URL

A URL for the package’s home page, often shown in UI displays as well as nuget.org.

  • Mandatory : NO
  • Default : CPACK_PACKAGE_HOMEPAGE_URL
CPACK_NUGET_PACKAGE_LICENSEURL
CPACK_NUGET_<compName>_PACKAGE_LICENSEURL

A URL for the package’s license, often shown in UI displays as well as nuget.org.

  • Mandatory : NO
  • Default : -
CPACK_NUGET_PACKAGE_ICONURL
CPACK_NUGET_<compName>_PACKAGE_ICONURL

A URL for a 64x64 image with transparency background to use as the icon for the package in UI display.

  • Mandatory : NO
  • Default : -
CPACK_NUGET_PACKAGE_DESCRIPTION_SUMMARY
CPACK_NUGET_<compName>_PACKAGE_DESCRIPTION_SUMMARY

A short description of the package for UI display. If omitted, a truncated version of description is used.

  • Mandatory : NO
  • Default : CPACK_PACKAGE_DESCRIPTION_SUMMARY
CPACK_NUGET_PACKAGE_RELEASE_NOTES
CPACK_NUGET_<compName>_PACKAGE_RELEASE_NOTES

A description of the changes made in this release of the package, often used in UI like the Updates tab of the Visual Studio Package Manager in place of the package description.

  • Mandatory : NO
  • Default : -
CPACK_NUGET_PACKAGE_COPYRIGHT
CPACK_NUGET_<compName>_PACKAGE_COPYRIGHT

Copyright details for the package.

  • Mandatory : NO
  • Default : -
CPACK_NUGET_PACKAGE_TAGS
CPACK_NUGET_<compName>_PACKAGE_TAGS

A space-delimited list of tags and keywords that describe the package and aid discoverability of packages through search and filtering.

  • Mandatory : NO
  • Default : -
CPACK_NUGET_PACKAGE_DEPENDENCIES
CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES

A list of package dependencies.

  • Mandatory : NO
  • Default : -
CPACK_NUGET_PACKAGE_DEPENDENCIES_<dependency>_VERSION
CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES_<dependency>_VERSION

A version specification for the particular dependency, where <dependency> is an item of the dependency list (see above) transformed with MAKE_C_IDENTIFIER function of string() command.

  • Mandatory : NO
  • Default : -
CPACK_NUGET_PACKAGE_DEBUG

Enable debug messages while executing CPack NuGet generator.

  • Mandatory : NO
  • Default : OFF

  • cpack-generators(7) »


CPack PackageMaker Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack PackageMaker Generator

PackageMaker CPack generator (macOS).

Variables specific to CPack PackageMaker generator

The following variable is specific to installers built on Mac macOS using PackageMaker:

CPACK_OSX_PACKAGE_VERSION

The version of macOS that the resulting PackageMaker archive should be compatible with. Different versions of macOS support different features. For example, CPack can only build component-based installers for macOS 10.4 or newer, and can only build installers that download component son-the-fly for macOS 10.5 or newer. If left blank, this value will be set to the minimum version of macOS that supports the requested features. Set this variable to some value (e.g., 10.4) only if you want to guarantee that your installer will work on that version of macOS, and don’t mind missing extra features available in the installer shipping with later versions of macOS.

  • cpack-generators(7) »


CPack productbuild Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack productbuild Generator

productbuild CPack generator (macOS).

Variables specific to CPack productbuild generator

The following variable is specific to installers built on Mac macOS using ProductBuild:

CPACK_COMMAND_PRODUCTBUILD

Path to the productbuild(1) command used to generate a product archive for the macOS Installer or Mac App Store. This variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it).

CPACK_PRODUCTBUILD_IDENTITY_NAME

Adds a digital signature to the resulting package.

CPACK_PRODUCTBUILD_KEYCHAIN_PATH

Specify a specific keychain to search for the signing identity.

CPACK_COMMAND_PKGBUILD

Path to the pkgbuild(1) command used to generate an macOS component package on macOS. This variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it).

CPACK_PKGBUILD_IDENTITY_NAME

Adds a digital signature to the resulting package.

CPACK_PKGBUILD_KEYCHAIN_PATH

Specify a specific keychain to search for the signing identity.

CPACK_PREFLIGHT_<COMP>_SCRIPT

Full path to a file that will be used as the preinstall script for the named <COMP> component’s package, where <COMP> is the uppercased component name. No preinstall script is added if this variable is not defined for a given component.

CPACK_POSTFLIGHT_<COMP>_SCRIPT

Full path to a file that will be used as the postinstall script for the named <COMP> component’s package, where <COMP> is the uppercased component name. No postinstall script is added if this variable is not defined for a given component.

CPACK_PRODUCTBUILD_RESOURCES_DIR

If specified the productbuild generator copies files from this directory (including subdirectories) to the Resources directory. This is done before the CPACK_RESOURCE_FILE_WELCOME, CPACK_RESOURCE_FILE_README, and CPACK_RESOURCE_FILE_LICENSE files are copied.

  • cpack-generators(7) »


CPack RPM Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack RPM Generator

The built in (binary) CPack RPM generator (Unix only)

Variables specific to CPack RPM generator

The CPack RPM generator may be used to create RPM packages using CPack. The CPack RPM generator is a CPack generator thus it uses the CPACK_XXX variables used by CPack.

The CPack RPM generator has specific features which are controlled by the specifics CPACK_RPM_XXX variables.

CPACK_RPM_<COMPONENT>_XXXX variables may be used in order to have component specific values. Note however that <COMPONENT> refers to the grouping name written in upper case. It may be either a component name or a component GROUP name. Usually those variables correspond to RPM spec file entities. One may find information about spec files here http://www.rpm.org/wiki/Docs

Note

<COMPONENT> part of variables is preferred to be in upper case (for e.g. if component is named foo then use CPACK_RPM_FOO_XXXX variable name format) as is with other CPACK_<COMPONENT>_XXXX variables. For the purposes of back compatibility (CMake/CPack version 3.5 and lower) support for same cased component (e.g. fOo would be used as CPACK_RPM_fOo_XXXX) is still supported for variables defined in older versions of CMake/CPack but is not guaranteed for variables that will be added in the future. For the sake of back compatibility same cased component variables also override upper cased versions where both are present.

Here are some CPack RPM generator wiki resources that are here for historic reasons and are no longer maintained but may still prove useful:

  • https://gitlab.kitware.com/cmake/community/wikis/doc/cpack/Configuration
  • https://gitlab.kitware.com/cmake/community/wikis/doc/cpack/PackageGenerators#rpm-unix-only

List of CPack RPM generator specific variables:

CPACK_RPM_COMPONENT_INSTALL

Enable component packaging for CPack RPM generator

  • Mandatory : NO
  • Default : OFF

If enabled (ON) multiple packages are generated. By default a single package containing files of all components is generated.

CPACK_RPM_PACKAGE_SUMMARY
CPACK_RPM_<component>_PACKAGE_SUMMARY

The RPM package summary.

  • Mandatory : YES
  • Default : CPACK_PACKAGE_DESCRIPTION_SUMMARY
CPACK_RPM_PACKAGE_NAME
CPACK_RPM_<component>_PACKAGE_NAME

The RPM package name.

  • Mandatory : YES
  • Default : CPACK_PACKAGE_NAME
CPACK_RPM_FILE_NAME
CPACK_RPM_<component>_FILE_NAME

Package file name.

  • Mandatory : YES

  • Default : <CPACK_PACKAGE_FILE_NAME>[-<component>].rpm with spaces

    replaced by ‘-‘

This may be set to RPM-DEFAULT to allow rpmbuild tool to generate package file name by itself. Alternatively provided package file name must end with .rpm suffix.

Note

By using user provided spec file, rpm macro extensions such as for generating debuginfo packages or by simply using multiple components more than one rpm file may be generated, either from a single spec file or from multiple spec files (each component execution produces its own spec file). In such cases duplicate file names may occur as a result of this variable setting or spec file content structure. Duplicate files get overwritten and it is up to the packager to set the variables in a manner that will prevent such errors.

CPACK_RPM_MAIN_COMPONENT

Main component that is packaged without component suffix.

  • Mandatory : NO
  • Default : -

This variable can be set to any component or group name so that component or group rpm package is generated without component suffix in filename and package name.

CPACK_RPM_PACKAGE_EPOCH

The RPM package epoch

  • Mandatory : No
  • Default : -

Optional number that should be incremented when changing versioning schemas or fixing mistakes in the version numbers of older packages.

CPACK_RPM_PACKAGE_VERSION

The RPM package version.

  • Mandatory : YES
  • Default : CPACK_PACKAGE_VERSION
CPACK_RPM_PACKAGE_ARCHITECTURE
CPACK_RPM_<component>_PACKAGE_ARCHITECTURE

The RPM package architecture.

  • Mandatory : YES
  • Default : Native architecture output by uname -m

This may be set to noarch if you know you are building a noarch package.

CPACK_RPM_PACKAGE_RELEASE

The RPM package release.

  • Mandatory : YES
  • Default : 1

This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.

Note

This is the string that goes into the RPM Release: field. Some distros (e.g. Fedora, CentOS) require 1%{?dist} format and not just a number. %{?dist} part can be added by setting CPACK_RPM_PACKAGE_RELEASE_DIST.

CPACK_RPM_PACKAGE_RELEASE_DIST

The dist tag that is added RPM Release: field.

  • Mandatory : NO
  • Default : OFF

This is the reported %{dist} tag from the current distribution or empty %{dist} if RPM macro is not set. If this variable is set then RPM Release: field value is set to ${CPACK_RPM_PACKAGE_RELEASE}%{?dist}.

CPACK_RPM_PACKAGE_LICENSE

The RPM package license policy.

  • Mandatory : YES
  • Default : “unknown”
CPACK_RPM_PACKAGE_GROUP
CPACK_RPM_<component>_PACKAGE_GROUP

The RPM package group.

  • Mandatory : YES
  • Default : “unknown”
CPACK_RPM_PACKAGE_VENDOR

The RPM package vendor.

  • Mandatory : YES
  • Default : CPACK_PACKAGE_VENDOR if set or “unknown”
CPACK_RPM_PACKAGE_URL
CPACK_RPM_<component>_PACKAGE_URL

The projects URL.

  • Mandatory : NO
  • Default : CMAKE_PROJECT_HOMEPAGE_URL
CPACK_RPM_PACKAGE_DESCRIPTION
CPACK_RPM_<component>_PACKAGE_DESCRIPTION

RPM package description.

  • Mandatory : YES
  • Default : CPACK_COMPONENT_<compName>_DESCRIPTION (component based installers only) if set, CPACK_PACKAGE_DESCRIPTION_FILE if set or “no package description available”
CPACK_RPM_COMPRESSION_TYPE

RPM compression type.

  • Mandatory : NO
  • Default : -

May be used to override RPM compression type to be used to build the RPM. For example some Linux distribution now default to lzma or xz compression whereas older cannot use such RPM. Using this one can enforce compression type to be used.

Possible values are:

  • lzma
  • xz
  • bzip2
  • gzip
CPACK_RPM_PACKAGE_AUTOREQ
CPACK_RPM_<component>_PACKAGE_AUTOREQ

RPM spec autoreq field.

  • Mandatory : NO
  • Default : -

May be used to enable (1, yes) or disable (0, no) automatic shared libraries dependency detection. Dependencies are added to requires list.

Note

By default automatic dependency detection is enabled by rpm generator.

CPACK_RPM_PACKAGE_AUTOPROV
CPACK_RPM_<component>_PACKAGE_AUTOPROV

RPM spec autoprov field.

  • Mandatory : NO
  • Default : -

May be used to enable (1, yes) or disable (0, no) automatic listing of shared libraries that are provided by the package. Shared libraries are added to provides list.

Note

By default automatic provides detection is enabled by rpm generator.

CPACK_RPM_PACKAGE_AUTOREQPROV
CPACK_RPM_<component>_PACKAGE_AUTOREQPROV

RPM spec autoreqprov field.

  • Mandatory : NO
  • Default : -

Variable enables/disables autoreq and autoprov at the same time. See CPACK_RPM_PACKAGE_AUTOREQ and CPACK_RPM_PACKAGE_AUTOPROV for more details.

Note

By default automatic detection feature is enabled by rpm.

CPACK_RPM_PACKAGE_REQUIRES
CPACK_RPM_<component>_PACKAGE_REQUIRES

RPM spec requires field.

  • Mandatory : NO
  • Default : -

May be used to set RPM dependencies (requires). Note that you must enclose the complete requires string between quotes, for example:

set(CPACK_RPM_PACKAGE_REQUIRES "python >= 2.5.0, cmake >= 2.8")

The required package list of an RPM file could be printed with:

rpm -qp --requires file.rpm
CPACK_RPM_PACKAGE_CONFLICTS
CPACK_RPM_<component>_PACKAGE_CONFLICTS

RPM spec conflicts field.

  • Mandatory : NO
  • Default : -

May be used to set negative RPM dependencies (conflicts). Note that you must enclose the complete requires string between quotes, for example:

set(CPACK_RPM_PACKAGE_CONFLICTS "libxml2")

The conflicting package list of an RPM file could be printed with:

rpm -qp --conflicts file.rpm
CPACK_RPM_PACKAGE_REQUIRES_PRE
CPACK_RPM_<component>_PACKAGE_REQUIRES_PRE

RPM spec requires(pre) field.

  • Mandatory : NO
  • Default : -

May be used to set RPM preinstall dependencies (requires(pre)). Note that you must enclose the complete requires string between quotes, for example:

set(CPACK_RPM_PACKAGE_REQUIRES_PRE "shadow-utils, initscripts")
CPACK_RPM_PACKAGE_REQUIRES_POST
CPACK_RPM_<component>_PACKAGE_REQUIRES_POST

RPM spec requires(post) field.

  • Mandatory : NO
  • Default : -

May be used to set RPM postinstall dependencies (requires(post)). Note that you must enclose the complete requires string between quotes, for example:

set(CPACK_RPM_PACKAGE_REQUIRES_POST "shadow-utils, initscripts")
CPACK_RPM_PACKAGE_REQUIRES_POSTUN
CPACK_RPM_<component>_PACKAGE_REQUIRES_POSTUN

RPM spec requires(postun) field.

  • Mandatory : NO
  • Default : -

May be used to set RPM postuninstall dependencies (requires(postun)). Note that you must enclose the complete requires string between quotes, for example:

set(CPACK_RPM_PACKAGE_REQUIRES_POSTUN "shadow-utils, initscripts")
CPACK_RPM_PACKAGE_REQUIRES_PREUN
CPACK_RPM_<component>_PACKAGE_REQUIRES_PREUN

RPM spec requires(preun) field.

  • Mandatory : NO
  • Default : -

May be used to set RPM preuninstall dependencies (requires(preun)). Note that you must enclose the complete requires string between quotes, for example:

set(CPACK_RPM_PACKAGE_REQUIRES_PREUN "shadow-utils, initscripts")
CPACK_RPM_PACKAGE_SUGGESTS
CPACK_RPM_<component>_PACKAGE_SUGGESTS

RPM spec suggest field.

  • Mandatory : NO
  • Default : -

May be used to set weak RPM dependencies (suggests). Note that you must enclose the complete requires string between quotes.

CPACK_RPM_PACKAGE_PROVIDES
CPACK_RPM_<component>_PACKAGE_PROVIDES

RPM spec provides field.

  • Mandatory : NO
  • Default : -

May be used to set RPM dependencies (provides). The provided package list of an RPM file could be printed with:

rpm -qp --provides file.rpm
CPACK_RPM_PACKAGE_OBSOLETES
CPACK_RPM_<component>_PACKAGE_OBSOLETES

RPM spec obsoletes field.

  • Mandatory : NO
  • Default : -

May be used to set RPM packages that are obsoleted by this one.

CPACK_RPM_PACKAGE_RELOCATABLE

build a relocatable RPM.

  • Mandatory : NO
  • Default : CPACK_PACKAGE_RELOCATABLE

If this variable is set to TRUE or ON, the CPack RPM generator will try to build a relocatable RPM package. A relocatable RPM may be installed using:

rpm --prefix or --relocate

in order to install it at an alternate place see rpm(8). Note that currently this may fail if CPACK_SET_DESTDIR is set to ON. If CPACK_SET_DESTDIR is set then you will get a warning message but if there is file installed with absolute path you’ll get unexpected behavior.

CPACK_RPM_SPEC_INSTALL_POST

Deprecated - use CPACK_RPM_SPEC_MORE_DEFINE instead.

  • Mandatory : NO
  • Default : -
  • Deprecated: YES

May be used to override the __spec_install_post section within the generated spec file. This affects the install step during package creation, not during package installation. For adding operations to be performed during package installation, use CPACK_RPM_POST_INSTALL_SCRIPT_FILE instead.

CPACK_RPM_SPEC_MORE_DEFINE

RPM extended spec definitions lines.

  • Mandatory : NO
  • Default : -

May be used to add any %define lines to the generated spec file. An example of its use is to prevent stripping of executables (but note that this may also disable other default post install processing):

set(CPACK_RPM_SPEC_MORE_DEFINE "%define __spec_install_post /bin/true")
CPACK_RPM_PACKAGE_DEBUG

Toggle CPack RPM generator debug output.

  • Mandatory : NO
  • Default : -

May be set when invoking cpack in order to trace debug information during CPack RPM run. For example you may launch CPack like this:

cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM
CPACK_RPM_USER_BINARY_SPECFILE
CPACK_RPM_<componentName>_USER_BINARY_SPECFILE

A user provided spec file.

  • Mandatory : NO
  • Default : -

May be set by the user in order to specify a USER binary spec file to be used by the CPack RPM generator instead of generating the file. The specified file will be processed by configure_file( @ONLY).

CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE

Spec file template.

  • Mandatory : NO
  • Default : -

If set CPack will generate a template for USER specified binary spec file and stop with an error. For example launch CPack like this:

cpack -D CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE=1 -G RPM

The user may then use this file in order to hand-craft is own binary spec file which may be used with CPACK_RPM_USER_BINARY_SPECFILE.

CPACK_RPM_PRE_INSTALL_SCRIPT_FILE
CPACK_RPM_PRE_UNINSTALL_SCRIPT_FILE

Path to file containing pre (un)install script.

  • Mandatory : NO
  • Default : -

May be used to embed a pre (un)installation script in the spec file. The referred script file (or both) will be read and directly put after the %pre or %preun section If CPACK_RPM_COMPONENT_INSTALL is set to ON the (un)install script for each component can be overridden with CPACK_RPM_<COMPONENT>_PRE_INSTALL_SCRIPT_FILE and CPACK_RPM_<COMPONENT>_PRE_UNINSTALL_SCRIPT_FILE. One may verify which scriptlet has been included with:

rpm -qp --scripts  package.rpm
CPACK_RPM_POST_INSTALL_SCRIPT_FILE
CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE

Path to file containing post (un)install script.

  • Mandatory : NO
  • Default : -

May be used to embed a post (un)installation script in the spec file. The referred script file (or both) will be read and directly put after the %post or %postun section. If CPACK_RPM_COMPONENT_INSTALL is set to ON the (un)install script for each component can be overridden with CPACK_RPM_<COMPONENT>_POST_INSTALL_SCRIPT_FILE and CPACK_RPM_<COMPONENT>_POST_UNINSTALL_SCRIPT_FILE. One may verify which scriptlet has been included with:

rpm -qp --scripts  package.rpm
CPACK_RPM_USER_FILELIST
CPACK_RPM_<COMPONENT>_USER_FILELIST
  • Mandatory : NO
  • Default : -

May be used to explicitly specify %(<directive>) file line in the spec file. Like %config(noreplace) or any other directive that be found in the %files section. You can have multiple directives per line, as in %attr(600,root,root) %config(noreplace). Since the CPack RPM generator is generating the list of files (and directories) the user specified files of the CPACK_RPM_<COMPONENT>_USER_FILELIST list will be removed from the generated list. If referring to directories do not add a trailing slash.

CPACK_RPM_CHANGELOG_FILE

RPM changelog file.

  • Mandatory : NO
  • Default : -

May be used to embed a changelog in the spec file. The referred file will be read and directly put after the %changelog section.

CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST

list of path to be excluded.

  • Mandatory : NO
  • Default : /etc /etc/init.d /usr /usr/bin /usr/include /usr/lib
    /usr/libx32 /usr/lib64 /usr/share /usr/share/aclocal /usr/share/doc

May be used to exclude path (directories or files) from the auto-generated list of paths discovered by CPack RPM. The default value contains a reasonable set of values if the variable is not defined by the user. If the variable is defined by the user then the CPack RPM generator will NOT any of the default path. If you want to add some path to the default list then you can use CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION variable.

CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION

additional list of path to be excluded.

  • Mandatory : NO
  • Default : -

May be used to add more exclude path (directories or files) from the initial default list of excluded paths. See CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST.

CPACK_RPM_RELOCATION_PATHS

Packages relocation paths list.

  • Mandatory : NO
  • Default : -

May be used to specify more than one relocation path per relocatable RPM. Variable contains a list of relocation paths that if relative are prefixed by the value of CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX or by the value of CPACK_PACKAGING_INSTALL_PREFIX if the component version is not provided. Variable is not component based as its content can be used to set a different path prefix for e.g. binary dir and documentation dir at the same time. Only prefixes that are required by a certain component are added to that component - component must contain at least one file/directory/symbolic link with CPACK_RPM_RELOCATION_PATHS prefix for a certain relocation path to be added. Package will not contain any relocation paths if there are no files/directories/symbolic links on any of the provided prefix locations. Packages that either do not contain any relocation paths or contain files/directories/symbolic links that are outside relocation paths print out an AUTHOR_WARNING that RPM will be partially relocatable.

CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX

Per component relocation path install prefix.

  • Mandatory : NO
  • Default : CPACK_PACKAGING_INSTALL_PREFIX

May be used to set per component CPACK_PACKAGING_INSTALL_PREFIX for relocatable RPM packages.

CPACK_RPM_NO_INSTALL_PREFIX_RELOCATION
CPACK_RPM_NO_<COMPONENT>_INSTALL_PREFIX_RELOCATION

Removal of default install prefix from relocation paths list.

  • Mandatory : NO
  • Default : CPACK_PACKAGING_INSTALL_PREFIX or CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX
    are treated as one of relocation paths

May be used to remove CPACK_PACKAGING_INSTALL_PREFIX and CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX from relocatable RPM prefix paths.

CPACK_RPM_ADDITIONAL_MAN_DIRS
  • Mandatory : NO
  • Default : -

May be used to set additional man dirs that could potentially be compressed by brp-compress RPM macro. Variable content must be a list of regular expressions that point to directories containing man files or to man files directly. Note that in order to compress man pages a path must also be present in brp-compress RPM script and that brp-compress script must be added to RPM configuration by the operating system.

Regular expressions that are added by default were taken from brp-compress RPM macro:

  • /usr/man/man.*
  • /usr/man/.*/man.*
  • /usr/info.*
  • /usr/share/man/man.*
  • /usr/share/man/.*/man.*
  • /usr/share/info.*
  • /usr/kerberos/man.*
  • /usr/X11R6/man/man.*
  • /usr/lib/perl5/man/man.*
  • /usr/share/doc/.*/man/man.*
  • /usr/lib/.*/man/man.*
CPACK_RPM_DEFAULT_USER
CPACK_RPM_<compName>_DEFAULT_USER

default user ownership of RPM content

  • Mandatory : NO
  • Default : root

Value should be user name and not UID. Note that <compName> must be in upper-case.

CPACK_RPM_DEFAULT_GROUP
CPACK_RPM_<compName>_DEFAULT_GROUP

default group ownership of RPM content

  • Mandatory : NO
  • Default : root

Value should be group name and not GID. Note that <compName> must be in upper-case.

CPACK_RPM_DEFAULT_FILE_PERMISSIONS
CPACK_RPM_<compName>_DEFAULT_FILE_PERMISSIONS

default permissions used for packaged files

  • Mandatory : NO
  • Default : - (system default)

Accepted values are lists with PERMISSIONS. Valid permissions are:

  • OWNER_READ
  • OWNER_WRITE
  • OWNER_EXECUTE
  • GROUP_READ
  • GROUP_WRITE
  • GROUP_EXECUTE
  • WORLD_READ
  • WORLD_WRITE
  • WORLD_EXECUTE

Note that <compName> must be in upper-case.

CPACK_RPM_DEFAULT_DIR_PERMISSIONS
CPACK_RPM_<compName>_DEFAULT_DIR_PERMISSIONS

default permissions used for packaged directories

  • Mandatory : NO
  • Default : - (system default)

Accepted values are lists with PERMISSIONS. Valid permissions are the same as for CPACK_RPM_DEFAULT_FILE_PERMISSIONS. Note that <compName> must be in upper-case.

CPACK_RPM_INSTALL_WITH_EXEC

force execute permissions on programs and shared libraries

  • Mandatory : NO
  • Default : - (system default)

Force set owner, group and world execute permissions on programs and shared libraries. This can be used for creating valid rpm packages on systems such as Debian where shared libraries do not have execute permissions set.

Note

Programs and shared libraries without execute permissions are ignored during separation of debug symbols from the binary for debuginfo packages.

Packaging of Symbolic Links

The CPack RPM generator supports packaging of symbolic links:

execute_process(COMMAND ${CMAKE_COMMAND}
  -E create_symlink <relative_path_location> <symlink_name>)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/<symlink_name>
  DESTINATION <symlink_location> COMPONENT libraries)

Symbolic links will be optimized (paths will be shortened if possible) before being added to the package or if multiple relocation paths are detected, a post install symlink relocation script will be generated.

Symbolic links may point to locations that are not packaged by the same package (either a different component or even not packaged at all) but those locations will be treated as if they were a part of the package while determining if symlink should be either created or present in a post install script - depending on relocation paths.

Symbolic links that point to locations outside packaging path produce a warning and are treated as non relocatable permanent symbolic links.

Currently there are a few limitations though:

  • For component based packaging component interdependency is not checked when processing symbolic links. Symbolic links pointing to content of a different component are treated the same way as if pointing to location that will not be packaged.
  • Symbolic links pointing to a location through one or more intermediate symbolic links will not be handled differently - if the intermediate symbolic link(s) is also on a relocatable path, relocating it during package installation may cause initial symbolic link to point to an invalid location.

Packaging of debug information

Debuginfo packages contain debug symbols and sources for debugging packaged binaries.

Debuginfo RPM packaging has its own set of variables:

CPACK_RPM_DEBUGINFO_PACKAGE
CPACK_RPM_<component>_DEBUGINFO_PACKAGE

Enable generation of debuginfo RPM package(s).

  • Mandatory : NO
  • Default : OFF

Note

Binaries must contain debug symbols before packaging so use either Debug or RelWithDebInfo for CMAKE_BUILD_TYPE variable value.

Note

Packages generated from packages without binary files, with binary files but without execute permissions or without debug symbols will cause packaging termination.

CPACK_BUILD_SOURCE_DIRS

Provides locations of root directories of source files from which binaries were built.

  • Mandatory : YES if CPACK_RPM_DEBUGINFO_PACKAGE is set
  • Default : -

Note

For CMake project CPACK_BUILD_SOURCE_DIRS is set by default to point to CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR paths.

Note

Sources with path prefixes that do not fall under any location provided with CPACK_BUILD_SOURCE_DIRS will not be present in debuginfo package.

CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX
CPACK_RPM_<component>_BUILD_SOURCE_DIRS_PREFIX

Prefix of location where sources will be placed during package installation.

  • Mandatory : YES if CPACK_RPM_DEBUGINFO_PACKAGE is set
  • Default : “/usr/src/debug/<CPACK_PACKAGE_FILE_NAME>” and
    for component packaging “/usr/src/debug/<CPACK_PACKAGE_FILE_NAME>-<component>”

Note

Each source path prefix is additionally suffixed by src_<index> where index is index of the path used from CPACK_BUILD_SOURCE_DIRS variable. This produces <CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX>/src_<index> replacement path. Limitation is that replaced path part must be shorter or of equal length than the length of its replacement. If that is not the case either CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX variable has to be set to a shorter path or source directories must be placed on a longer path.

CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS

Directories containing sources that should be excluded from debuginfo packages.

  • Mandatory : NO
  • Default : “/usr /usr/src /usr/src/debug”

Listed paths are owned by other RPM packages and should therefore not be deleted on debuginfo package uninstallation.

CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS_ADDITION

Paths that should be appended to CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS for exclusion.

  • Mandatory : NO
  • Default : -
CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE

Create a single debuginfo package even if components packaging is set.

  • Mandatory : NO
  • Default : OFF

When this variable is enabled it produces a single debuginfo package even if component packaging is enabled.

When using this feature in combination with components packaging and there is more than one component this variable requires CPACK_RPM_MAIN_COMPONENT to be set.

Note

If none of the CPACK_RPM_<component>_DEBUGINFO_PACKAGE variables is set then CPACK_RPM_DEBUGINFO_PACKAGE is automatically set to ON when CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE is set.

CPACK_RPM_DEBUGINFO_FILE_NAME
CPACK_RPM_<component>_DEBUGINFO_FILE_NAME

Debuginfo package file name.

  • Mandatory : NO
  • Default : rpmbuild tool generated package file name

Alternatively provided debuginfo package file name must end with .rpm suffix and should differ from file names of other generated packages.

Variable may contain @cpack_component@ placeholder which will be replaced by component name if component packaging is enabled otherwise it deletes the placeholder.

Setting the variable to RPM-DEFAULT may be used to explicitly set filename generation to default.

Note

CPACK_RPM_FILE_NAME also supports rpmbuild tool generated package file name - disabled by default but can be enabled by setting the variable to RPM-DEFAULT.

Packaging of sources (SRPM)

SRPM packaging is enabled by setting CPACK_RPM_PACKAGE_SOURCES variable while usually using CPACK_INSTALLED_DIRECTORIES variable to provide directory containing CMakeLists.txt and source files.

For CMake projects SRPM package would be produced by executing:

cpack -G RPM --config ./CPackSourceConfig.cmake

Note

Produced SRPM package is expected to be built with cmake(1) executable and packaged with cpack(1) executable so CMakeLists.txt has to be located in root source directory and must be able to generate binary rpm packages by executing cpack -G command. The two executables as well as rpmbuild must also be present when generating binary rpm packages from the produced SRPM package.

Once the SRPM package is generated it can be used to generate binary packages by creating a directory structure for rpm generation and executing rpmbuild tool:

mkdir -p build_dir/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
rpmbuild --define "_topdir <path_to_build_dir>" --rebuild <SRPM_file_name>

Generated packages will be located in build_dir/RPMS directory or its sub directories.

Note

SRPM package internally uses CPack/RPM generator to generate binary packages so CMakeScripts.txt can decide during the SRPM to binary rpm generation step what content the package(s) should have as well as how they should be packaged (monolithic or components). CMake can decide this for e.g. by reading environment variables set by the package manager before starting the process of generating binary rpm packages. This way a single SRPM package can be used to produce different binary rpm packages on different platforms depending on the platform’s packaging rules.

Source RPM packaging has its own set of variables:

CPACK_RPM_PACKAGE_SOURCES

Should the content be packaged as a source rpm (default is binary rpm).

  • Mandatory : NO
  • Default : OFF

Note

For cmake projects CPACK_RPM_PACKAGE_SOURCES variable is set to OFF in CPackConfig.cmake and ON in CPackSourceConfig.cmake generated files.

CPACK_RPM_SOURCE_PKG_BUILD_PARAMS

Additional command-line parameters provided to cmake(1) executable.

  • Mandatory : NO
  • Default : -
CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX

Packaging install prefix that would be provided in CPACK_PACKAGING_INSTALL_PREFIX variable for producing binary RPM packages.

  • Mandatory : YES
  • Default : “/”
CPACK_RPM_BUILDREQUIRES

List of source rpm build dependencies.

  • Mandatory : NO
  • Default : -

May be used to set source RPM build dependencies (BuildRequires). Note that you must enclose the complete build requirements string between quotes, for example:

set(CPACK_RPM_BUILDREQUIRES "python >= 2.5.0, cmake >= 2.8")

  • cpack-generators(7) »


CPack WIX Generator — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • cpack-generators(7) »

CPack WIX Generator

CPack WIX generator specific options

Variables specific to CPack WIX generator

The following variables are specific to the installers built on Windows using WiX.

CPACK_WIX_UPGRADE_GUID

Upgrade GUID (Product/@UpgradeCode)

Will be automatically generated unless explicitly provided.

It should be explicitly set to a constant generated globally unique identifier (GUID) to allow your installers to replace existing installations that use the same GUID.

You may for example explicitly set this variable in your CMakeLists.txt to the value that has been generated per default. You should not use GUIDs that you did not generate yourself or which may belong to other projects.

A GUID shall have the following fixed length syntax:

XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

(each X represents an uppercase hexadecimal digit)

CPACK_WIX_PRODUCT_GUID

Product GUID (Product/@Id)

Will be automatically generated unless explicitly provided.

If explicitly provided this will set the Product Id of your installer.

The installer will abort if it detects a pre-existing installation that uses the same GUID.

The GUID shall use the syntax described for CPACK_WIX_UPGRADE_GUID.

CPACK_WIX_LICENSE_RTF

RTF License File

If CPACK_RESOURCE_FILE_LICENSE has an .rtf extension it is used as-is.

If CPACK_RESOURCE_FILE_LICENSE has an .txt extension it is implicitly converted to RTF by the WIX Generator. The expected encoding of the .txt file is UTF-8.

With CPACK_WIX_LICENSE_RTF you can override the license file used by the WIX Generator in case CPACK_RESOURCE_FILE_LICENSE is in an unsupported format or the .txt -> .rtf conversion does not work as expected.

CPACK_WIX_PRODUCT_ICON

The Icon shown next to the program name in Add/Remove programs.

If set, this icon is used in place of the default icon.

CPACK_WIX_UI_REF

This variable allows you to override the Id of the <UIRef> element in the WiX template.

The default is WixUI_InstallDir in case no CPack components have been defined and WixUI_FeatureTree otherwise.

CPACK_WIX_UI_BANNER

The bitmap will appear at the top of all installer pages other than the welcome and completion dialogs.

If set, this image will replace the default banner image.

This image must be 493 by 58 pixels.

CPACK_WIX_UI_DIALOG

Background bitmap used on the welcome and completion dialogs.

If this variable is set, the installer will replace the default dialog image.

This image must be 493 by 312 pixels.

CPACK_WIX_PROGRAM_MENU_FOLDER

Start menu folder name for launcher.

If this variable is not set, it will be initialized with CPACK_PACKAGE_NAME

CPACK_WIX_CULTURES

Language(s) of the installer

Languages are compiled into the WixUI extension library. To use them, simply provide the name of the culture. If you specify more than one culture identifier in a comma or semicolon delimited list, the first one that is found will be used. You can find a list of supported languages at: http://wix.sourceforge.net/manual-wix3/WixUI_localization.htm

CPACK_WIX_TEMPLATE

Template file for WiX generation

If this variable is set, the specified template will be used to generate the WiX wxs file. This should be used if further customization of the output is required.

If this variable is not set, the default MSI template included with CMake will be used.

CPACK_WIX_PATCH_FILE

Optional list of XML files with fragments to be inserted into generated WiX sources

This optional variable can be used to specify an XML file that the WIX generator will use to inject fragments into its generated source files.

Patch files understood by the CPack WIX generator roughly follow this RELAX NG compact schema:

start = CPackWiXPatch

CPackWiXPatch = element CPackWiXPatch { CPackWiXFragment* }

CPackWiXFragment = element CPackWiXFragment
{
    attribute Id { string },
    fragmentContent*
}

fragmentContent = element * - CPackWiXFragment
{
    (attribute * { text } | text | fragmentContent)*
}

Currently fragments can be injected into most Component, File, Directory and Feature elements.

The following additional special Ids can be used:

  • #PRODUCT for the <Product> element.
  • #PRODUCTFEATURE for the root <Feature> element.

The following example illustrates how this works.

Given that the WIX generator creates the following XML element:

<Component Id="CM_CP_applications.bin.my_libapp.exe" Guid="*"/>

The following XML patch file may be used to inject an Environment element into it:

<CPackWiXPatch>
  <CPackWiXFragment Id="CM_CP_applications.bin.my_libapp.exe">
    <Environment Id="MyEnvironment" Action="set"
      Name="MyVariableName" Value="MyVariableValue"/>
  </CPackWiXFragment>
</CPackWiXPatch>
CPACK_WIX_EXTRA_SOURCES

Extra WiX source files

This variable provides an optional list of extra WiX source files (.wxs) that should be compiled and linked. The full path to source files is required.

CPACK_WIX_EXTRA_OBJECTS

Extra WiX object files or libraries

This variable provides an optional list of extra WiX object (.wixobj) and/or WiX library (.wixlib) files. The full path to objects and libraries is required.

CPACK_WIX_EXTENSIONS

This variable provides a list of additional extensions for the WiX tools light and candle.

CPACK_WIX_<TOOL>_EXTENSIONS

This is the tool specific version of CPACK_WIX_EXTENSIONS. <TOOL> can be either LIGHT or CANDLE.

CPACK_WIX_<TOOL>_EXTRA_FLAGS

This list variable allows you to pass additional flags to the WiX tool <TOOL>.

Use it at your own risk. Future versions of CPack may generate flags which may be in conflict with your own flags.

<TOOL> can be either LIGHT or CANDLE.

CPACK_WIX_CMAKE_PACKAGE_REGISTRY

If this variable is set the generated installer will create an entry in the windows registry key HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\<PackageName> The value for <PackageName> is provided by this variable.

Assuming you also install a CMake configuration file this will allow other CMake projects to find your package with the find_package() command.

CPACK_WIX_PROPERTY_<PROPERTY>

This variable can be used to provide a value for the Windows Installer property <PROPERTY>

The following list contains some example properties that can be used to customize information under “Programs and Features” (also known as “Add or Remove Programs”)

  • ARPCOMMENTS - Comments
  • ARPHELPLINK - Help and support information URL
  • ARPURLINFOABOUT - General information URL
  • ARPURLUPDATEINFO - Update information URL
  • ARPHELPTELEPHONE - Help and support telephone number
  • ARPSIZE - Size (in kilobytes) of the application
CPACK_WIX_ROOT_FEATURE_TITLE

Sets the name of the root install feature in the WIX installer. Same as CPACK_COMPONENT_<compName>_DISPLAY_NAME for components.

CPACK_WIX_ROOT_FEATURE_DESCRIPTION

Sets the description of the root install feature in the WIX installer. Same as CPACK_COMPONENT_<compName>_DESCRIPTION for components.

CPACK_WIX_SKIP_PROGRAM_FOLDER

If this variable is set to true, the default install location of the generated package will be CPACK_PACKAGE_INSTALL_DIRECTORY directly. The install location will not be located relatively below ProgramFiles or ProgramFiles64.

Note

Installers created with this feature do not take differences between the system on which the installer is created and the system on which the installer might be used into account.

It is therefore possible that the installer e.g. might try to install onto a drive that is unavailable or unintended or a path that does not follow the localization or convention of the system on which the installation is performed.

CPACK_WIX_ROOT_FOLDER_ID

This variable allows specification of a custom root folder ID. The generator specific <64> token can be used for folder IDs that come in 32-bit and 64-bit variants. In 32-bit builds the token will expand empty while in 64-bit builds it will expand to 64.

When unset generated installers will default installing to ProgramFiles<64>Folder.

CPACK_WIX_ROOT

This variable can optionally be set to the root directory of a custom WiX Toolset installation.

When unspecified CPack will try to locate a WiX Toolset installation via the WIX environment variable instead.

  • cpack-generators(7) »


CMake Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »

CMake Release Notes

Releases

  • 3.14
  • 3.13
  • 3.12
  • 3.11
  • 3.10
  • 3.9
  • 3.8
  • 3.7
  • 3.6
  • 3.5
  • 3.4
  • 3.3
  • 3.2
  • 3.1
  • 3.0


CMake 3.14 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.14 Release Notes

Contents

  • CMake 3.14 Release Notes
    • New Features
      • Generators
      • File-Based API
      • Platforms
      • Command-Line
      • Commands
      • Variables
      • Properties
      • Modules
      • Generator Expressions
      • Autogen
      • CTest
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.13 include the following.

New Features

Generators

  • The Visual Studio 16 2019 generator was added. This is experimental and based on “Visual Studio 2019 Preview 4” because this version of VS has not been released.

    The VS 2019 generator differs from generators for earlier versions in that it does not provide variants that specify the target platform in the generator name. Instead CMAKE_GENERATOR_PLATFORM must be used, e.g. through the -A command-line option. Furthermore, the default target platform (architecture) is now based on the host platform. The VS host toolset selection is now based on the host architecture as well.

  • The Green Hills MULTI generator has been updated:

    • Now supports Object Libraries.
    • Now warns on unsupported project types such as shared libraries.
    • Now generates a top-level <PROJECT-NAME>.top.gpj for each directory calling the project() command. The top-level project file default.gpj is no longer created.
    • Now honors target renaming and destination output control properties such as RUNTIME_OUTPUT_DIRECTORY and OUTPUT_NAME. This also fixes support for installation rules generated by install().
    • Now honors source file properties INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS, and COMPILE_OPTIONS.
    • Now supports Dynamic Download Integrity Applications which did not include Integrate Files via GHS_INTEGRITY_APP and setting a target link flag of -dynamic.
    • The contents of project files now sorts sources groups and files by name. Set the GHS_NO_SOURCE_GROUP_FILE target property to ON to generate a single project file for the target instead of a project file for each source group. Set the CMAKE_GHS_NO_SOURCE_GROUP_FILE variable to enable this for all targets.

File-Based API

  • A file-based api for clients to get semantic buildsystem information has been added. See the cmake-file-api(7) manual. This is intended to replace the cmake-server(7) mode for IDEs.

Platforms

  • CMake now supports Cross Compiling for iOS, tvOS, or watchOS using simple toolchain files.

Command-Line

  • The cmake(1) Build Tool Mode (cmake --build) gained --verbose and -v options to specify verbose build output. Some generators such as Xcode don’t support this option currently.
  • The cmake(1) -E compare_files command learned a new --ignore-eol option to specify that end-of-line differences (e.g. LF vs CRLF) should be ignored when comparing files.
  • The cmake-gui(1) dialog gained new -S and -B arguments to explicitly specify source and build directories.

Commands

  • The file() command learned a new sub-command, CREATE_LINK, which can be used to create hard or symbolic links.
  • The file() command learned a new sub-command, READ_SYMLINK, which can be used to determine the path that a symlink points to.
  • The file() command gained a SIZE mode to get the size of a file on disk.
  • The find_package() command learned to optionally resolve symbolic links in the paths to package configuration files. See the CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS variable.
  • The get_filename_component() command gained new LAST_EXT and NAME_WLE variants to work with the extension after the last . in the name.
  • The if() command gained support for checking if cache variables are defined with the DEFINED CACHE{VAR} syntax.
  • The install(CODE) and install(SCRIPT) commands learned to support generator expressions. See policy CMP0087.
  • The install(TARGETS) command learned how to install to an appropriate default directory for a given target type, based on variables from the GNUInstallDirs module and built-in defaults, in lieu of a DESTINATION argument.
  • The install(FILES) and install(DIRECTORY) commands learned a new set of parameters for installing files as a file type, setting the destination based on the appropriate variables from GNUInstallDirs and built-in defaults, in lieu of a DESTINATION argument.
  • The list() operations REMOVE_ITEM, REMOVE_DUPLICATES, SORT, REVERSE, and FILTER all now accept a non-existent variable as the list since these operations on empty lists is also the empty list.
  • The list() operation REMOVE_AT now indicates that the given indices are invalid for a non-existent variable or empty list.
  • The try_compile() and try_run() commands gained a new LINK_OPTIONS option.

Variables

  • A CMAKE_BUILD_RPATH_USE_ORIGIN variable and corresponding BUILD_RPATH_USE_ORIGIN target property were added to enable use of relative runtime paths (RPATHs). This helps achieving relocatable and reproducible builds that are invariant of the build directory.

Properties

  • A CMAKE_ROLE global property was added to allow scripts to determine whether they’re running in project mode, script mode, find-package mode, CTest, or CPack.
  • The CUDA_RESOLVE_DEVICE_SYMBOLS target property is now supported on shared library, module library, and executable targets. Previously it was only honored on static libraries.
  • The EXCLUDE_FROM_ALL target property was created to override the setting of its directory. A target will now be built as part of “all” if its EXCLUDE_FROM_ALL property is set to OFF, even if its containing directory is marked as EXCLUDE_FROM_ALL.
  • INTERFACE_POSITION_INDEPENDENT_CODE target property gains the support of generator expressions.

Modules

  • The family of modules to check capabilities (like CheckCSourceCompiles) gain capability to manage LINK_OPTIONS.

  • A CheckFortranSourceRuns module was added to provide a check_fortran_source_runs() command to check if a Fortran source snippet compiles and runs.

  • The CMakePackageConfigHelpers module’s write_basic_package_version_file() command gained a new ARCH_INDEPENDENT option for supporting architecture-independent packages.

  • The ExternalProject module ExternalProject_Add() command gained LOG_DIR and LOG_MERGED_STDOUTERR options to control logging.

  • The ExternalProject module ExternalProject_Add() command gained LOG_PATCH to optionally log the patch step.

  • The ExternalProject module ExternalProject_Add() command learned to apply SOURCE_SUBDIR when BUILD_IN_SOURCE is also used. The BUILD_COMMAND is run in the given SOURCE_SUBDIR of the SOURCE_DIR.

  • The FetchContent module gained a new FetchContent_MakeAvailable() command. It accepts a list of dependency names, which it then iterates over, populating and adding each one to the main build using the canonical pattern. This significantly reduces the amount of boilerplate needed in a project.

  • The FindBISON module’s BISON_TARGET command now runs bison with CMAKE_CURRENT_BINARY_DIR as the working directory. See policy CMP0088.

  • The FindCURL module gained support for requesting protocols as package components.

  • The FindFontconfig module was added to find fontconfig.

  • The FindGDAL module now provides imported targets.

  • The FindGIF module now provides imported targets.

  • The FindGit module now provides an imported target for the Git executable.

  • The FindIce module learned to find slice2confluence and slice2matlab.

  • The FindLibinput module was added to find libinput.

  • The FindLibLZMA module now provides imported targets.

  • The FindMatlab module gained new options R2017b and R2018a to specify the MEX API version to use; these options mirror the new options to the mex command in MATLAB R2018a. The option MX_LIBRARY is no longer needed.

  • The FindPostgreSQL module now provides imported targets.

  • The FindPython, FindPython2, and FindPython3 modules gained support for NumPy component.

  • The FindPython2, FindPython3, and FindPython modules now support running in script mode by skipping the creation of imported targets and helper functions.

  • The FindSQLite3 module was added to find the SQLite v3.x library.

  • The FindX11 had the following variables renamed in order to match their library names rather than header names. The old variables are provided for compatibility:

    • X11_Xxf86misc_INCLUDE_PATH instead of X11_xf86misc_INCLUDE_PATH
    • X11_Xxf86misc_LIB instead of X11_xf86misc_LIB
    • X11_Xxf86misc_FOUND instead of X11_xf86misc_FOUND
    • X11_Xxf86vm_INCLUDE_PATH instead of X11_xf86vmode_INCLUDE_PATH
    • X11_Xxf86vm_LIB instead of X11_xf86vmode_LIB
    • X11_Xxf86vm_FOUND instead of X11_xf86vmode_FOUND
    • X11_xkbfile_INCLUDE_PATH instead of X11_Xkbfile_INCLUDE_PATH
    • X11_xkbfile_LIB instead of X11_Xkbfile_LIB
    • X11_xkbfile_FOUND instead of X11_Xkbfile_FOUND
    • X11_Xtst_INCLUDE_PATH instead of X11_XTest_INCLUDE_PATH
    • X11_Xtst_LIB instead of X11_XTest_LIB
    • X11_Xtst_FOUND instead of X11_XTest_FOUND
    • X11_Xss_INCLUDE_PATH instead of X11_Xscreensaver_INCLUDE_PATH
    • X11_Xss_LIB instead of X11_Xscreensaver_LIB
    • X11_Xss_FOUND instead of X11_Xscreensaver_FOUND

    The following variables are deprecated completely since they were essentially duplicates:

    • X11_Xinput_INCLUDE_PATH (use X11_Xi_INCLUDE_PATH)
    • X11_Xinput_LIB (use X11_Xi_LIB)
    • X11_Xinput_FOUND (use X11_Xi_FOUND)

  • The FindX11 now provides X11_Xext_INCLUDE_PATH.

  • The FindX11 now provides imported targets.

  • The UseSWIG module learned to pass -module <module_name> to the SWIG compiler if the file property SWIG_MODULE_NAME is defined. See policy CMP0086.

  • The UseSWIG module gained an option to specify SWIG source file extensions.

Generator Expressions

  • The $<Fortran_COMPILER_ID:...> and $<Fortran_COMPILER_VERSION:...> generator expressions were added.
  • The $<IN_LIST:...> generator expression now correctly handles an empty argument. See CMP0085 for details.

Autogen

  • The AUTOMOC_EXECUTABLE, AUTORCC_EXECUTABLE, and AUTOUIC_EXECUTABLE target properties were added. They all take a path to an executable and force automoc/autorcc/autouic to use this executable.

    Setting these will also prevent the configure time testing for these executables. This is mainly useful when you build these tools yourself.

  • The new variables CMAKE_GLOBAL_AUTOGEN_TARGET, CMAKE_GLOBAL_AUTOGEN_TARGET_NAME, CMAKE_GLOBAL_AUTORCC_TARGET and CMAKE_GLOBAL_AUTORCC_TARGET_NAME control the generation of global autogen and autorcc targets.

  • A new CMAKE_AUTOGEN_ORIGIN_DEPENDS variable and AUTOGEN_ORIGIN_DEPENDS target property may be set to enable or disable forwarding of the origin target dependencies to the corresponding _autogen target.

CTest

  • ctest(1) gained a --show-only=json-v1 option to show the list of tests in a machine-readable JSON format. See the Show as JSON Object Model section of the manual.
  • The ctest_submit() command learned a new Done part that can be used to inform CDash that a build is complete and that no more parts will be uploaded.
  • CTest learned to accept the dashboard server submission URL from a single variable. See the SubmitURL setting in ctest(1), the CTEST_SUBMIT_URL variable, and the SUBMIT_URL argument of the ctest_submit() command.

Deprecated and Removed Features

  • An explicit deprecation diagnostic was added for policies CMP0064 and CMP0065 (CMP0063 and below were already deprecated). The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors.
  • The Xcode generator deprecated support for Xcode versions prior to Xcode 5. Support for those will be dropped in a future version of CMake.
  • The FindQt module is no longer used by the find_package() command as a find module. This allows the Qt Project upstream to optionally provide its own QtConfig.cmake package configuration file and have applications use it via find_package(Qt) rather than find_package(Qt CONFIG). See policy CMP0084.
  • Support for running CMake on Windows XP and Windows Vista has been dropped. The precompiled Windows binaries provided on cmake.org now require Windows 7 or higher.
  • CTest no longer supports submissions via ftp, scp, cp, and xmlrpc. CDash is the only maintained testing dashboard for CTest, and it only supports submissions over http and https.

Other Changes

  • Object library linking has been fixed to propagate private link libraries of object libraries to consuming targets.
  • Install rules under add_subdirectory() now interleave with those in the calling directory. See policy CMP0082 for details.
  • CMake now imposes a maximum recursion limit to prevent a stack overflow on scripts that recurse infinitely. The limit can be adjusted at runtime with CMAKE_MAXIMUM_RECURSION_DEPTH.
  • When using cppcheck via the CMAKE_<LANG>_CPPCHECK variable or <LANG>_CPPCHECK property, the build will now fail if cppcheck returns non-zero as configured by its command-line options.
  • Required link options to manage Position Independent Executable are now added when POSITION_INDEPENDENT_CODE is set. The project is responsible for using the CheckPIESupported module to check for PIE support to ensure that the POSITION_INDEPENDENT_CODE target property will be honored at link time for executables. This behavior is controlled by policy CMP0083.
  • Visual Studio Generators for VS 2010 and above learned to support the VS_DEBUGGER_* properties on targets created via add_custom_target().
  • The CPack module no longer defaults to the paxr value in the CPACK_DEBIAN_ARCHIVE_TYPE variable, because dpkg has never supported the PAX tar format. The paxr value will be mapped to gnutar and a deprecation message emitted.
  • CMake no longer issues a warning if a target listed in an install(TARGETS) command has its EXCLUDE_FROM_ALL property set to true.

  • CMake Release Notes »


CMake 3.13 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.13 Release Notes

Contents

  • CMake 3.13 Release Notes
    • New Features
      • Generators
      • Command-Line
      • Commands
      • Variables
      • Properties
      • Modules
      • CTest
      • CPack
    • Deprecated and Removed Features
    • Other Changes
    • Updates
      • 3.13.2
      • 3.13.3
      • 3.13.4

Changes made since CMake 3.12 include the following.

New Features

Generators

  • The Visual Studio Generators for VS 2010 and above learned to support the INTERPROCEDURAL_OPTIMIZATION target property and supporting CheckIPOSupported module.
  • The Xcode generator learned to configure more Xcode Scheme fields. See the CMAKE_XCODE_GENERATE_SCHEME variable.
  • The Green Hills MULTI generator has been updated:
    • Added support for architecture selection through CMAKE_GENERATOR_PLATFORM: e.g. arm, ppc, and 86.
    • Added support for toolset selection through CMAKE_GENERATOR_TOOLSET, e.g. comp_201205, comp_201510, comp_201722_beta.
    • Added support for platform selection through GHS_TARGET_PLATFORM, e.g. integrity, linux, standalone, etc.
    • No longer checks that arm based compilers are installed but ensures that the correct gbuild.exe exists.
    • No longer hard-codes ARM files, BSP, toolset, or OS locations.

Command-Line

  • The cmake(1) command gained the -S <source_dir> command line option to specify the location of the source directory. This option can be used independently of -B.
  • The cmake(1) command gained the -B <build_dir> command line option to specify the location of the build directory. This option can be used independently of -S.
  • The cmake(1) -E create_symlink command can now be used on Windows.

Commands

  • The add_custom_command() and add_custom_target() commands learned to support generator expressions in WORKING_DIRECTORY options.
  • The add_link_options() command was created to add link options in the current directory.
  • The install(TARGETS) command learned to install targets created outside the current directory.
  • The link_directories() command gained options to control insertion position.
  • The list(SORT) command gained options to control the comparison operation used to order the entries.
  • The math() command gained options for hexadecimal.
  • The target_link_directories() command was created to specify link directories for targets and their dependents.
  • The target_link_options() command was created to specify link options for targets and their dependents.
  • The target_link_libraries() command may now be called to modify targets created outside the current directory. See policy CMP0079.

Variables

  • A CMAKE_AUTOGEN_VERBOSE variable was added to optionally increase the verbosity of AUTOMOC, AUTOUIC and AUTORCC from within CMake project code.
  • A CMAKE_VS_GLOBALS variable was added to initialize VS_GLOBAL_<variable> target properties on targets as they are created.

Properties

  • The DEPLOYMENT_ADDITIONAL_FILES target property was added to tell the Visual Studio 9 2008 generator to specify additional files for deployment to WinCE devices for remote debugging.
  • The INTERFACE_LINK_DEPENDS target property was created to specify transitive link dependencies on files.
  • The LINK_DEPENDS target property learned to support generator expressions.
  • LINK_DIRECTORIES and INTERFACE_LINK_DIRECTORIES target properties were added to collect link directories for a target and its dependents. Use the target_link_directories() command to set them.
  • LINK_OPTIONS and INTERFACE_LINK_OPTIONS target properties were added to collect link options for a target and its dependents. Use the target_link_options() command to set them.
  • A LINK_OPTIONS directory property was added to collect link options for targets created under the current directory. Use the add_link_options() command to set it.
  • A STATIC_LIBRARY_OPTIONS target property was created to specify archiver options to use when creating static libraries.
  • A VS_DEBUGGER_COMMAND_ARGUMENTS target property was created to set the debugging command line arguments with Visual Studio Generators for VS 2010 and above.
  • A VS_DEBUGGER_ENVIRONMENT target property was created to set the debugging environment with Visual Studio Generators for VS 2010 and above.
  • The VS_DEBUGGER_COMMAND and VS_DEBUGGER_WORKING_DIRECTORY target properties now support generator expressions.

Modules

  • The FindBoost module gained a Boost_ARCHITECTURE option to specify a Boost architecture-specific library filename fragment.
  • The FindCURL module learned to find debug and release variants separately.
  • The FindMatlab module gained new components ENGINE_LIBRARY and DATAARRAY_LIBRARY to request finding the Matlab C++ Engine and DataArray libraries respectively.
  • The FindMatlab module now explicitly exports mexFunction in Visual Studio.
  • The FindMatlab module gained a new MCC_COMPILER component to request finding the Matlab Compiler add-on.
  • The FindPkgConfig module gained an option to create imported targets in global scope.
  • The FindPkgConfig module gained support for < and > operators for version checks in addition to the already supported operators >=, <=, and =.
  • Modules FindPython3, FindPython2 and FindPython gain capability to control order of resource lookup on macOS (Framework) and Windows (Registry).
  • The FindSubversion module Subversion_WC_INFO command gained an IGNORE_SVN_FAILURE option to suppress failures, e.g. when the source tree is not under Subversion control.
  • The UseSWIG module learned to manage target property INCLUDE_DIRECTORIES for SWIG compilation.

CTest

  • ctest(1) gained a --progress option to enable a live test progress summary when output goes to a terminal.

CPack

  • The CPack DEB Generator learned to split debug symbols into a corresponding .ddeb package when CPACK_DEBIAN_DEBUGINFO_PACKAGE is set.
  • The CPack DEB Generator learned to honor the SOURCE_DATE_EPOCH environment variable when packaging files. This is useful for generating reproducible packages.
  • CPack gained a new CPack External Generator which is used to export the CPack metadata in a format that other software can understand. The intention of this generator is to allow external packaging software to take advantage of CPack’s features when it may not be possible to use CPack for the entire packaging process.

Deprecated and Removed Features

  • An explicit deprecation diagnostic was added for policies CMP0055 through CMP0063 (CMP0054 and below were already deprecated). The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors.

Other Changes

  • The precompiled binaries provided on cmake.org now include qthelp-format documentation.
  • The option() command now honors an existing normal variable of the same name and does nothing instead of possibly creating a cache entry (or setting its type) and removing the normal variable. See policy CMP0077.
  • The Makefile Generators learned to remove custom command and custom target byproducts during make clean.
  • The target_sources() command now interprets relative source file paths as relative to the current source directory. This simplifies incrementally building up a target’s sources from subdirectories. The CMP0076 policy was added to provide backward compatibility with the old behavior where required.
  • The BundleUtilities module may no longer be included at configure time. This was always a bug anyway. See policy CMP0080.
  • The UseSWIG module has changed strategy for target naming. See policy CMP0078.
  • The LINK_DIRECTORIES target property now expects absolute paths. See policy CMP0081.
  • The CPack generators have been moved into their own separate section in the documentation, rather than having the documentation in their internal implementation modules. These internal implementation modules are also no longer available to scripts that may have been incorrectly including them, because they should never have been available in the first place.

Updates

Changes made since CMake 3.13.0 include the following.

3.13.2

  • CMake 3.13.0 included a change to pass compiler implicit include directories to the moc tool for AUTOMOC. This has been reverted due to regressing existing builds and will need further investigation before being re-introduced in a later release.

3.13.3

  • The Visual Studio 15 2017 generator has been fixed to work when VS 2019 is installed.
  • CMake now checks that at least one of the source or binary directory is specified when running CMake and issues an error if both are missing. This has always been a documented requirement, but the implementation previously accidentally accepted cases in which neither are specified so long as some other argument is given, and silently used the current working directory as the source and build tree.

3.13.4

  • The error added by 3.13.3 in cases that neither a source or binary directory is specified has been downgraded to a warning. While this was never intended, documented, nor supported behavior, some projects relied on it. The error has been downgraded to a warning for the remainder of the 3.13.x release series to allow a transition period, but it may become a fatal error again in a later release. Scripts relying on the old behavior can be trivially fixed by specifying the path to the source tree (even if just .) explicitly and continue to work with all versions of CMake.

  • CMake Release Notes »


CMake 3.12 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.12 Release Notes

Contents

  • CMake 3.12 Release Notes
    • New Features
      • Generators
      • Command-Line
      • Commands
      • Variables
      • Properties
      • Modules
      • Generator Expressions
      • CTest
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.11 include the following.

New Features

Generators

  • The Visual Studio Generators for VS 2017 learned to support a version=14.## option in the CMAKE_GENERATOR_TOOLSET value (e.g. via the cmake(1) -T option) to specify a toolset version number.

Command-Line

  • The cmake(1) Build a Project (cmake --build) gained --parallel [<jobs>] and -j [<jobs>] options to specify a parallel build level. They map to corresponding options of the native build tool.

Commands

  • The add_compile_definitions() command was added to set preprocessor definitions at directory level. This supersedes add_definitions().
  • The cmake_minimum_required() and cmake_policy(VERSION) commands now accept a version range using the form <min>[...<max>]. The <min> version is required but policies are set based on the older of the running CMake version and the version specified by <max>. This allows projects to specify a range of versions for which they have been updated and avoid explicit policy settings.
  • The file(GLOB) and file(GLOB_RECURSE) commands learned a new flag CONFIGURE_DEPENDS which enables expression of build system dependency on globbed directory’s contents.
  • The file(TOUCH) and file(TOUCH_NOCREATE) commands were added to expose TOUCH functionality without having to use CMake’s command-line tool mode with execute_process().
  • The find_package() command now searches prefixes specified by the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable. Package roots are maintained as a stack so nested calls to all find_* commands inside find modules also search the roots as prefixes. See policy CMP0074.
  • The install() command learned an optional NAMELINK_COMPONENT parameter, which allows you to change the component for a shared library’s namelink. If none is specified, the value of COMPONENT is used by default.
  • The list() command learned a JOIN sub-command to concatenate list’s elements separated by a glue string.
  • The list() command learned a SUBLIST sub-command to get a sublist of the list.
  • The list() command learned a TRANSFORM sub-command to apply various string transformation to list’s elements.
  • The project() command learned an optional HOMEPAGE_URL parameter which has the effect of setting variables like PROJECT_HOMEPAGE_URL, <PROJECT-NAME>_HOMEPAGE_URL and CMAKE_PROJECT_HOMEPAGE_URL.
  • The string() command learned a JOIN sub-command to concatenate input strings separated by a glue string.
  • target_compile_options() and add_compile_options() commands gained a SHELL: prefix to specify a group of related options using shell-like quoting.
  • The target_link_libraries() command now supports Object Libraries. Linking to an object library uses its object files in direct dependents and also propagates usage requirements.

Variables

  • The CMAKE_FOLDER variable was added to initialize the FOLDER property on all targets.
  • The CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION variable was defined to initialize all DOTNET_TARGET_FRAMEWORK_VERSION target properties.
  • CMAKE_PROJECT_VERSION* variables have been introduced:
    • CMAKE_PROJECT_VERSION
    • CMAKE_PROJECT_VERSION_MAJOR
    • CMAKE_PROJECT_VERSION_MINOR
    • CMAKE_PROJECT_VERSION_PATCH
    • CMAKE_PROJECT_VERSION_TWEAK
  • The CMAKE_SUPPRESS_REGENERATION variable was extended to support the Ninja and Makefile Generators. It is also now documented.
  • CMAKE_VS_SDK_*_DIRECTORIES variables were defined to tell Visual Studio Generators for VS 2010 and above how to populate fields in .vcxproj files that specify SDK directories. The variables are:
    • CMAKE_VS_SDK_EXCLUDE_DIRECTORIES
    • CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES
    • CMAKE_VS_SDK_INCLUDE_DIRECTORIES
    • CMAKE_VS_SDK_LIBRARY_DIRECTORIES
    • CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES
    • CMAKE_VS_SDK_REFERENCE_DIRECTORIES
    • CMAKE_VS_SDK_SOURCE_DIRECTORIES
  • A MSVC_TOOLSET_VERSION variable was added to provide the MSVC toolset version associated with the current MSVC compiler version in MSVC_VERSION.

Properties

  • The COMMON_LANGUAGE_RUNTIME target property was introduced to configure the use of managed C++ for Visual Studio Generators for VS 2010 and above. A corresponding IMPORTED_COMMON_LANGUAGE_RUNTIME target property was added to support C++/CLI for imported targets.
  • The DOTNET_TARGET_FRAMEWORK_VERSION target property was introduced as replacement for VS_DOTNET_TARGET_FRAMEWORK_VERSION, which is considered deprecated now.
  • An EXPORT_PROPERTIES target property was added to specify a custom list of target properties to include in targets exported by the install(EXPORT) and export() commands.
  • The PDB_OUTPUT_DIRECTORY property learned to support generator expressions.
  • A TESTS directory property was added to hold the list of tests defined by the add_test() command.
  • A VS_DEBUGGER_COMMAND target property was created to set the debugging command line with Visual Studio Generators for VS 2010 and above.
  • HLSL source file properties VS_SHADER_DISABLE_OPTIMIZATIONS and VS_SHADER_ENABLE_DEBUG gained support for generator expressions.
  • HLSL source file property VS_SHADER_OBJECT_FILE_NAME has been added to the Visual Studio Generators for VS 2010 and above. The property specifies the file name of the compiled shader object.

Modules

  • The FindALSA module now provides imported targets.
  • The FindCURL module now provides imported targets.
  • The FindJPEG module now provides imported targets.
  • The FindLibXml2 module now provides imported targets.
  • The FindMatlab module now supports the Matlab Runtime Compiler (MCR) for compiling and linking matlab extensions.
  • A FindODBC module was added to find an Open Database Connectivity (ODBC) library.
  • The FindPkgConfig module has learned to export the found libraries with full path for direct consumption with the target_link_libraries() command.
  • New FindPython3 and FindPython2 modules, as well as a new FindPython module, have been added to provide a new way to locate python environments.
  • The UseSWIG module gained a whole refresh and is now more consistent with standard CMake commands to generate libraries and is fully configurable through properties.
  • The UseSWIG module learned to manage multiple behaviors through UseSWIG_MODULE_VERSION variable to ensure legacy support as well as more robust handling of SWIG advanced features (like %template).
  • The UseSWIG module learned to support CSHARP variant wrapper files.
  • The WriteCompilerDetectionHeader module gained a BARE_FEATURES option to add a compatibility define for the exact keyword of a new language feature.

Generator Expressions

  • A new $<GENEX_EVAL:...> and $<TARGET_GENEX_EVAL:target,...> generator expression has been added to enable consumption of generator expressions whose evaluation results itself in generator expressions.
  • A new $<IN_LIST:...> generator expression has been added.
  • A new $<TARGET_EXISTS:...> generator expression has been added.
  • A new $<TARGET_NAME_IF_EXISTS:...> generator expression has been added.

CTest

  • The ctest_start() command has been reworked so that you can simply call ctest_start(APPEND) and it will read all the needed information from the TAG file. The argument parsing has also been relaxed so that the order of the arguments is less significant.
  • A PROCESSOR_AFFINITY test property was added to request that CTest run a test with CPU affinity for a set of processors disjoint from other concurrently running tests with the property set.

CPack

  • The CPack module now uses variables CMAKE_PROJECT_VERSION_MAJOR, CMAKE_PROJECT_VERSION_MINOR and CMAKE_PROJECT_VERSION_PATCH to initialize corresponding CPack variables.
  • A CPack NuGet Generator was was added with basic support for NuGet.

Other

  • The Compile Features functionality is now aware of C++ 20. No specific features are yet enumerated besides the cxx_std_20 meta-feature.
  • The Compile Features functionality is now aware of the availability of C features in MSVC since VS 2010.
  • The Compile Features functionality is now aware of C language standards supported by Texas Instruments C compilers.

Deprecated and Removed Features

  • The Visual Studio 8 2005 generator has been removed.
  • CMake no longer produces <tgt>_LIB_DEPENDS cache entries for library targets. See policy CMP0073.

Other Changes

  • Include flags for directories marked as SYSTEM are now moved after non-system directories. The -isystem flag does this automatically, so moving them explicitly to the end makes the behavior consistent on compilers that do not have any -isystem flag.
  • Fortran dependency scanning now supports dependencies implied by Fortran Submodules.
  • The existence and functionality of the file ${CMAKE_BINARY_DIR}/cmake_install.cmake has now been documented in the install() documentation so that external packaging software can take advantage of CPack-style component installs.
  • The CheckIncludeFile module check_include_file macro learned to honor the CMAKE_REQUIRED_LIBRARIES variable. See policy CMP0075.
  • The CheckIncludeFileCXX module check_include_file_cxx macro learned to honor the CMAKE_REQUIRED_LIBRARIES variable. See policy CMP0075.
  • The CheckIncludeFiles module check_include_files macro learned to honor the CMAKE_REQUIRED_LIBRARIES variable. See policy CMP0075.
  • The cmake(1) -E copy_directory tool now fails when the source directory does not exist. Previously it succeeded by creating an empty destination directory.
  • The UseSWIG module swig_add_library() command (and legacy swig_add_module command) now set the prefix of Java modules to "" for MINGW, MSYS, and CYGWIN environments.

  • CMake Release Notes »


CMake 3.11 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.11 Release Notes

Contents

  • CMake 3.11 Release Notes
    • New Features
      • Platforms
      • Generators
      • Commands
      • Variables
      • Properties
      • Modules
      • Autogen
      • CTest
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes
    • Updates
      • 3.11.1
      • 3.11.2
      • 3.11.3

Changes made since CMake 3.10 include the following.

New Features

Platforms

  • TI C/C++ compilers are now supported by the Ninja generator.

Generators

  • The CodeBlocks extra generator learned to check a CMAKE_CODEBLOCKS_COMPILER_ID variable for a custom compiler identification value to place in the project file.
  • The Makefile Generators and the Ninja generator learned to add compiler launcher tools along with the compiler for the Fortran language (C, CXX, and CUDA were supported previously). See the CMAKE_<LANG>_COMPILER_LAUNCHER variable and <LANG>_COMPILER_LAUNCHER target property for details.
  • Visual Studio Generators learned to support the COMPILE_LANGUAGE generator expression in target-wide COMPILE_DEFINITIONS, INCLUDE_DIRECTORIES, COMPILE_OPTIONS, and file(GENERATE). See generator expression documentation for caveats.
  • The Xcode generator learned to support the COMPILE_LANGUAGE generator expression in target-wide COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES. It previously supported only COMPILE_OPTIONS and file(GENERATE). See generator expression documentation for caveats.

Commands

  • add_library() and add_executable() commands can now be called without any sources and will not complain as long as sources are added later via the target_sources() command.
  • The file(DOWNLOAD) and file(UPLOAD) commands gained NETRC and NETRC_FILE options to specify use of a .netrc file.
  • The target_compile_definitions() command learned to set the INTERFACE_COMPILE_DEFINITIONS property on Imported Targets.
  • The target_compile_features() command learned to set the INTERFACE_COMPILE_FEATURES property on Imported Targets.
  • The target_compile_options() command learned to set the INTERFACE_COMPILE_OPTIONS property on Imported Targets.
  • The target_include_directories() command learned to set the INTERFACE_INCLUDE_DIRECTORIES property on Imported Targets.
  • The target_sources() command learned to set the INTERFACE_SOURCES property on Imported Targets.
  • The target_link_libraries() command learned to set the INTERFACE_LINK_LIBRARIES property on Imported Targets.

Variables

  • A CMAKE_GENERATOR_INSTANCE variable was introduced to hold the selected instance of the generator’s corresponding native tools if multiple are available. This is used by the Visual Studio 15 2017 generator to hold the selected instance of Visual Studio persistently.
  • A CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS variable was added to enable setting of default permissions for directories created implicitly during installation of files by install() and file(INSTALL), e.g. during make install.
  • A CMAKE_JOB_POOLS variable was added specify a value to use for the JOB_POOLS property. This enables control over build parallelism with command line configuration parameters when using the Ninja generator.
  • The CMAKE_NETRC and CMAKE_NETRC_FILE variables were added to specify use of a .netrc file by the file(DOWNLOAD) and file(UPLOAD) commands and the ExternalProject module.
  • A CMAKE_CUDA_SEPARABLE_COMPILATION variable was added to initialize the CUDA_SEPARABLE_COMPILATION target property on targets when they are created.

Properties

  • The COMPILE_DEFINITIONS source file property learned to support generator expressions.
  • A COMPILE_OPTIONS source file property was added to manage list of options to pass to the compiler.
  • An IMPORTED_GLOBAL target property was added to indicate whether an IMPORTED target is globally visible. It is automatically set to a true value for targets created with the GLOBAL option to add_library() or add_executable(). Additionally, project code may now promote a local imported target to be globally visible by setting this property to TRUE.
  • An INCLUDE_DIRECTORIES source file property was added to specify list of preprocessor include file search directories.
  • Source file properties VS_SHADER_DISABLE_OPTIMIZATIONS and VS_SHADER_ENABLE_DEBUG have been added to specify more details of .hlsl sources with Visual Studio Generators.

Modules

  • The CheckIncludeFiles module CHECK_INCLUDE_FILES() command gained a LANGUAGE option to specify whether to check using the C or CXX compiler.
  • The CMakePackageConfigHelpers module write_basic_package_version_file() command learned a new SameMinorVersion mode for the COMPATIBILITY argument.
  • The ExternalProject module learned to substitute <DOWNLOAD_DIR> in comments, commands, working directory and byproducts.
  • The ExternalProject module gained NETRC and NETRC_FILE options to specify use of a .netrc file.
  • A new FetchContent module was added which supports populating content at configure time using any of the download/update methods supported by ExternalProject_Add(). This allows the content to be used immediately during the configure stage, such as with add_subdirectory(), etc. Hierarchical project structures are well supported, allowing parent projects to override the content details of child projects and ensuring content is not populated multiple times throughout the whole project tree.
  • The FindBLAS and FindLAPACK modules learned to support FLAME blis and libflame.
  • The FindDoxygen module doxygen_add_docs() function now supports a new DOXYGEN_VERBATIM_VARS list variable. Any DOXYGEN_... variable contained in that list will bypass the automatic quoting logic, leaving its contents untouched when transferring them to the output Doxyfile.
  • A FindIconv module was added to locate iconv support.
  • The GenerateExportHeader module GENERATE_EXPORT_HEADER command gained an INCLUDE_GUARD_NAME option to change the name of the include guard symbol written to the generated export header. Additionally, it now adds a comment after the closing #endif on the generated export header’s include guard.
  • The UseJava module add_jar command gained a GENERATE_NATIVE_HEADERS option to generate native header files using javac -h for javac 1.8 or above. This supersedes create_javah, which no longer works with JDK 1.10 and above due to removal of the javah tool by JEP 313.

Autogen

  • When using AUTOMOC or AUTOUIC, CMake now starts multiple parallel moc or uic processes to reduce the build time. A new CMAKE_AUTOGEN_PARALLEL variable and AUTOGEN_PARALLEL target property may be set to specify the number of parallel moc or uic processes to start. The default is derived from the number of CPUs on the host.

CTest

  • The ctest_start() command no longer sets CTEST_RUN_CURRENT_SCRIPT due to issues with scoping if it is called from inside a function. Instead, it sets an internal variable in CTest. However, setting CTEST_RUN_CURRENT_SCRIPT to 0 at the global scope still prevents the script from being re-run at the end.

CPack

  • cpack(1) gained --trace and --trace-expand options.
  • The CPack IFW Generator gained new CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR variable to control if the target directory should not be deleted when uninstalling.
  • The CPack RPM Generator learned to enable enforcing of execute privileges on programs and shared libraries. See CPACK_RPM_INSTALL_WITH_EXEC variable.
  • A CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS variable was added which serves the same purpose during packaging (e.g. make package) as the CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS variable serves during installation (e.g. make install).

Other

  • Alias Targets may now alias Imported Targets that are created with the GLOBAL option to add_library().
  • Interface Libraries may now have custom properties set on them if they start with either an underscore (_) or a lowercase ASCII character. The original intention was to only allow properties which made sense for INTERFACE libraries, but it also blocked usage of custom properties.
  • The cmake(1) --open <dir> command-line option was added to open generated IDE projects like Visual Studio solutions or Xcode projects.

Deprecated and Removed Features

  • An explicit deprecation diagnostic was added for policies CMP0037 through CMP0054 (CMP0036 and below were already deprecated). The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors.
  • The KDevelop3 generator has been removed.

Other Changes

  • Policy CMP0037 no longer reserves target names associated with optional features, such as test and package, unless the corresponding feature is enabled.
  • The FindOpenGL module now prefers GLVND libraries if available. See policy CMP0072.
  • The minimum deployment target set in the CMAKE_OSX_DEPLOYMENT_TARGET variable used to be only applied for macOS regardless of the selected SDK. It is now properly set for the target platform selected by CMAKE_OSX_SYSROOT. For example, if the sysroot variable specifies an iOS SDK then the value in CMAKE_OSX_DEPLOYMENT_TARGET is interpreted as minimum iOS version.
  • The Xcode generator behavior of generating one project file per project() command may now be controlled with the CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY variable. 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.
  • Since the CMakeCache.txt format does not support newlines in values, values containing newlines are now truncated before writing to the file. In addition, a warning comment is written to the cache file, and a warning message is displayed to the user on the console.

Updates

Changes made since CMake 3.11.0 include the following.

3.11.1

  • The CheckIncludeFile module check_include_file macro, CheckIncludeFileCXX module check_include_file_cxx macro, and CheckIncludeFiles module check_include_files macro were taught to honor the CMAKE_REQUIRED_LIBRARIES variable in CMake 3.11.0. This has been reverted due to changing behavior of checks for existing projects. It may be restored in the future with a policy for compatibility.

3.11.2

  • Calling add_library() to create an alias of an imported target that is not globally visible now causes an error again as it did prior to 3.11.0. This diagnostic was accidentally dropped from CMake 3.11.0 and 3.11.1 by the change to allow globally visible imported targets to be aliased.
  • The FindQt4 module qt4_wrap_cpp, qt4_wrap_ui and qt4_add_resources macros now set SKIP_AUTOMOC and SKIP_AUTOUIC on their generated files. These files never need to be processed by moc or uic, and we must say so explicitly to account for policy CMP0071.

3.11.3

  • CMake 3.11.0 introduced support for resolving symbolic links on Windows in code paths that typically do so on UNIX. This has been reverted due to breakage on subst drives.

  • CMake Release Notes »


CMake 3.10 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.10 Release Notes

Contents

  • CMake 3.10 Release Notes
    • New Features
      • Platforms
      • Generators
      • Commands
      • Variables
      • Properties
      • Modules
      • Autogen
      • CTest
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes
    • Updates
      • 3.10.1
      • 3.10.3

Changes made since CMake 3.9 include the following.

New Features

Platforms

  • The flang Fortran compiler is now supported, with compiler id Flang.
  • A new minimal platform file for Midipix was added.
  • Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain.
  • Support for the IAR ARM Compiler was improved.

Generators

  • The Makefile Generators and the Ninja generator learned to add compiler launcher tools like ccache along with the compiler for the CUDA language (C and CXX were supported previously). See the CMAKE_<LANG>_COMPILER_LAUNCHER variable and <LANG>_COMPILER_LAUNCHER target property for details.
  • The CodeBlocks extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES variable.

Commands

  • The cmake_host_system_information() command learned more keys to get information about the processor capabilities and the host OS version.
  • The configure_file() command learned to support indented #  cmakedefine and #  cmakedefine01. Spaces and/or tabs between the # character and the cmakedefine/cmakedefine01 words are now understood and preserved in the output.
  • The execute_process() command gained a RESULTS_VARIABLE option to collect a list of results from all children in a pipeline of processes when multiple COMMAND arguments are given.
  • The include_guard() command was introduced to allow guarding CMake scripts from being included more than once. The command supports DIRECTORY and GLOBAL options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check.
  • The string() command learned a new PREPEND subcommand.
  • The string(TIMESTAMP) command now supports %A for full weekday name and %B for full month name.

Variables

  • A CMAKE_DIRECTORY_LABELS variable was added to specify labels for all tests in a directory.

Properties

  • A <LANG>_CPPCHECK target property and supporting CMAKE_<LANG>_CPPCHECK variable were introduced to tell the Makefile Generators and the Ninja generator to run cppcheck with the compiler for C and CXX languages.
  • A LABELS directory property was added to specify labels for all targets and tests in a directory.
  • A TEST_INCLUDE_FILES directory property was added to list any number of files to be included when running tests with ctest(1). This generalizes the TEST_INCLUDE_FILE property.
  • The VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname> target property was added to support custom XML tags for reference assemblies in C# targets.
  • Source file properties VS_SHADER_OUTPUT_HEADER_FILE and VS_SHADER_VARIABLE_NAME have been added to specify more details of .hlsl sources with Visual Studio Generators.

Modules

  • The FindCurses module gained a CURSES_NEED_WIDE option to request the wide-character variant.
  • The FindEXPAT module now provides imported targets.
  • The FindFreetype module now provides imported targets.
  • FindMPI gained a number of new features, including:
    • Language-specific components have been added to the module.
    • Many more MPI environments are now supported.
    • The environmental support for Fortran has been improved.
    • A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler.
    • The version of the implemented MPI standard is now being exposed.
    • MPI-2 C++ bindings can now be detected and also suppressed if so desired.
    • The available Fortran bindings are now being detected and verified.
    • Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings.
    • Statically linked MPI implementations are supported.
  • A FindOpenACC module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers.
  • The FindOpenGL module gained support for GLVND on Linux.
  • The FindOpenMP module gained support for language-specific components.
  • A FindPatch module was added to find the patch command-line executable.
  • The FindProtobuf module protobuf_generate_cpp() command gained a DESCRIPTORS option to generate descriptor files.
  • The GoogleTest module gained a new command gtest_discover_tests() implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in ‘list available tests’ mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. Note that a breaking change was made in CMake 3.10.3 to address an ambiguity of the TIMEOUT keyword (see 3.10.3).
  • The InstallRequiredSystemLibraries module gained support for installing Intel compiler runtimes.

Autogen

  • When using AUTOMOC or AUTOUIC with a multi configuration generator (e.g. Xcode), included *.moc, moc_*.cpp and ui_*.h files are generated in <AUTOGEN_BUILD_DIR>/include_<CONFIG> instead of <AUTOGEN_BUILD_DIR>/include.
  • When using AUTOMOC or AUTOUIC, source files that are GENERATED will be processed as well. They were ignored by AUTOMOC and AUTOUIC in earlier releases. See policy CMP0071.
  • When using AUTOMOC, CMake searches for the strings Q_OBJECT, Q_GADGET or Q_NAMESPACE in a source file to determine if it needs to be moc processed. The new CMAKE_AUTOMOC_MACRO_NAMES variable and AUTOMOC_MACRO_NAMES target property may be set to register additional strings (macro names) to search for.
  • When using AUTOMOC, the new CMAKE_AUTOMOC_COMPILER_PREDEFINES variable and AUTOMOC_COMPILER_PREDEFINES target property specify whether to enable or disable the generation of the compiler pre definitions file moc_predefs.h.

CTest

  • A CTEST_LABELS_FOR_SUBPROJECTS CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. ctest -S) set it in the CTestConfig.cmake config file.

CPack

  • A CPack FreeBSD Generator was added for FreeBSD pkg(8).
  • The CPack DEB Generator was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross-platform Debian packages.
  • The CPack DEB Generator learned to set package release version in Version info property. See the CPACK_DEBIAN_PACKAGE_RELEASE variable.
  • The CPack DEB Generator learned more strict package version checking that complies with Debian rules.
  • The CPackIFW module cpack_ifw_configure_component() and cpack_ifw_configure_component_group() commands gained a new REPLACES and CHECKABLE options.
  • The CPack IFW Generator gained new CPACK_IFW_PACKAGE_FILE_EXTENSION variable to customize target binary format.
  • The CPack IFW Generator gained new CPACK_IFW_REPOSITORIES_DIRECTORIES variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later.
  • The CPack RPM Generator and CPack DEB Generator learned to set the package epoch version. See CPACK_RPM_PACKAGE_EPOCH and CPACK_DEBIAN_PACKAGE_EPOCH variables.

Other

  • The cmake(1) -E mode gained support for sha1sum, sha224sum, sha256sum, sha384sum, and sha512sum.
  • The graphviz output now distinguishes among the different dependency types PUBLIC, PRIVATE and INTERFACE and represents them in the output graph as solid, dashed and dotted edges.

Deprecated and Removed Features

  • Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11.
  • Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support.

Other Changes

  • On FreeBSD the C++ compiler named c++ is now the preferred default.
  • The file(GENERATE) command now interprets relative paths given to its OUTPUT and INPUT arguments with respect to the caller’s current binary and source directories, respectively. See policy CMP0070.
  • The get_filename_component() PROGRAM mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed.

Updates

Changes made since CMake 3.10.0 include the following.

3.10.1

  • The cmake-server(7) codemodel response crossReferences field added by 3.10.0 has been dropped due to excessive memory usage. Another approach will be needed to provide backtrace information.

3.10.3

  • CMake 3.10.1 added a TIMEOUT option to gtest_discover_tests() from the GoogleTest module. That keyword clashed with the TIMEOUT test property, which is one of the common properties that would be set with the command’s PROPERTIES keyword, usually leading to legal but unintended behavior. The keyword was changed to DISCOVERY_TIMEOUT in CMake 3.10.3 to address this problem. The ambiguous behavior of the gtest_discover_tests() command’s TIMEOUT keyword in 3.10.1 and 3.10.2 has not been preserved.

  • CMake Release Notes »


CMake 3.9 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.9 Release Notes

Contents

  • CMake 3.9 Release Notes
    • New Features
      • Languages
      • Generators
      • Commands
      • Variables
      • Properties
      • Modules
      • CTest
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes
    • Updates
      • 3.9.1
      • 3.9.2

Changes made since CMake 3.8 include the following.

New Features

Languages

  • CUDA is now supported by the Visual Studio Generators for VS 2010 and above. This complements the existing support by the Makefile Generators and the Ninja generator. CUDA 8.0.61 or higher is recommended due to known bugs in the VS integration by earlier versions.
  • CMake is now aware of the C++ standards and C standards and their associated meta-features for the following compiler ids: Cray, PGI, and XL.

Generators

  • Visual Studio Generators for VS 2010 and above learned to support the ASM_NASM language when nasm is installed.
  • The Xcode generator learned to create Xcode schema files. This is an experimental feature and can be activated by setting the CMAKE_XCODE_GENERATE_SCHEME variable to a TRUE value.

Commands

  • The add_library() command IMPORTED option learned to support Object Libraries.
  • The find_library() command learned to search libx32 paths when the build targets the x32 ABI. See the FIND_LIBRARY_USE_LIBX32_PATHS global property.
  • The include_external_msproject() command learned to use the MAP_IMPORTED_CONFIG_<CONFIG> target property to map current configurations to the external configurations.
  • The install(TARGETS) command learned a new OBJECTS option to specify where to install Object Libraries.
  • The install(EXPORT) command learned how to export Object Libraries.
  • The project() command learned an optional DESCRIPTION parameter to set the PROJECT_DESCRIPTION variable.
  • The separate_arguments() command gained a NATIVE_COMMAND mode that performs argument separation depending on the host operating system.

Variables

  • A CMAKE_ANDROID_NDK_DEPRECATED_HEADERS variable was added for use when Cross Compiling for Android with the NDK to request use of the deprecated headers even when unified headers are available. The default is now to use unified headers if available.
  • A CMAKE_AUTOMOC_DEPEND_FILTERS variable was introduced to allow CMAKE_AUTOMOC to extract additional dependency file names for moc from the contents of source files.
  • A CMAKE_AUTOUIC_SEARCH_PATHS variable was introduced to allow CMAKE_AUTOUIC to search for foo.ui in more places than the vicinity of the file including ui_foo.h.
  • A CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX variable was added to tell the find_library() command to search in a lib<suffix> directory before each lib directory that would normally be searched.
  • A CMAKE_INTERPROCEDURAL_OPTIMIZATION variable was added to initialize the INTERPROCEDURAL_OPTIMIZATION property on all targets.
  • A CMAKE_<LANG>_COMPILER_AR variable was added to hold the path to the GCC/Clang wrapper of ar.
  • A CMAKE_<LANG>_COMPILER_RANLIB variable was added to hold the path to the GCC/Clang wrapper of ranlib.
  • The CMAKE_SYSROOT_COMPILE and CMAKE_SYSROOT_LINK variables were added to use separate sysroots for compiling and linking.

Properties

  • A new AUTOGEN_BUILD_DIR target property was introduced to set a custom output directory for AUTOMOC, AUTOUIC, and AUTORCC.
  • A new AUTOMOC_DEPEND_FILTERS target property was introduced to allow AUTOMOC to extract additional dependency file names for moc from the contents of source files.
  • A new AUTOUIC_SEARCH_PATHS target property was introduced to allow AUTOUIC to search for foo.ui in more places than the vicinity of the file including ui_foo.h.
  • Global properties AUTOGEN_SOURCE_GROUP, AUTOMOC_SOURCE_GROUP and AUTORCC_SOURCE_GROUP were introduced to allow files generated by AUTOMOC or AUTORCC to be placed in a source_group().
  • A BUILD_WITH_INSTALL_NAME_DIR target property and corresponding CMAKE_BUILD_WITH_INSTALL_NAME_DIR variable were added to control whether to use the INSTALL_NAME_DIR target property value for binaries in the build tree. This is for macOS install_name as BUILD_WITH_INSTALL_RPATH is for RPATH.
  • A CUDA_PTX_COMPILATION target property was added to Object Libraries to support compiling to .ptx files instead of host object files.
  • A GENERATOR_IS_MULTI_CONFIG global property was added to determine whether the current generator is a multi-configuration generator (such as Visual Studio Generators or Xcode).
  • The INTERPROCEDURAL_OPTIMIZATION target property is now enforced when enabled. CMake will add IPO flags unconditionally or produce an error if it does not know the flags for the current compiler. The project is now responsible to use the CheckIPOSupported module to check for IPO support before enabling the target property. See policy CMP0069.
  • The WINDOWS_EXPORT_ALL_SYMBOLS target property may now be used in combination with explicit .def files in order to export all symbols from the object files within a target plus an explicit list of symbols that the linker finds in dependencies (e.g. msvcrt.lib).

Modules

  • A CheckIPOSupported module was added to help projects check whether interprocedural optimization (IPO) is supported by the current toolchain and CMake version.
  • The CMakeFindDependencyMacro module find_dependency macro now forwards all arguments to the underlying find_package() call. Existing uses will continue to function as before, but callers can now access the full suite of arguments that find_package accepts.
  • The FeatureSummary module feature_summary() command now accepts the new DEFAULT_DESCRIPTION option that will print the default title for the selected package type.
  • The FeatureSummary module gained a new FeatureSummary_<TYPE>_DESCRIPTION variable that can be defined for each <TYPE> to replace the type name with the specified string whenever the package type is used in an output string by the module.
  • The FindDoxygen module learned to control Doxygen behavior using CMake variables and generate documentation via the newly added doxygen_add_docs() function. The Doxygen input file (Doxyfile) is automatically generated and doxygen is run as part of a custom target. Additional components can be specified to find optional tools: dot, mscgen and dia.
  • The FindMPI module now provides imported targets.
  • The FindProtobuf module protobuf_generate_cpp() command gained an EXPORT_MACRO option to specify the name of a DLL export markup macro.
  • The FindProtobuf module now supports usage of static libraries for Unix via a new Protobuf_USE_STATIC_LIBS input variable.
  • The FindProtobuf module now provides imported targets when the libraries are found.
  • A new GoogleTest module was added to provide the gtest_add_tests() function independently of the FindGTest module. The function was also updated to support keyword arguments, with functionality expanded to allow a test name prefix and suffix to be specified, the dependency on the source files to be optional and the list of discovered test cases to be returned to the caller.

CTest

  • The ctest_submit() command gained a HTTPHEADER option to specify custom headers to send during submission.
  • The ctest(1) executable gained new options which allow the developer to disable automatically adding tests to the test set to satisfy fixture dependencies. -FS prevents adding setup tests for fixtures matching the provided regular expression, -FC prevents adding cleanup tests for matching fixtures and -FA prevents adding any test for matching fixtures.
  • A DISABLED test property was added to mark tests that are configured but explicitly disabled so they do not run.

CPack

  • The CPack Archive Generator learned to modify the filename per-component. See the CPACK_ARCHIVE_FILE_NAME variable and its per-component version CPACK_ARCHIVE_<component>_FILE_NAME.
  • The CPackComponent module cpack_add_component() command gained a new PLIST <filename> option to specify the pkgbuild --component-plist argument when using the productbuild generator.
  • The CPackIFW module cpack_ifw_configure_component() and cpack_ifw_configure_component_group() commands gained internationalization support for DISPLAY_NAME and DESCRIPTION options.
  • The CPack IFW Generator learned the new hint CPACK_IFW_ROOT variable for finding the QtIFW tool suite installed in a non-standard place.
  • The CPack productbuild Generator gained a new CPACK_PRODUCTBUILD_RESOURCES_DIR variable to specify resources to be copied into the Resources directory.
  • The CPack RPM Generator learned to modify the debuginfo package name. See the CPACK_RPM_DEBUGINFO_FILE_NAME variable.
  • The CPack WIX Generator patching system now has the ability to set additional attributes. This can be done by specifying attributes with the CPackWiXFragment XML tag after the Id attribute. See the CPACK_WIX_PATCH_FILE variable.
  • The CPack WIX Generator implemented a new CPACK_WIX_ROOT_FOLDER_ID variable which allows using a custom root folder ID instead of the default ProgramFilesFolder / ProgramFiles64Folder.

Other

  • Interprocedural optimization (IPO) is now supported for GNU and Clang compilers using link time optimization (LTO) flags. See the INTERPROCEDURAL_OPTIMIZATION target property and CheckIPOSupported module.
  • The TARGET_OBJECTS generator expression is now supported by the add_custom_command() and file(GENERATE) commands.
  • Two new informational generator expressions to retrieve Apple Bundle directories have been added. The first one $<TARGET_BUNDLE_DIR:tgt> outputs the full path to the Bundle directory, the other one $<TARGET_BUNDLE_CONTENT_DIR:tgt> outputs the full path to the Contents directory of macOS Bundles and App Bundles. For all other bundle types and SDKs it is identical with $<TARGET_BUNDLE_DIR:tgt>. The new expressions are helpful to query Bundle locations independent of the different Bundle types and layouts on macOS and iOS.

Deprecated and Removed Features

  • An explicit deprecation diagnostic was added for policies CMP0036 and below. The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that projects should always port to the NEW behaviors as soon as possible.
  • The Visual Studio 8 2005 generator is now deprecated and will be removed in a future version of CMake.
  • The Visual Studio 7 .NET 2003 generator has been removed.
  • The Xcode generator dropped support for Xcode versions older than 3.
  • The FindDoxygen module has deprecated several variables.
  • The version of curl bundled with CMake no longer accepts URLs of the form file://c:/... on Windows due to a change in upstream curl 7.52. Use the form file:///c:/... instead to work on all versions.

Other Changes

  • When using AUTOMOC, CMake now scans for the presence of the Q_PLUGIN_METADATA macro and reruns moc when the file from the macro’s FILE argument changes.
  • When AUTOMOC detects an include statement of the form #include "moc_<basename>.cpp" the search for the respective header file now looks in the INCLUDE_DIRECTORIES of the target as well.
  • When running tests, CTest learned to treat skipped tests (using the SKIP_RETURN_CODE property) the same as tests with the new DISABLED property. Due to this change, CTest will not indicate failure when all tests are either skipped or pass.
  • The Ninja generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object’s target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets’ dependencies to link.
  • On macOS, RPATH settings such as BUILD_WITH_INSTALL_RPATH no longer affect the install_name field. See policy CMP0068.
  • The Visual Studio 14 2015 generator has been taught about a change to the v140 toolset made by a VS 2015 update. VS changed the set of values it understands for the GenerateDebugInformation linker setting that produces the -DEBUG linker flag variants.

Updates

Changes made since CMake 3.9.0 include the following.

3.9.1

  • The find_ command PACKAGE_ROOT search path group added by CMake 3.9.0 has been removed for the 3.9 series due to regressions caused by new use of <PackageName>_ROOT variables. The behavior may be re-introduced in the future in a more-compatible way.

3.9.2

  • On macOS, the default application bundle Info.plist file no longer enables Hi-DPI support as it did in 3.9.0 and 3.9.1. The change had to be reverted because it broke iOS applications.
  • The Xcode generator no longer adds “outputPaths” to custom script build phases as it did in 3.9.0 and 3.9.1. This was added in an attempt to support Xcode 9’s new build system, but broke incremental rebuilds for both the old and new Xcode build systems.

  • CMake Release Notes »


CMake 3.8 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.8 Release Notes

Contents

  • CMake 3.8 Release Notes
    • New Features
      • Languages
        • C#
        • CUDA
        • C & C++
      • Platforms
      • Generators
      • Commands
      • Variables
      • Properties
      • Modules
      • CTest
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.7 include the following.

New Features

Languages

C#

  • CMake learned to support CSharp (C#) as a first-class language that can be enabled via the project() and enable_language() commands. It is currently supported by the Visual Studio Generators for VS 2010 and above.

    C# assemblies and programs can be added just like common C++ targets using the add_library() and add_executable() commands. References between C# targets in the same source tree may be specified by target_link_libraries() like for C++. References to system or 3rd-party assemblies may be specified by the target properties VS_DOTNET_REFERENCE_<refname> and VS_DOTNET_REFERENCES.

  • More fine tuning of C# targets may be done using target and source file properties. Specifically the target properties related to Visual Studio (VS_*) are worth a look (for setting toolset versions, root namespaces, assembly icons, …).

CUDA

  • CMake learned to support CUDA as a first-class language that can be enabled via the project() and enable_language() commands.
  • CUDA is currently supported by the Makefile Generators and the Ninja generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release.
  • The NVIDIA CUDA Toolkit compiler (nvcc) is supported.

C & C++

  • The Compile Features functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. cxx_std_11). See CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES.
  • The Compile Features functionality is now aware of C++ 17. No specific features are yet enumerated besides the cxx_std_17 meta-feature.
  • The Compile Features functionality is now aware of the availability of C99 in gcc since version 3.4.

Platforms

  • A new minimal platform file for Fuchsia was added.

Generators

  • The CodeBlocks extra generator may now be used to generate with NMake Makefiles JOM.
  • The Visual Studio Generators for VS 2013 and above learned to support a host=x64 option in the CMAKE_GENERATOR_TOOLSET value (e.g. via the cmake(1) -T option) to request use of a VS 64-bit toolchain on 64-bit hosts.
  • The Visual Studio Generators learned to treat files passed to target_link_libraries() whose names end in .targets as MSBuild “targets” files to be imported into generated project files.

Commands

  • The add_custom_command() and add_custom_target() commands learned the option COMMAND_EXPAND_LISTS which causes lists in the COMMAND argument to be expanded, including lists created by generator expressions.
  • The execute_process() command gained an ENCODING option to specify on Windows which encoding is used for output from child process.
  • The math(EXPR) command gained support for unary + and - operators.
  • The source_group() command gained TREE and PREFIX options to add groups following source tree directory structure.
  • The string(TIMESTAMP) command learned to treat %% as a way to encode plain %.
  • The string(TIMESTAMP) command will now honor the SOURCE_DATE_EPOCH environment variable and use its value instead of the current time.
  • The try_compile() command source file signature gained new options to specify the language standard to use in the generated test project.
  • The try_compile() command source file signature now honors language standard variables like CMAKE_CXX_STANDARD. See policy CMP0067.

Variables

  • A CMAKE_CODELITE_USE_TARGETS variable was added to tell the CodeLite extra generator to change the generated project to have target-centric organization. The build, rebuild, and clean operations within CodeLite then work on a selected target rather than the whole workspace. (Note that the Ninja clean operation on a target includes its dependencies, though.)
  • The CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS variable was added to tell the Sublime Text 2 extra generator to place specified environment variables in the generated .sublime-project.
  • The CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE variable was added to tell the Sublime Text 2 extra generator whether to exclude the build tree from the .sublime-project when it is inside the source tree.
  • A CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD variable was added to tell Visual Studio Generators for VS 2010 and above to include the PACKAGE target in the default build, similar to the existing CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD variable for the INSTALL target.

Properties

  • A BUILD_RPATH target property and corresponding CMAKE_BUILD_RPATH variable were added to support custom RPATH locations to be added to binaries in the build tree.
  • The COMPILE_FLAGS source file property learned to support generator expressions.
  • The FRAMEWORK target property may now also be applied to static libraries on Apple targets. It will result in a proper Framework but with a static library inside.
  • Imported Interface Libraries learned new IMPORTED_LIBNAME and IMPORTED_LIBNAME_<CONFIG> target properties to specify a link library name since interface libraries do not build their own library files.
  • A <LANG>_CPPLINT target property and supporting CMAKE_<LANG>_CPPLINT variable were introduced to tell the Makefile Generators and the Ninja generator to run the cpplint style checker along with the compiler for C and CXX languages.
  • A MANUALLY_ADDED_DEPENDENCIES target property has been added. It provides a read-only list of dependencies that have been added with the add_dependencies() command.
  • The MAP_IMPORTED_CONFIG_<CONFIG> target property learned to interpret empty list elements as referring to the configuration-less imported location specified by IMPORTED_LOCATION.
  • The NO_SYSTEM_FROM_IMPORTED target property is now supported on Imported Interface Libraries.
  • New source file properties SKIP_AUTOMOC, SKIP_AUTOUIC, SKIP_AUTORCC, and SKIP_AUTOGEN were added to allow source files to be excluded from processing by AUTOMOC, AUTOUIC, and AUTORCC target properties.
  • A VS_COPY_TO_OUT_DIR source file property was added to tell Visual Studio Generators for VS 2010 and above whether or not a file should e copied to the output directory.
  • A VS_DEBUGGER_WORKING_DIRECTORY target property was added to tell Visual Studio Generators for VS 2010 and above what debugger working directory should be set for the target.
  • A VS_DOTNET_REFERENCES_COPY_LOCAL target property was added to specify whether to copy referenced assemblies to the output directory.
  • A VS_DOTNET_REFERENCE_<refname> target property was added to tell Visual Studio Generators for VS 2010 and above to add a .NET reference with a given hint path.
  • A VS_INCLUDE_IN_VSIX source file property was added to tell Visual Studio Generators for VS 2010 and above whether to include the file in a Visual Studio extension package.
  • A VS_RESOURCE_GENERATOR source file property was added to give Visual Studio Generators for VS 2010 and above a setting for the resource generator (C# only).
  • A VS_USER_PROPS target property was added to tell Visual Studio Generators for VS 2010 and above to use a custom MSBuild user .props file.
  • A XCODE_EMIT_EFFECTIVE_PLATFORM_NAME global property was added to tell the Xcode generator whether to emit the EFFECTIVE_PLATFORM_NAME variable. This is useful when building with multiple SDKs like macosx and iphoneos in parallel.
  • New XCODE_PRODUCT_TYPE and XCODE_EXPLICIT_FILE_TYPE target properties were created to tell the Xcode generator to use custom values of the corresponding attributes for a target in the generated Xcode project.

Modules

  • A CSharpUtilities module was added to aid parameterization of Visual Studio C# targets. It provides functions to allow automated setting of source file properties to support Windows Forms, WPF/XAML or other technologies as needed.
  • The ExternalData module learned to support multiple content links for one data file using different hashes, e.g. img.png.sha256 and img.png.sha1. This allows objects to be fetched from sources indexed by different hash algorithms.
  • The ExternalProject module gained the GIT_PROGRESS option to force Git to show progress when cloning repositories.
  • The ExternalProject module gained a GIT_CONFIG option to pass --config options to Git when cloning repositories.
  • The FeatureSummary module feature_summary() command now accepts a new QUIET_ON_EMPTY option that suppresses the output when the list of packages that belong to the selected category is empty.
  • The FeatureSummary module add_feature_info() command now accepts lists of dependencies for deciding whether a feature is enabled or not.
  • The package types accepted by the FeatureSummary module can now be tweaked by changing the FeatureSummary_PKG_TYPES, FeatureSummary_REQUIRED_PKG_TYPES and FeatureSummary_DEFAULT_PKG_TYPE global properties.
  • The FindOpenGL module now provides imported targets OpenGL::GL and OpenGL::GLU when the libraries are found.
  • The UseSWIG module gained a swig_add_library command to give more flexibility over the old swig_add_module command.
  • The UseSWIG module swig_add_source_to_module command learned a new SWIG_OUTFILE_DIR option to control the output file location (swig -o).
  • The WriteCompilerDetectionHeader module gained the ALLOW_UNKNOWN_COMPILERS and ALLOW_UNKNOWN_COMPILER_VERSIONS options that allow creation of headers that will work also with unknown or old compilers by simply assuming they do not support any of the requested features.

CTest

  • The ctest_memcheck() command gained a DEFECT_COUNT <var> option to capture the number of memory defects detected.
  • The ctest_memcheck() command learned to read the location of suppressions files for sanitizers from the CTEST_MEMORYCHECK_SUPPRESSIONS_FILE variable.
  • The ctest_memcheck() command learned to support LeakSanitizer independently from AddressSanitizer.
  • The ctest_update() command CDASH_UPLOAD signature was taught to honor the RETRY_COUNT, RETRY_DELAY, and QUIET options.

CPack

  • The CPackIFWConfigureFile module was added to define a new cpack_ifw_configure_file() command to configure file templates prepared in QtIFW/SDK/Creator style.
  • The CPackIFW module cpack_ifw_configure_component() and cpack_ifw_configure_component_group() commands gained a new DEFAULT, VIRTUAL, FORCED_INSTALLATION, REQUIRES_ADMIN_RIGHTS, DISPLAY_NAME, UPDATE_TEXT, DESCRIPTION, RELEASE_DATE, AUTO_DEPEND_ON and TRANSLATIONS options to more specific configuration.
  • The CPackIFW module cpack_ifw_configure_component() command gained a new DEPENDENCIES alias for DEPENDS option.
  • The CPackIFW module cpack_ifw_configure_component_group() command gained a new DEPENDS option. The DEPENDENCIES alias also added.
  • The CPackIFW module cpack_ifw_configure_component() and cpack_ifw_configure_component_group() commands PRIORITY option now is deprecated and will be removed in a future version of CMake. Please use new SORTING_PRIORITY option instead.
  • The CPack IFW Generator gained new CPACK_IFW_PACKAGE_WATERMARK, CPACK_IFW_PACKAGE_BANNER, CPACK_IFW_PACKAGE_BACKGROUND, CPACK_IFW_PACKAGE_WIZARD_STYLE, CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH, CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT, and CPACK_IFW_PACKAGE_TITLE_COLOR variables to customize a QtIFW installer look.
  • The CPack productbuild Generator gained options to sign packages. See the variables CPACK_PRODUCTBUILD_IDENTITY_NAME, CPACK_PRODUCTBUILD_KEYCHAIN_PATH, CPACK_PKGBUILD_IDENTITY_NAME, and CPACK_PKGBUILD_KEYCHAIN_PATH.
  • The CPack RPM Generator learned to omit tags that are not supported by provided rpmbuild tool. If unsupported tags are set they are ignored and a developer warning is printed out.
  • The CPack RPM Generator learned to generate main component package which forces generation of a rpm for defined component without component suffix in filename and package name. See CPACK_RPM_MAIN_COMPONENT variable.
  • The CPack RPM Generator learned to generate a single debuginfo package on demand even if components packaging is used. See CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE variable.
  • The CPack RPM Generator learned to support multiple directives per file when using CPACK_RPM_USER_FILELIST variable.

Other

  • CMake functionality using cryptographic hashes now supports SHA-3 algorithms.
  • A new generator expression $<IF:cond,true-value,false-value> was added. It resolves to the true-value if the condition is 1 and resolves to the false-value if the condition is 0.

Deprecated and Removed Features

  • The  FeatureSummary module commands  set_package_info(),
 set_feature_info(),  print_enabled_features(), and
 print_disabled_features() are now deprecated.
  • The UseSWIG module swig_add_module command is now deprecated in favor of swig_add_library.

Other Changes

  • If a command specified by the <LANG>_CLANG_TIDY target property returns non-zero at build time this is now treated as an error instead of silently ignored.
  • The ctest_memcheck() command no longer automatically adds leak_check=1 to the options used by AddressSanitizer. The default behavior of AddressSanitizer is to run LeakSanitizer to check leaks unless leak_check=0.
  • The ctest_memcheck() command was fixed to correctly append extra sanitizer options read from the CTEST_MEMORYCHECK_SANITIZER_OPTIONS variable to the environment variables used internally by the sanitizers.
  • The FeatureSummary module set_package_properties() command no longer forces the package type to OPTIONAL when the type is not explicitly set.
  • The Compile Features functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms.
  • Calls to the FindPkgConfig module pkg_check_modules() command following a successful call learned to re-evaluate the cached values for a given prefix after changes to the parameters to the command for that prefix.
  • When using AUTOMOC or AUTOUIC, generated moc_*, *.moc and ui_* are placed in the <CMAKE_CURRENT_BINARY_DIR>/<TARGETNAME>_autogen/include directory which is automatically added to the target’s INCLUDE_DIRECTORIES. It is therefore not necessary anymore to have CMAKE_CURRENT_BINARY_DIR in the target’s INCLUDE_DIRECTORIES.
  • The Sublime Text 2 generator no longer runs the native build command (e.g. ninja or make) with verbose build output enabled.
  • The try_compile() command source file signature now honors the CMAKE_WARN_DEPRECATED variable value in the generated test project.
  • The Visual Studio Generators for VS 2010 and above now place per-source file flags after target-wide flags when they are classified as raw flags with no project file setting (AdditionalOptions). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target).
  • The precompiled Windows binary MSI package provided on cmake.org now records the installation directory in the Windows Registry under the key HKLM\Software\Kitware\CMake with a value named InstallDir.

  • CMake Release Notes »


CMake 3.7 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.7 Release Notes

Contents

  • CMake 3.7 Release Notes
    • New Features
      • Platforms
      • Generators
      • Commands
      • Variables
      • Properties
      • Modules
      • CTest
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.6 include the following.

New Features

Platforms

  • CMake now supports Cross Compiling for Android with simple toolchain files.
  • The Clang compiler is now supported on AIX.

Generators

  • The Ninja generator learned to conditionally support Fortran when using a ninja tool that has the necessary features. See generator documentation for details.
  • The Ninja generator learned to produce phony targets of the form sub/dir/{test,install,package} to drive the build of a subdirectory installation, test or packaging target. This is equivalent to cd sub/dir; make {test,install,package} with Makefile Generators.
  • The Visual Studio 15 2017 generator was added. This is experimental and based on “Visual Studio 2017 RC” because this version of VS has not been released.
  • Visual Studio Generators for VS 2010 and above learned to place .natvis source files into VS project files properly.
  • The Xcode generator’s rudimentary Swift language support learned to honor a new CMAKE_Swift_LANGUAGE_VERSION variable to tell Xcode what version of Swift is used by the source.
  • The CodeLite generator gained a new CMAKE_CODELITE_USE_TARGETS option to change project creation from projects to targets.

Commands

  • The add_custom_command() command gained a new DEPFILE option that works with the Ninja generator to provide implicit dependency information to the build tool.
  • The cmake_parse_arguments() command gained a new PARSE_ARGV mode to read arguments directly from ARGC and ARGV# variables inside a function() body.
  • The export() command gained an ANDROID_MK option to generate Android.mk files referencing CMake-built libraries as prebuilts for the Android NDK build system.
  • The file(DOWNLOAD) and file(UPLOAD) commands gained HTTPHEADER <HTTP-header> and USERPWD <username>:<password> options.
  • The find_library() and find_package() commands learned to search in lib32/ directories when the build targets a 32-bit architecture. See the FIND_LIBRARY_USE_LIB32_PATHS global property.
  • The find_package() command gained the possibility of sorting compatible libraries by NAME or by NATURAL sorting by setting the two new variables CMAKE_FIND_PACKAGE_SORT_ORDER and CMAKE_FIND_PACKAGE_SORT_DIRECTION.
  • The if() command gained new boolean comparison operations LESS_EQUAL, GREATER_EQUAL, STRLESS_EQUAL, STRGREATER_EQUAL, VERSION_LESS_EQUAL, and VERSION_GREATER_EQUAL.
  • The install() command gained an EXPORT_ANDROID_MK subcommand to install Android.mk files referencing installed libraries as prebuilts for the Android NDK build system.
  • The string(TIMESTAMP) and file(TIMESTAMP) commands gained support for the %a and %b placeholders. These are the abbreviated weekday and month names.
  • The try_compile() command source file signature now honors configuration-specific flags (e.g. CMAKE_<LANG>_FLAGS_DEBUG) in the generated test project. Previously only the default such flags for the current toolchain were used. See policy CMP0066.

Variables

  • Variable CMAKE_FIND_PACKAGE_SORT_ORDER was added to control the sorting mode of the find_package() command.
  • Variable CMAKE_FIND_PACKAGE_SORT_DIRECTION was added to control the sorting direction the find_package() command.
  • Toolchain files may now set a CMAKE_<LANG>_FLAGS_INIT variable to initialize the CMAKE_<LANG>_FLAGS cache entry the first time a language is enabled in a build tree.
  • Toolchain files may now set CMAKE_EXE_LINKER_FLAGS_INIT, CMAKE_SHARED_LINKER_FLAGS_INIT, and CMAKE_MODULE_LINKER_FLAGS_INIT variables to initialize the CMAKE_EXE_LINKER_FLAGS, CMAKE_SHARED_LINKER_FLAGS, and CMAKE_MODULE_LINKER_FLAGS cache entries the first time a language is enabled in a build tree.

Properties

  • On Apple platforms the BUNDLE_EXTENSION target property now also applies to Frameworks and App Bundles.
  • A BINARY_DIR directory property was added to get the absolute path to the binary directory corresponding to the source directory on which the property is read.
  • A BUILDSYSTEM_TARGETS directory property was added to get the list of logical buildsystem target names added by the project in a directory.
  • A LINK_WHAT_YOU_USE target property and supporting CMAKE_LINK_WHAT_YOU_USE variable were introduced to detect (on UNIX) shared libraries that are linked but not needed by running ldd -r -u.
  • A SOURCE_DIR directory property was added to get the absolute path to the source directory associated with a directory.
  • A SUBDIRECTORIES directory property was added to get the list of subdirectories added by a project in a directory.
  • A VS_SDK_REFERENCES target property was added to tell Visual Studio Generators to reference the named SDKs.
  • A VS_TOOL_OVERRIDE source file property was created to tell Visual Studio Generators what tool to use for a source file.
  • The WINDOWS_EXPORT_ALL_SYMBOLS target property now applies to executable targets with the ENABLE_EXPORTS property set.
  • A XCODE_FILE_ATTRIBUTES source file property was added to tell the Xcode generator to generate custom content in the Xcode project attributes for the file.

Modules

  • An AndroidTestUtilities module was added to manage transfer of test data to an Android device.
  • The CheckFortranSourceCompiles module macro CHECK_Fortran_SOURCE_COMPILES gained a SRC_EXT option to specify a custom test Fortran source file extension.
  • The ExternalProject module gained HTTP_USERNAME and HTTP_PASSWORD options to set http download credentials.
  • The ExternalProject module gained a HTTP_HEADER option to add http download headers.
  • The FindBISON module BISON_TARGET macro learned a new REPORT_FILE option to specify the bison --report-file= option.
  • The FindBZip2 module now provides imported targets.
  • A FindICU module was introduced to find the International Components for Unicode (ICU) libraries and programs.
  • The FindMatlab module learned to find the SIMULINK and MAT components.
  • The FindMatlab module matlab_add_mex() command learned to add executables and modules.
  • The FindMatlab module matlab_add_unit_test() command learned to support inline Matlab test code.
  • The FindOpenCL module now provides imported targets.
  • The FindOpenMP module learned to detect the OpenMP version (specification date) from the compiler.
  • A FindVulkan module was added.
  • The GenerateExportHeader module learned a new CUSTOM_CONTENT_FROM_VARIABLE option to specify a variable containing custom content for inclusion in the generated header.
  • The GNUInstallDirs module gained a new GNUInstallDirs_get_absolute_install_dir() command.
  • The UseJava module gained APIs to “export” jar targets for use by external CMake projects. See the install_jar_exports and export_jars functions.

CTest

  • CTest now supports test fixtures through the new FIXTURES_SETUP, FIXTURES_CLEANUP and FIXTURES_REQUIRED test properties. When using regular expressions or --rerun-failed to limit the tests to be run, a fixture’s setup and cleanup tests will automatically be added to the execution set if any test requires that fixture.
  • The ctest_configure(), ctest_build(), ctest_test(), ctest_coverage(), and ctest_upload() commands gained a new CAPTURE_CMAKE_ERROR option to capture any errors that occur as the commands run into a variable and avoid affecting the return code of the ctest(1) process.

CPack

  • CPack gained a CPack productbuild Generator on OS X.
  • CPack gained a new CPACK_PACKAGE_CHECKSUM variable to enable generation of a checksum file for each package file.
  • The CPack DEB Generator learned to support long file names when archive format is set to GNU tar. See CPACK_DEBIAN_ARCHIVE_TYPE
  • The CPackIFW module gained a new cpack_ifw_add_package_resources() command to include additional resources in the installer binary.
  • The CPackIFW module cpack_ifw_configure_component() and cpack_ifw_configure_component_group() commands gained a new USER_INTERFACES option to add a list of additional pages to the IFW installer.
  • The CPack RPM Generator learned to generate debuginfo packages on demand. See CPACK_RPM_DEBUGINFO_PACKAGE and its per component version.
  • The CPack RPM Generator learned to generate source rpm (SRPM) packages on demand. See CPACK_RPM_PACKAGE_SOURCES, CPACK_RPM_SOURCE_PKG_BUILD_PARAMS and CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX.
  • The CPack NSIS Generator now supports CPACK_NSIS_<compName>_INSTALL_DIRECTORY. This can be used to set component specific installation directories.
  • The CPack WIX Generator now supports CPACK_WIX_SKIP_PROGRAM_FOLDER to allow specification of a custom absolute installation prefix outside of the ProgramFiles folders.
  • The CPack WIX Generator now supports CPACK_COMPONENT_<compName>_DISABLED. This can be used to deselect a component from being installed by default.
  • The CPack WIX Generator now supports CPACK_WIX_PATCH_FILE fragments for Feature elements.
  • The CPack WIX Generator now supports CPACK_WIX_ROOT_FEATURE_TITLE and CPACK_WIX_ROOT_FEATURE_DESCRIPTION to allow the specification of a custom title and description for the root feature element.

Other

  • cmake(1) gained a -E capabilities option to provide a machine-readable (JSON) description of the capabilities of the cmake tool (available generators, etc.).
  • A new cmake-server(7) mode was added to provide semantic information about a CMake-generated buildsystem to clients through a JSON protocol. Currently all protocols are experimental and subject to change.
  • The cmake(1) command learned a --trace-source=<file> option.
  • ccmake(1) learned to support vim-like navigation bindings.
  • cmake-gui(1) gained a button to open the generated project file for Visual Studio Generators and the Xcode generator.

Deprecated and Removed Features

  • We no longer provide Linux i386 binaries for download from cmake.org for new versions of CMake.

  • Vim support files cmake-indent.vim, cmake-syntax.vim, and cmake-help.vim have been removed in favor of the files now provided from the vim-cmake-syntax project.

  • Support for building CMake itself with some compilers was dropped:

    • Visual Studio 7.1 and 2005 – superseded by VS 2008 and above
    • MinGW.org mingw32 – superseded by MSYS2 mingw32 and mingw64

    CMake still supports generating build systems for other projects using these compilers.

Other Changes

  • The Fortran dependency scanner learned to support the syntax of Fortran Submodules.
  • Vim support files indent/cmake.vim and syntax/cmake.vim from the vim-cmake-syntax project are now distributed with CMake.

  • CMake Release Notes »


CMake 3.6 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.6 Release Notes

Contents

  • CMake 3.6 Release Notes
    • New Features
      • Generators
      • Commands
      • Variables
      • Properties
      • Modules
      • Platforms
      • CTest
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.5 include the following.

New Features

Generators

  • The Ninja generator learned to produce phony targets of the form sub/dir/all to drive the build of a subdirectory. This is equivalent to cd sub/dir; make all with Makefile Generators.
  • The Ninja generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated.
  • The Visual Studio 14 2015 generator learned to support the Clang/C2 toolsets, e.g. with the -T v140_clang_3_7 option. This feature is experimental.

Commands

  • The add_custom_command() and add_custom_target() commands learned how to use the CROSSCOMPILING_EMULATOR executable target property.
  • The install() command learned a new EXCLUDE_FROM_ALL option to leave installation rules out of the default installation.
  • The list() command gained a FILTER sub-command to filter list elements by regular expression.
  • The string(TIMESTAMP) and file(TIMESTAMP) commands gained support for the %s placeholder. This is the number of seconds since the UNIX Epoch.

Variables

  • A CMAKE_DEPENDS_IN_PROJECT_ONLY variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees.
  • A new CMAKE_HOST_SOLARIS variable was introduced to indicate when CMake is running on an Oracle Solaris host.
  • A CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines.
  • The CMAKE_<LANG>_STANDARD_LIBRARIES variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines.
  • A CMAKE_NINJA_OUTPUT_PATH_PREFIX variable was introduced to tell the Ninja generator to configure the generated build.ninja file for use as a subninja.
  • A CMAKE_TRY_COMPILE_PLATFORM_VARIABLES variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the try_compile() command into test projects.
  • A CMAKE_TRY_COMPILE_TARGET_TYPE variable was added to optionally tell the try_compile() command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts.

Properties

  • A DEPLOYMENT_REMOTE_DIRECTORY target property was introduced to tell the Visual Studio 9 2008 and Visual Studio 8 2005 generators to generate the “remote directory” for WinCE project deployment and debugger settings.
  • A <LANG>_CLANG_TIDY target property and supporting CMAKE_<LANG>_CLANG_TIDY variable were introduced to tell the Makefile Generators and the Ninja generator to run clang-tidy along with the compiler for C and CXX languages.
  • A TIMEOUT_AFTER_MATCH test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test.
  • A VS_CONFIGURATION_TYPE target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above.
  • A VS_STARTUP_PROJECT directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (.sln files).

Modules

  • The CMakePushCheckState module now pushes/pops/resets the variable CMAKE_EXTRA_INCLUDE_FILE used in CheckTypeSize.
  • The ExternalProject module leared the GIT_SHALLOW 1 option to perform a shallow clone of a Git repository.
  • The ExternalProject module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the GIT_SUBMODULES option to restrict which submodules are initialized and updated.
  • The ExternalProject module leared the DOWNLOAD_NO_EXTRACT 1 argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or .msi files).
  • The ExternalProject module now uses TLS_VERIFY when fetching from git repositories.
  • The FindBLAS and FindLAPACK modules learned to support OpenBLAS.
  • The FindCUDA module learned to find the cublas_device library.
  • The FindGTest module gtest_add_tests function now causes CMake to automatically re-run when test sources change so that they can be re-scanned.
  • The FindLTTngUST module was introduced to find the LTTng-UST library.
  • The FindPkgConfig module learned to optionally create imported targets for the libraries it has found.
  • The FindProtobuf module learned to provide a Protobuf_VERSION variable and check the version number requested in a find_package() call.
  • The InstallRequiredSystemLibraries module learned a new CMAKE_INSTALL_UCRT_LIBRARIES option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015.

Platforms

  • The Clang compiler is now supported on CYGWIN.
  • Support was added for the Bruce C Compiler with compiler id Bruce.

CTest

  • The ctest_update() command now looks at the CTEST_GIT_INIT_SUBMODULES variable to determine whether submodules should be updated or not before updating.
  • The ctest_update() command will now synchronize submodules on an update. Updates which add submodules or change a submodule’s URL will now be pulled properly.

CPack

  • The CPack DEB Generator learned how to handle $ORIGIN in CMAKE_INSTALL_RPATH when CPACK_DEBIAN_PACKAGE_SHLIBDEPS is used for dependency auto detection.

  • The CPack DEB Generator learned how to generate DEBIAN/shlibs contorl file when package contains shared libraries.

  • The CPack DEB Generator learned how to generate DEBIAN/postinst and DEBIAN/postrm files if the package installs libraries in ldconfig-controlled locations (e.g. /lib/, /usr/lib/).

  • The CPack DEB Generator learned how to generate dependencies between Debian packages if multi-component setup is used and CPACK_COMPONENT_<compName>_DEPENDS variables are set. For backward compatibility this feature is disabled by default. See CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS.

  • The CPack DEB Generator learned how to set custom package file names including how to generate properly-named Debian packages:

    <PackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb

    For backward compatibility this feature is disabled by default. See CPACK_DEBIAN_FILE_NAME and CPACK_DEBIAN_<COMPONENT>_FILE_NAME.

  • The CPack DEB Generator learned how to set the package release number (DebianRevisionNumber in package file name when used in combination with DEB-DEFAULT value set by CPACK_DEBIAN_FILE_NAME). See CPACK_DEBIAN_PACKAGE_RELEASE.

  • The CPack DEB Generator learned how to set the package architecture per-component. See CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE.

  • The CPack DragNDrop Generator learned a new option to skip the /Applications symlink. See the CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK variable.

  • The CPackIFW module gained a new cpack_ifw_update_repository() command to update a QtIFW-specific repository from a remote repository.

  • The CPack RPM Generator learned how to set RPM dist tag as part of RPM Release: tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See CPACK_RPM_PACKAGE_RELEASE_DIST.

  • The CPack RPM Generator learned how to set default values for owning user/group and file/directory permissions of package content. See CPACK_RPM_DEFAULT_USER, CPACK_RPM_DEFAULT_GROUP, CPACK_RPM_DEFAULT_FILE_PERMISSIONS, CPACK_RPM_DEFAULT_DIR_PERMISSIONS and their per component counterparts.

  • The CPack RPM Generator learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See CPACK_RPM_PACKAGE_NAME and CPACK_RPM_<component>_PACKAGE_NAME.

  • The CPack RPM Generator learned how to correctly handle symlinks that are pointing outside generated packages.

Other

  • The Compile Features functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms.

Deprecated and Removed Features

  • The CMakeForceCompiler module and its macros are now deprecated. See module documentation for an explanation.
  • The find_library(), find_path(), and find_file() commands no longer search in installation prefixes derived from the PATH environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some <prefix>/bin directories in the PATH just for their tools do not necessarily want any supporting <prefix>/lib directories searched. One may set the CMAKE_PREFIX_PATH environment variable with a semicolon-separated list of prefixes that are to be searched.
  • The Visual Studio 7 .NET 2003 generator is now deprecated and will be removed in a future version of CMake.
  • The Visual Studio 7 generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3.
  • The Visual Studio 6 generator has been removed. It had been deprecated since CMake 3.3.

Other Changes

  • The precompiled OS X binary provided on cmake.org now requires OS X 10.7 or newer.
  • On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via https, such as file(DOWNLOAD), file(UPLOAD), and ctest_submit().
  • The cmake(1) --build command-line tool now rejects multiple --target options with an error instead of silently ignoring all but the last one.
  • AUTOMOC now diagnoses name collisions when multiple source files in different directories use #include <moc_foo.cpp> with the same name (because the generated moc_foo.cpp files would collide).
  • The FindBISON module BISON_TARGET macro now supports special characters by passing the VERBATIM option to internal add_custom_command() calls. This may break clients that added escaping manually to work around the bug.
  • The FindFLEX module FLEX_TARGET macro now supports special characters by passing the VERBATIM option to internal add_custom_command() calls. This may break clients that added escaping manually to work around the bug.
  • The FindProtobuf module input and output variables were all renamed from PROTOBUF_ to Protobuf_ for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided.
  • The CPack RPM Generator now supports upper cased component names in per component CPackRPM specific variables. E.g. component named foo now expects component specific variable to be CPACK_RPM_FOO_PACKAGE_NAME while before it expected CPACK_RPM_foo_PACKAGE_NAME. Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format.
  • The CPack NSIS generator’s configuration file template was fixed to quote the path to the uninstaller tool used by the CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL option. This avoids depending on an insecure Windows feature to run an uninstaller tool with a space in the path.

  • CMake Release Notes »


CMake 3.5 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.5 Release Notes

Contents

  • CMake 3.5 Release Notes
    • New Features
      • GUI
      • Command-Line
      • Commands
      • Variables
      • Properties
      • Modules
      • Platforms
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.4 include the following.

New Features

GUI

  • The cmake-gui(1) gained options to control warnings about deprecated functionality.
  • The cmake-gui(1) learned an option to set the toolset to be used with VS IDE and Xcode generators, much like the existing -T option to cmake(1).
  • The cmake-gui(1) gained a Regular Expression Explorer which may be used to create and evaluate regular expressions in real-time. The explorer window is available via the Tools menu.

Command-Line

  • The -Wdev and -Wno-dev cmake(1) options now also enable and suppress the deprecated warnings output by default.
  • The suppression of developer warnings as errors can now be controlled with the new -Werror=dev and -Wno-error=dev cmake(1) options.
  • The cmake(1) -E command-line tools copy, copy_if_different, copy_directory, and make_directory learned to support multiple input files or directories.

Commands

  • The cmake_parse_arguments() command is now implemented natively. The CMakeParseArguments module remains as an empty placeholder for compatibility.
  • The install(DIRECTORY) command learned to support generator expressions in the list of directories.

Variables

  • The CMAKE_ERROR_DEPRECATED variable can now be set using the -Werror=deprecated and -Wno-error=deprecated cmake(1) options.
  • The CMAKE_WARN_DEPRECATED variable can now be set using the -Wdeprecated and -Wno-deprecated cmake(1) options.

Properties

  • The VS_GLOBAL_<variable> target property is now implemented for VS 2010 and above. Previously it worked only in VS 2008 and below.

Modules

  • The ExternalProject module learned a new GIT_REMOTE_NAME option to control the git clone --origin value.
  • The FindBoost module now provides imported targets such as Boost::boost and Boost::filesystem.
  • The FindFLEX module FLEX_TARGET macro learned a new DEFINES_FILE option to specify a custom output header to be generated.
  • The FindGTest module now provides imported targets.
  • The FindGTK2 module, when GTK2_USE_IMPORTED_TARGETS is enabled, now sets GTK2_LIBRARIES to contain the list of imported targets instead of the paths to the libraries. Moreover it now sets a new GTK2_TARGETS variable containing all the targets imported.
  • The FindOpenMP module learned to support Clang.
  • The FindOpenSSL module gained a new OPENSSL_MSVC_STATIC_RT option to search for libraries using the MSVC static runtime.
  • The FindPNG module now provides imported targets.
  • The FindTIFF module now provides imported targets.
  • A FindXalanC module was introduced to find the Apache Xalan-C++ XSL transform processing library.
  • The FindXercesC module now provides imported targets.

Platforms

  • Support was added for the ARM Compiler (arm.com) with compiler id ARMCC.
  • A new platform file for cross-compiling in the Cray Linux Environment to target compute nodes was added. See Cross Compiling for the Cray Linux Environment for usage details.
  • The Compile Features functionality is now aware of features supported by Clang compilers on Windows (MinGW).
  • When building for embedded Apple platforms like iOS CMake learned to build and install combined targets which contain both a device and a simulator build. This behavior can be enabled by setting the IOS_INSTALL_COMBINED target property.

CPack

  • The CPack DragNDrop Generator learned new variable to specify AppleScript file run to customize appearance of DragNDrop installer folder, including background image setting using supplied PNG or multi-resolution TIFF file. See the CPACK_DMG_DS_STORE_SETUP_SCRIPT and CPACK_DMG_BACKGROUND_IMAGE variables.
  • The CPack DEB Generator learned to set the optional config file Source field using a monolithic or per-component variable. See CPACK_DEBIAN_PACKAGE_SOURCE.
  • The CPack DEB Generator learned to set Package, Section and Priority control fields per-component. See variables CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION and CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY.
  • The CPack DragNDrop Generator learned to add multi-lingual SLAs to a DMG which is presented to the user when they try to mount the DMG. See the CPACK_DMG_SLA_LANGUAGES and CPACK_DMG_SLA_DIR variables for details.
  • The CPack NSIS Generator learned new variables to add bitmaps to the installer. See the CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP and CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP variables.
  • The CPack RPM Generator learned to set Name and Group control fields per-component. See CPACK_RPM_<component>_PACKAGE_NAME and CPACK_RPM_<component>_PACKAGE_GROUP.

Other

  • Warnings about deprecated functionality are now enabled by default. They may be suppressed with -Wno-deprecated or by setting the CMAKE_WARN_DEPRECATED variable to false.

Deprecated and Removed Features

  • The cmake(1) -E time command now properly passes arguments with spaces or special characters through to the child process. This may break scripts that worked around the bug with their own extra quoting or escaping.
  • The Xcode generator was fixed to escape backslashes in strings consistently with other generators. Projects that previously worked around the inconsistecy with an extra level of backslashes conditioned on the Xcode generator must be updated to remove the workaround for CMake 3.5 and greater.

Other Changes

  • The Visual Studio 14 2015 generator learned to map the /debug:fastlink linker flag to the .vcxproj file property.
  • The FindGTK2 module now configures the GTK2::sigc++ imported target to enable c++11 on its dependents when using sigc++ 2.5.1 or higher.
  • The precompiled Windows binary provided on cmake.org is now a .msi package instead of an installer executable. One may need to manually uninstall CMake versions lower than 3.5 before installing the new package.

  • CMake Release Notes »


CMake 3.4 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.4 Release Notes

Contents

  • CMake 3.4 Release Notes
    • New Features
      • Generators
      • Commands
      • Variables
      • Properties
      • Modules
      • Generator Expressions
      • CTest
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.3 include the following.

New Features

Generators

  • The Visual Studio 14 2015 generator learned to select a Windows 10 SDK based on the value of the CMAKE_SYSTEM_VERSION variable and the SDKs available on the host.
  • CMake learned rudimentary support for the Apple Swift language. When using the Xcode generator with Xcode 6.1 or higher, one may enable the Swift language with the enable_language() command or the project() command (this is an error with other generators or when Xcode is too old). Then one may list .swift source files in targets for compilation.

Commands

  • The find_program() command learned a NAMES_PER_DIR option to consider all given NAMES in each directory before moving on to the next directory.
  • The get_filename_component() command learned a new BASE_DIR subcommand. This is used to specify a base directory when calculating an absolute path from a relative path.
  • The if() command learned a new TEST operator that evaluates to true if a given test name has been defined by the add_test() command. See policy CMP0064.
  • The install(DIRECTORY) command DESTINATION option learned to support generator expressions.
  • The install(FILES) command DESTINATION option learned to support generator expressions.
  • The string() command learned a new APPEND subcommand.

Variables

  • The Makefile Generators and the Ninja generator learned to add compiler launcher tools like distcc and ccache along with the compiler for C and CXX languages. See the CMAKE_<LANG>_COMPILER_LAUNCHER variable and <LANG>_COMPILER_LAUNCHER target property for details.
  • New CMAKE_LINK_SEARCH_START_STATIC and CMAKE_LINK_SEARCH_END_STATIC variables were introduced to initialize the LINK_SEARCH_START_STATIC and LINK_SEARCH_END_STATIC target properties, respectively.

Properties

  • Visual Studio Generators learned to support additional target properties to customize projects for NVIDIA Nsight Tegra Visual Studio Edition:
    • ANDROID_ANT_ADDITIONAL_OPTIONS
    • ANDROID_ARCH
    • ANDROID_ASSETS_DIRECTORIES
    • ANDROID_JAR_DEPENDENCIES
    • ANDROID_JAR_DIRECTORIES
    • ANDROID_JAVA_SOURCE_DIR
    • ANDROID_NATIVE_LIB_DEPENDENCIES
    • ANDROID_NATIVE_LIB_DIRECTORIES
    • ANDROID_PROCESS_MAX
    • ANDROID_PROGUARD
    • ANDROID_PROGUARD_CONFIG_PATH
    • ANDROID_SECURE_PROPS_PATH
    • ANDROID_SKIP_ANT_STEP
    • ANDROID_STL_TYPE
  • The ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and RUNTIME_OUTPUT_DIRECTORY target properties learned to support generator expressions.
  • The SOURCE_DIR and BINARY_DIR target properties were introduced to allow project code to query where a target is defined.
  • The OUTPUT_NAME target property and its variants learned to support generator expressions.
  • A TARGET_MESSAGES global property was added to tell the Makefile Generators whether to generate commands to print output after each target is completed.
  • On Windows with MS-compatible tools, CMake learned to optionally generate a module definition (.def) file for SHARED libraries. See the WINDOWS_EXPORT_ALL_SYMBOLS target property.

Modules

  • The ExternalProject module ExternalProject_Add() function GIT_SUBMODULES option now also limits the set of submodules that are initialized in addition to the prior behavior of limiting the set of submodules that are updated.
  • The ExternalProject module learned new USES_TERMINAL arguments for giving steps exclusive terminal access. This is useful with the Ninja generator to monitor CMake superbuild progress and prevent CPU oversubscription.
  • The FindBISON module BISON_TARGET macro learned a new DEFINES_FILE option to specify a custom output header to be generated.
  • The FindHDF5 module learend a new HDF5_PREFER_PARALLEL option allowing users to specify that a parallel HDF5 tool is preferred if both are available.
  • The FindIce module now provides imported targets.
  • The FindJava module learned to optionally find the idlj and jarsigner tools.
  • The FindOpenSSL module now provides imported targets.
  • The FindOpenSSL module learned a new OPENSSL_USE_STATIC_LIBS option to search only for static libraries.
  • The FindPkgConfig learned a new pkg_get_variable() command which may be used to query for arbitrary variables from a package (such as for related tools or data and plugin install paths).
  • The FindProtobuf module gained a new protobuf_generate_python() function to generate python sources from .proto files.
  • The FindTIFF module learned to search separately for debug and release variants.
  • The FindwxWidgets module learned to support version requests.
  • The FindXercesC module learned to search separately for debug and release variants.
  • The FindZLIB module learned to search separately for debug and release variants.
  • The GNUInstallDirs module learned special default values for certain installation prefixes according to the GNU Coding Standards and the Filesystem Hierarchy Standard.
  • The UseJava module add_jar function learned to support response files (e.g. @srcs.txt) for source specification.
  • The UseJava module install_jar function learned new DESTINATION and COMPONENT options to specify the corresponding install() command options.
  • The UseJava module gained a new create_javah function to create C headers from Java classes.

Generator Expressions

  • A new $<SHELL_PATH:...> generator expression has been added.

CTest

  • CTest learned to optionally measure the CPU load during parallel testing and avoid starting tests that may cause the load to exceed a given threshold. See the ctest(1) command --test-load option, the TestLoad setting of the CTest Test Step, the CTEST_TEST_LOAD variable, and the TEST_LOAD option of the ctest_test() command.
  • ctest(1) learned options --test-output-size-passed and --test-output-size-failed to customize the limit on test output size submitted when running as a Dashboard Client.

CPack

  • The CPack DEB Generator learned to set package dependencies per component. See variables:
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS
  • The CPack module learned to package empty directories.
  • The CPack module gained a new setting, CPACK_VERBATIM_VARIABLES, which can be used to ensure the cpack program receives the settings’ values exactly as they were set, even if they contain CMake-special characters. For compatibility, it’s off by default.

Other

  • The Compile Features functionality is now aware of features supported by GNU C compilers on Windows.
  • CMake learned to honor *.manifest source files with MSVC tools. Manifest files named as sources of .exe and .dll targets will be merged with linker-generated manifests and embedded in the binary.
  • The Concurrent Fortran 77 compiler is now supported. Its compiler id is CCur.
  • cmake(1) gained a new --trace-expand command line option that is like --trace but expands variable references in the output.

Deprecated and Removed Features

  • The CMakeExpandImportedTargets module is now documented as deprecated. See module documentation for an explanation.
  • The CMAKE_USE_RELATIVE_PATHS variable no longer has any effect. Previously it was partially implemented and unreliable.

Other Changes

  • The CheckFunctionExists, CheckLibraryExists, CheckSymbolExists, and FindThreads modules learned to work in environments where only CXX is enabled.
  • The CPack DEB Generator now correctly excludes symlinks during package checksum calculation.
  • The CPack DEB Generator no longer uses fakeroot and system tar program for packaging.
  • The CPack module no longer mangles settings with CMake-special characters when they’re used as defaults for other settings. The macro cpack_set_if_not_set, which was responsible for this, is now deprecated.
  • CMake no longer links executables with flags to export symbols unless the ENABLE_EXPORTS target property is set. See policy CMP0065.
  • The SONAME field is no longer set for MODULE libraries created with the add_library() command. MODULE libraries are meant for explicit dynamic loading at runtime. They cannot be linked so SONAME is not useful.
  • The internal CMAKE_<LANG>_COMPILE_OBJECT rule variable now substitutes compiler include flags in a separate <INCLUDES> placeholder instead of the main <FLAGS> placeholder.

  • CMake Release Notes »


CMake 3.3 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.3 Release Notes

Contents

  • CMake 3.3 Release Notes
    • New Features
      • Generators
      • Commands
      • Variables
      • Properties
      • Modules
      • Generator Expressions
      • CTest
      • CPack
      • Other
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.2 include the following.

New Features

Generators

  • The Makefile Generators now add .DELETE_ON_ERROR to the makefiles that contain the actual build rules for files on disk. This tells GNU make to remove rule outputs when their recipe modifies an output but fails.
  • The Visual Studio Generators learned to support .xaml source files and automatically associate them with corresponding .h and .cpp sources.
  • A new experimental Green Hills MULTI generator was added on Windows. Green Hills MULTI is an IDE for embedded real-time systems.

Commands

  • The add_dependencies() command learned to allow dependencies to be added to interface libraries. Dependencies added to an interface library are followed transitively in its place since the target itself does not build.
  • The execute_process() command learned to support specifying the same file for OUTPUT_FILE and ERROR_FILE.
  • The file(GLOB) and file(GLOB_RECURSE) commands learned a new LIST_DIRECTORIES <bool> option to specify whether the glob result should include directories.
  • The find_library(), find_path(), and find_file() commands now search in installation prefixes derived from the PATH environment variable.
  • The if() command learned a new IN_LIST operator that evaluates to true if a given element is contained in a named list.
  • The install(EXPORT) and export() commands learned to export targets that populate the INTERFACE_SOURCES target property.
  • The install(TARGETS) command learned to support generator expressions in the DESTINATION value.

Variables

  • The version of some Fortran compilers is now detected and stored in the CMAKE_Fortran_COMPILER_VERSION variable.
  • The Visual Studio Generators learned a new CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD option to put the INSTALL target in the default build of a solution (.sln) file.

Properties

  • A CROSSCOMPILING_EMULATOR target property and supporting CMAKE_CROSSCOMPILING_EMULATOR variable were introduced to allow target platform binaries to run on the host during cross compiling.
  • A <LANG>_INCLUDE_WHAT_YOU_USE target property and supporting CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE variable were introduced to tell the Makefile Generators and the Ninja generator to run include-what-you-use along with the compiler for C and CXX languages.
  • The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target properties now affect compilation in sources of all target types. See policy CMP0063.
  • The XCODE_ATTRIBUTE_<an-attribute> target property learned to support generator expressions.

Modules

  • The CheckFortranCompilerFlag module was introduced to check Fortran compiler flags, much like the CheckCCompilerFlag module already does for C.
  • The ExternalData module learned a new ExternalData_NO_SYMLINKS option to disable use of symbolic links to populate the real data files and use copies instead.
  • The ExternalData module learned a new RECURSE: option in DATA{} references specifying directories. This allows an entire directory tree of associated files to be matched.
  • The ExternalData module learned a new URL template placeholder %(algo:<key>) to allow custom mapping from algorithm name to URL component through configuration of new ExternalData_URL_ALGO_<algo>_<key> variables. This allows more flexibility in remote URLs.
  • The ExternalProject module learned to replace tokens like <BINARY_DIR> in the BYPRODUCTS of each step.
  • The ExternalProject module APIs learned to support generator expressions when using LOG_* options and in CMake initial cache options.
  • The FindBoost module now tracks the directories containing libraries separately for RELEASE and DEBUG configurations.
  • The FindCUDA module now defaults to using the static CUDA runtime library if it is available. A new CUDA_USE_STATIC_CUDA_RUNTIME option is offered to control this behavior.
  • The FindMatlab module was completely rewritten. It learned about versions and components and to find Matlab in a more precise and multiplatform way. The module now offers APIs to create mex extensions, documentation, and unit tests.
  • The FindPackageHandleStandardArgs module FIND_PACKAGE_HANDLE_STANDARD_ARGS function now always populates both the <PackageName>_FOUND and <UPPERCASE_NAME>_FOUND variables (the latter for backwards compatibility). The FOUND_VAR option is now ignored except to enforce its allowed values.
  • The InstallRequiredSystemLibraries module learned a new CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT option to specify the installation component.

Generator Expressions

  • A new COMPILE_LANGUAGE generator expression was introduced to allow specification of compile options for target files based on the LANGUAGE of each source file. Due to limitations of the underlying native build tools, this feature has varying support across generators. See the cmake-generator-expressions(7) manual for details.

CTest

  • The ctest(1) tool learned a new --repeat-until-fail <n> option to help find sporadic test failures.
  • The CTestCoverageCollectGCOV module learned to support the same CTEST_CUSTOM_COVERAGE_EXCLUDE option as the ctest_coverage() command.

CPack

  • The CPack IFW Generator learned to support Qt Framework Installer 2.0 tools.
  • The CPack DEB Generator learned a new CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS variable to specify per-component use of dpkg-shlibdeps.
  • The CPack DEB Generator learned a new CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS option to specify per-component dependencies.
  • The CPack RPM Generator learned to package symbolic links more cleanly and now supports directory symlinks with recent rpmbuild versions.
  • The CPack RPM Generator learned a new CPACK_RPM_ADDITIONAL_MAN_DIRS variable to specify directories containing man pages for the brp-compress RPM macro.
  • The CPack RPM Generator learned a new CPACK_RPM_<component>_PACKAGE_ARCHITECTURE variable to specify a component-specific package architecture.
  • The CPack WIX generator learned the new CPACK_START_MENU_SHORTCUTS, CPACK_DESKTOP_SHORTCUTS and CPACK_STARTUP_SHORTCUTS installed file properties which can be used to install shorcuts in the Start Menu, on the Desktop and in the Startup Folder respectively.

Other

  • The Compile Features functionality is now aware of features supported by GNU compilers on Windows, versions 4.4 through 5.0.
  • The cmake(1) -E tar command learned a new --format<format> option to specify the archive format to be written.
  • On OS X, CMake learned to create XCTest bundles to test Frameworks and App Bundles within Xcode. The FindXCTest module provides convenience functions to handle XCTEST bundles.

Deprecated and Removed Features

  • On OS X the cmake-gui(1) no longer has the Install For Command Line Use menu item. Instead there is a How to Install For Command Line Use menu item that shows an informational dialog box explaining how to make the command line tools available. For example:

    /Applications/CMake.app/Contents/bin/cmake-gui --install

  • The ctest_build() and build_command() commands no longer tell make tools to ignore errors with the -i option. Previously this was done for Makefile Generators but not others. See policy CMP0061.

  • The Visual Studio 10 2010 generator no longer checks for running VS IDEs with the project open or asks them to reload. This was originally done for VS 10 because it had been done for VS 7 through 9 to avoid prompting for every project in a solution. Since VS >= 10 allow the whole solution to reload at once they do not need CMake to help them.

  • The Visual Studio 7 generator (.NET 2002) is now deprecated and will be removed in a future version of CMake.

  • The Visual Studio 6 generator is now deprecated and will be removed in a future version of CMake.

  • The find_package() command no longer considers project build trees recently configured in a cmake-gui(1). This was previously done only on Windows and is now never done. The NO_CMAKE_BUILDS_PATH option is now ignored if given and effectively always on. Projects may populate the User Package Registry to aid users building multiple dependent projects one after another.

  • The add_definitions() command no longer causes a DEFINITIONS directory property to be populated. See policy CMP0059.

  • With Visual Studio 7, 8, and 9 generators the value of the $(OutDir) placeholder no longer evaluates to the configuration name. Projects should use $(ConfigurationName) for that instead.

  • Using the output of export() with the install(FILES) command is no longer allowed. See policy CMP0062 for details.

Other Changes

  • The Ninja generator now requires that calls to the add_custom_command() and add_custom_target() commands use the BYPRODUCTS option to explicitly specify any files generated by the custom commands that are not listed as outputs (perhaps because their timestamps are allowed to be older than the inputs). See policy CMP0058.
  • Build-time progress output of Makefile Generators has been improved. It no longer mixes progress and build rule messages during parallel builds. The link rule messages now have progress and are displayed as bold green instead of bold red (since red is often associated with an error message).
  • The CMAKE_CFG_INTDIR variable value for Visual Studio 7, 8, and 9 is now $(ConfigurationName) instead of $(OutDir). This should have no effect on the intended use cases of the variable.
  • Linking to library files by a full path in an implicit linker search directory (e.g. /usr/lib/libfoo.a) no longer asks the linker to search for the library (e.g. -lfoo) and now links by full path. See policy CMP0060.

  • CMake Release Notes »


CMake 3.2 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.2 Release Notes

Contents

  • CMake 3.2 Release Notes
    • New Features
      • Syntax
      • Commands
      • Variables
      • Properties
      • Modules
      • CTest
      • CPack
      • Other
    • New Diagnostics
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.1 include the following.

New Features

Syntax

  • CMake learned to support unicode characters encoded as UTF-8 on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as .h.in files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters.

Commands

  • The add_custom_command() and add_custom_target() commands learned a new BYPRODUCTS option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs.
  • The add_custom_command() and add_custom_target() commands learned a new USES_TERMINAL option to request that the command be given direct access to the terminal if possible. The Ninja generator will places such commands in the console pool. Build targets provided by CMake that are meant for individual interactive use, such as install, are now placed in this pool.
  • A new continue() command was added that can be called inside loop contexts to end the current iteration and start the next one at the top of the loop block.
  • The file(LOCK) subcommand was created to allow CMake processes to synchronize through file and directory locks.
  • The file(STRINGS) now supports UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE as ENCODING options.
  • The install(EXPORT) command now works with an absolute DESTINATION even if targets in the export set are installed with a destination or usage requirements specified relative to the install prefix. The value of the CMAKE_INSTALL_PREFIX variable is hard-coded into the installed export file as the base for relative references.
  • The try_compile() command source file signature now honors link flags (e.g. CMAKE_EXE_LINKER_FLAGS) in the generated test project. See policy CMP0056.
  • The try_run() command learned to honor the LINK_LIBRARIES option just as try_compile() already does.
  • The file(GENERATE) command now generates the output file with the same permissions as the input file if set.
  • The file(GENERATE) command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their GENERATED property set to TRUE.

Variables

  • The CMAKE_MATCH_COUNT variable was introduced to record the number of matches made in the last regular expression matched in an if() command or a string() command.

Properties

  • An ANDROID_API_MIN target property was introduced to specify the minimum version to be targeted by the toolchain.
  • A VS_SHADER_FLAGS source file property was added to specify additional shader flags to .hlsl files, for the Visual Studio generators.

Modules

  • The ExternalData module learned to support Custom Fetch Scripts. This allows projects to specify custom .cmake scripts for fetching data objects during the build.
  • The ExternalProject module learned options to create independent external project step targets that do not depend on the builtin steps.
  • The ExternalProject module ExternalProject_Add() command learned a new CMAKE_CACHE_DEFAULT_ARGS option to initialize cache values in the external project without setting them on future builds.
  • The ExternalProject module ExternalProject_Add() command learned a new TEST_EXCLUDE_FROM_MAIN option to exclude tests from the main build.
  • The ExternalProject module ExternalProject_Add() command learned a new UPDATE_DISCONNECTED option to avoid automatically updating the source tree checkout from version control.
  • The FindCUDA module learned about the cusolver library in CUDA 7.0.
  • The FindGit module learned to find the git command-line tool that comes with GitHub for Windows installed in user home directories.
  • A FindGSL module was introduced to find the GNU Scientific Library.
  • A FindIntl module was introduced to find the Gettext libintl library.
  • The FindLATEX module learned to support components.
  • The FindMPI module learned to find MS-MPI on Windows.
  • The FindOpenSSL module now reports crypto and ssl libraries separately in OPENSSL_CRYPTO_LIBRARY and OPENSSL_SSL_LIBRARY, respectively, to allow applications to link to one without the other.
  • The WriteCompilerDetectionHeader module learned to create a define for portability of the cxx_thread_local feature. The define expands to either the C++11 thread_local keyword, or a pre-standardization compiler-specific equivalent, as appropriate.
  • The WriteCompilerDetectionHeader module learned to create multiple output files per compiler and per language, instead of creating one large file.

CTest

  • The ctest_coverage() command learned to support Delphi coverage.
  • The ctest_coverage() command learned to support Javascript coverage.
  • The CTestCoverageCollectGCOV module was introduced as an alternative to the ctest_coverage() command for collecting gcov results for submission to CDash.

CPack

  • The CPack RPM Generator learned options to set per-component descriptions and summaries. See the CPACK_RPM_<component>_PACKAGE_DESCRIPTION and CPACK_RPM_<component>_PACKAGE_SUMMARY variables.
  • The CPack RPM Generator learned options to specify requirements for pre- and post-install scripts. See the CPACK_RPM_PACKAGE_REQUIRES_PRE and CPACK_RPM_PACKAGE_REQUIRES_POST variables.
  • The CPack RPM Generator learned options to specify requirements for pre- and post-uninstall scripts. See the CPACK_RPM_PACKAGE_REQUIRES_PREUN and CPACK_RPM_PACKAGE_REQUIRES_POSTUN variables.
  • The CPack RPM Generator learned a new CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX variable to specify a component-specific value to use instead of CPACK_PACKAGING_INSTALL_PREFIX.
  • The CPack RPM Generator learned a new CPACK_RPM_RELOCATION_PATHS variable to specify multiple relocation prefixes for a single rpm package.

Other

  • The cmake(1) -E tar command now supports creating .xz-compressed archives with the J flag.
  • The cmake(1) -E tar command learned a new --files-from=<file> option to specify file names using lines in a file to overcome command-line length limits.
  • The cmake(1) -E tar command learned a new --mtime=<date> option to specify the modification time recorded in tarball entries.
  • The Compile Features functionality is now aware of features supported by more compilers, including:
    • Apple Clang (AppleClang) for Xcode versions 4.4 though 6.1.
    • GNU compiler versions 4.4 through 5.0 on UNIX and Apple (GNU).
    • Microsoft Visual Studio (MSVC) for versions 2010 through 2015.
    • Oracle SolarisStudio (SunPro) version 12.4.
  • The AUTORCC feature now tracks files listed in .qrc files as dependencies. If an input file to the rcc tool is changed, the tool is automatically re-run.

New Diagnostics

  • The break() command now rejects calls outside of a loop context or that pass arguments to the command. See policy CMP0055.

Deprecated and Removed Features

  • Files written in the cmake-language(7), such as CMakeLists.txt or *.cmake files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted.
  • The FindOpenGL module no longer explicitly searches for any dependency on X11 libraries with the FindX11 module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly.
  • The implementation of CMake now relies on some C++ compiler features which are not supported by some older compilers. As a result, those old compilers can no longer be used to build CMake itself. CMake continues to be able to generate Makefiles and project files for users of those old compilers however. Compilers known to no longer be capable of building CMake are:
    • Visual Studio 6 and 7.0 – superseded by VisualStudio 7.1 and newer.
    • GCC 2.95 – superseded by GCC 3 and newer compilers.
    • Borland compilers – superseded by other Windows compilers.
    • Compaq compilers – superseded by other compilers.
    • SGI compilers – IRIX was dropped as a host platform.

Other Changes

  • On Windows and OS X, commands supporting network communication via https, such as file(DOWNLOAD), file(UPLOAD), and ctest_submit(), now support SSL/TLS even when CMake is not built against OpenSSL. The Windows or OS X native SSL/TLS implementation is used by default. OS-configured certificate authorities will be trusted automatically.

    On other platforms, when CMake is built with OpenSSL, these commands now search for OS-configured certificate authorities in a few /etc paths to be trusted automatically.

  • On OS X with Makefile and Ninja generators, when a compiler is found in /usr/bin it is now mapped to the corresponding compiler inside the Xcode application folder, if any. This allows such build trees to continue to work with their original compiler even when xcode-select switches to a different Xcode installation.

  • The Visual Studio generators now write solution and project files in UTF-8 instead of Windows-1252. Windows-1252 supported Latin 1 languages such as those found in North and South America and Western Europe. With UTF-8, additional languages are now supported.

  • The Xcode generator no longer requires a value for the CMAKE_MAKE_PROGRAM variable to be located up front. It now locates xcodebuild when needed at build time.

  • When building CMake itself using SolarisStudio 12, the default libCStd standard library is not sufficient to build CMake. The SolarisStudio distribution supports compiler options to use STLPort4 or libstdc++. An appropriate option to select the standard library is now added automatically when building CMake with SolarisStudio compilers.

  • CMake Release Notes »


CMake 3.1 Release Notes — CMake 3.14.0-rc4 Documentation

  • next |
  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.1 Release Notes

Contents

  • CMake 3.1 Release Notes
    • Documentation Changes
    • New Features
      • Generators
        • Windows Phone and Windows Store
        • NVIDIA Nsight Tegra
      • Syntax
      • Commands
      • Variables
      • Properties
      • Modules
      • Generator Expressions
      • CTest
      • CPack
      • Other
    • New Diagnostics
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 3.0 include the following.

Documentation Changes

  • A new cmake-compile-features(7) manual was added.

New Features

Generators

  • The Visual Studio 14 2015 generator was added.

Windows Phone and Windows Store

  • Generators for Visual Studio 11 (2012) and above learned to generate projects for Windows Phone and Windows Store. One may set the CMAKE_SYSTEM_NAME variable to WindowsPhone or WindowsStore on the cmake(1) command-line or in a CMAKE_TOOLCHAIN_FILE to activate these platforms. Also set CMAKE_SYSTEM_VERSION to 8.0 or 8.1 to specify the version of Windows to be targeted.

NVIDIA Nsight Tegra

  • Generators for Visual Studio 10 (2010) and above learned to generate projects for NVIDIA Nsight Tegra Visual Studio Edition. One may set the CMAKE_SYSTEM_NAME variable to Android on the cmake(1) command-line or in a CMAKE_TOOLCHAIN_FILE to activate this platform.

Syntax

  • The cmake-language(7) syntax for Variable References and Escape Sequences was simplified in order to allow a much faster implementation. See policy CMP0053.
  • The if() command no longer automatically dereferences variables named in quoted or bracket arguments. See policy CMP0054.

Commands

  • The add_custom_command() command learned to interpret cmake-generator-expressions(7) in arguments to DEPENDS.
  • The export(PACKAGE) command learned to check the CMAKE_EXPORT_NO_PACKAGE_REGISTRY variable to skip exporting the package.
  • The file(STRINGS) command gained a new ENCODING option to enable extraction of UTF-8 strings.
  • The find_package() command learned to check the CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY and CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY variables to skip searching the package registries.
  • The get_property() command learned a new INSTALL scope for properties.
  • The install() command learned a MESSAGE_NEVER option to avoid output during installation.
  • The set_property() command learned a new INSTALL scope for properties.
  • The string() command learned a new GENEX_STRIP subcommand which removes generator expression.
  • The string() command learned a new UUID subcommand to generate a univerally unique identifier.
  • New target_compile_features() command allows populating the COMPILE_FEATURES target property, just like any other build variable.
  • The target_sources() command was added to add to the SOURCES target property.

Variables

  • The Visual Studio generators for versions 8 (2005) and above learned to read the target platform name from a new CMAKE_GENERATOR_PLATFORM variable when it is not specified as part of the generator name. The platform name may be specified on the cmake(1) command line with the -A option, e.g. -G "Visual Studio 12 2013" -A x64.
  • The CMAKE_GENERATOR_TOOLSET variable may now be initialized in a toolchain file specified by the CMAKE_TOOLCHAIN_FILE variable. This is useful when cross-compiling with the Xcode or Visual Studio generators.
  • The CMAKE_INSTALL_MESSAGE variable was introduced to optionally reduce output installation.

Properties

  • New CXX_STANDARD and CXX_EXTENSIONS target properties may specify values which CMake uses to compute required compile options such as -std=c++11 or -std=gnu++11. The CMAKE_CXX_STANDARD and CMAKE_CXX_EXTENSIONS variables may be set to initialize the target properties.
  • New C_STANDARD and C_EXTENSIONS target properties may specify values which CMake uses to compute required compile options such as -std=c11 or -std=gnu11. The CMAKE_C_STANDARD and CMAKE_C_EXTENSIONS variables may be set to initialize the target properties.
  • New COMPILE_FEATURES target property may contain a list of features required to compile a target. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags to support language features.
  • New COMPILE_PDB_NAME and COMPILE_PDB_OUTPUT_DIRECTORY target properties were introduced to specify the MSVC compiler program database file location (cl /Fd). This complements the existing PDB_NAME and PDB_OUTPUT_DIRECTORY target properties that specify the linker program database file location (link /pdb).
  • The INTERFACE_LINK_LIBRARIES target property now supports a $<LINK_ONLY:...> generator expression.
  • A new INTERFACE_SOURCES target property was introduced. This is consumed by dependent targets, which compile and link the listed sources.
  • The SOURCES target property now contains generator expression such as TARGET_OBJECTS when read at configure time, if policy CMP0051 is NEW.
  • The SOURCES target property now generally supports generator expression. The generator expressions may be used in the add_library() and add_executable() commands.
  • It is now possible to write and append to the SOURCES target property. The CMAKE_DEBUG_TARGET_PROPERTIES variable may be used to trace the origin of sources.
  • A VS_DEPLOYMENT_CONTENT source file property was added to tell the Visual Studio generators to mark content for deployment in Windows Phone and Windows Store projects.
  • A VS_DEPLOYMENT_LOCATION source file property was added to tell the Visual Studio generators the relative location of content marked for deployment in Windows Phone and Windows Store projects.
  • The VS_WINRT_COMPONENT target property was created to tell Visual Studio generators to compile a shared library as a Windows Runtime (WinRT) component.
  • The Xcode generator learned to check source file properties XCODE_EXPLICIT_FILE_TYPE and XCODE_LAST_KNOWN_FILE_TYPE for a custom Xcode file reference type.

Modules

  • The BundleUtilities module learned to resolve and replace @rpath placeholders on OS X to correctly bundle applications using them.
  • The CMakePackageConfigHelpers module configure_package_config_file() command learned a new INSTALL_PREFIX option to generate package configuration files meant for a prefix other than CMAKE_INSTALL_PREFIX.
  • The CheckFortranSourceCompiles module was added to provide a CHECK_Fortran_SOURCE_COMPILES macro.
  • The ExternalData module learned to tolerate a DATA{} reference to a missing source file with a warning instead of rejecting it with an error. This helps developers write new DATA{} references to test reference outputs that have not yet been created.
  • The ExternalProject module learned to support lzma-compressed source tarballs with .7z, .tar.xz, and .txz extensions.
  • The ExternalProject module ExternalProject_Add command learned a new BUILD_ALWAYS option to cause the external project build step to run every time the host project is built.
  • The ExternalProject module ExternalProject_Add command learned a new EXCLUDE_FROM_ALL option to cause the external project target to have the EXCLUDE_FROM_ALL target property set.
  • The ExternalProject module ExternalProject_Add_Step command learned a new EXCLUDE_FROM_MAIN option to cause the step to not be a direct dependency of the main external project target.
  • The ExternalProject module ExternalProject_Add command learned a new DOWNLOAD_NO_PROGRESS option to disable progress output while downloading the source tarball.
  • The FeatureSummary module feature_summary API learned to accept multiple values for the WHAT option and combine them appropriately.
  • The FindCUDA module learned to support fatbin and cubin modules.
  • The FindGTest module gtest_add_tests macro learned a new AUTO option to automatically read the SOURCES target property of the test executable and scan the source files for tests to be added.
  • The FindGLEW module now provides imported targets.
  • The FindGLUT module now provides imported targets.
  • The FindHg module gained a new Hg_WC_INFO macro to help run hg to extract information about a Mercurial work copy.
  • The FindOpenCL module was introduced.
  • The FindOpenMP module learned to support Fortran.
  • The FindPkgConfig module learned to use the PKG_CONFIG environment variable value as the pkg-config executable, if set.
  • The FindXercesC module was introduced.
  • The FindZLIB module now provides imported targets.
  • The GenerateExportHeader module generate_export_header function learned to allow use with Object Libraries.
  • The InstallRequiredSystemLibraries module gained a new CMAKE_INSTALL_OPENMP_LIBRARIES option to install MSVC OpenMP runtime libraries.
  • The UseSWIG module learned to detect the module name from .i source files if possible to avoid the need to set the SWIG_MODULE_NAME source file property explicitly.
  • The WriteCompilerDetectionHeader module was added to allow creation of a portable header file for compiler optional feature detection.

Generator Expressions

  • New COMPILE_FEATURES generator expression allows setting build properties based on available compiler features.

CTest

  • The ctest_coverage() command learned to read variable CTEST_COVERAGE_EXTRA_FLAGS to set CoverageExtraFlags.
  • The ctest_coverage() command learned to support Intel coverage files with the codecov tool.
  • The ctest_memcheck() command learned to support sanitizer modes, including AddressSanitizer, MemorySanitizer, ThreadSanitizer, and UndefinedBehaviorSanitizer. Options may be set using the new CTEST_MEMORYCHECK_SANITIZER_OPTIONS variable.

CPack

  • cpack(1) gained an IFW generator to package using Qt Framework Installer tools. See the CPack IFW Generator.
  • cpack(1) gained 7Z and TXZ generators supporting lzma-compressed archives.
  • The CPack DEB Generator learned a new CPACK_DEBIAN_COMPRESSION_TYPE variable to set the tarball compression type.
  • The CPack WIX Generator learned to support a CPACK_WIX_ACL installed file property to specify an Access Control List.

Other

  • The cmake(1) -E option learned a new env command.
  • The cmake(1) -E tar command learned to support lzma-compressed files.
  • Object Libraries may now have extra sources that do not compile to object files so long as they would not affect linking of a normal library (e.g. .dat is okay but not .def).
  • Visual Studio generators for VS 8 and later learned to support the ASM_MASM language.
  • The Visual Studio generators learned to treat .hlsl source files as High Level Shading Language sources (using FXCompile in .vcxproj files). Source file properties VS_SHADER_TYPE, VS_SHADER_MODEL, and VS_SHADER_ENTRYPOINT were added added to specify the shader type, model, and entry point name.

New Diagnostics

  • Policy CMP0052 introduced to control directories in the INTERFACE_INCLUDE_DIRECTORIES of exported targets.

Deprecated and Removed Features

  • In CMake 3.0 the target_link_libraries() command accidentally began allowing unquoted arguments to use generator expressions containing a (; separated) list within them. For example:

    set(libs B C)
target_link_libraries(A PUBLIC $<BUILD_INTERFACE:${libs}>)

    This is equivalent to writing:

    target_link_libraries(A PUBLIC $<BUILD_INTERFACE:B C>)

    and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments:

    set(libs B C)
target_link_libraries(A PUBLIC "$<BUILD_INTERFACE:${libs}>")

    CMake 3.1 again requires the quotes for this to work correctly.

  • Prior to CMake 3.1 the Makefile generators did not escape # correctly inside make variable assignments used in generated makefiles, causing them to be treated as comments. This made code like:

    add_compile_options(-Wno-#pragma-messages)

    not work in Makefile generators, but work in other generators. Now it is escaped correctly, making the behavior consistent across generators. However, some projects may have tried to workaround the original bug with code like:

    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-\\#pragma-messages")

    This added the needed escape for Makefile generators but also caused other generators to pass -Wno-\#pragma-messages to the shell, which would work only in POSIX shells. Unfortunately the escaping fix could not be made in a compatible way so this platform- and generator-specific workaround no longer works. Project code may test the CMAKE_VERSION variable value to make the workaround version-specific too.

  • Callbacks established by the variable_watch() command will no longer receive the ALLOWED_UNKNOWN_READ_ACCESS access type when the undocumented CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS variable is set. Uninitialized variable accesses will always be reported as UNKNOWN_READ_ACCESS.

  • The CMakeDetermineVSServicePack module now warns that it is deprecated and should not longer be used. Use the CMAKE_<LANG>_COMPILER_VERSION variable instead.

  • The FindITK module has been removed altogether. It was a thin-wrapper around find_package(ITK ... NO_MODULE). This produces much clearer error messages when ITK is not found.

  • The FindVTK module has been removed altogether. It was a thin-wrapper around find_package(VTK ... NO_MODULE). This produces much clearer error messages when VTK is not found.

    The module also provided compatibility support for finding VTK 4.0. This capability has been dropped.

Other Changes

  • The cmake-gui(1) learned to capture output from child processes started by the execute_process() command and display it in the output window.
  • The cmake-language(7) internal implementation of generator expression and list expansion parsers have been optimized and shows non-trivial speedup on large projects.
  • The Makefile generators learned to use response files with GNU tools on Windows to pass library directories and names to the linker.
  • When generating linker command-lines, CMake now avoids repeating items corresponding to SHARED library targets.
  • Support for the Open Watcom compiler has been overhauled. The CMAKE_<LANG>_COMPILER_ID is now OpenWatcom, and the CMAKE_<LANG>_COMPILER_VERSION now uses the Open Watcom external version numbering. The external version numbers are lower than the internal version number by 11.
  • The cmake-mode.el major Emacs editing mode no longer treats _ as part of words, making it more consistent with other major modes.

  • CMake Release Notes »


CMake 3.0 Release Notes — CMake 3.14.0-rc4 Documentation

  • previous |
  • CMake »
  • 3.14.0-rc4 Documentation »
  • CMake Release Notes »

CMake 3.0 Release Notes

Contents

  • CMake 3.0 Release Notes
    • Documentation Changes
    • New Features
      • Syntax
      • Generators
      • Commands
      • Variables
      • Properties
      • Modules
      • Generator Expressions
      • Other
    • New Diagnostics
    • Deprecated and Removed Features
    • Other Changes

Changes made since CMake 2.8.12 include the following.

Documentation Changes

  • The CMake documentation has been converted to reStructuredText and now transforms via Sphinx (http://sphinx-doc.org) into man and html pages. This allows the documentation to be properly indexed and to contain cross-references.

    Conversion from the old internal documentation format was done by an automatic process so some documents may still contain artifacts. They will be updated incrementally over time.

    A basic reStructuredText processor has been implemented to support cmake --help-command and similar command-line options.

  • New manuals were added:

    • cmake-buildsystem(7)
    • cmake-commands(7), replacing cmakecommands(1) and cmakecompat(1)
    • cmake-developer(7)
    • cmake-generator-expressions(7)
    • cmake-generators(7)
    • cmake-language(7)
    • cmake-modules(7), replacing cmakemodules(1)
    • cmake-packages(7)
    • cmake-policies(7), replacing cmakepolicies(1)
    • cmake-properties(7), replacing cmakeprops(1)
    • cmake-qt(7)
    • cmake-toolchains(7)
    • cmake-variables(7), replacing cmakevars(1)

  • Release notes for CMake 3.0.0 and above will now be included with the html documentation.

New Features

Syntax

  • The CMake language has been extended with Bracket Argument and Bracket Comment syntax inspired by Lua long brackets:

    set(x [===[bracket argument]===] #[[bracket comment]])

    Content between equal-length open- and close-brackets is taken literally with no variable replacements.

    Warning

    This syntax change could not be made in a fully compatible way. No policy is possible because syntax parsing occurs before any chance to set a policy. Existing code using an unquoted argument that starts with an open bracket will be interpreted differently without any diagnostic. Fortunately the syntax is obscure enough that this problem is unlikely in practice.

Generators

  • A new CodeLite extra generator is available for use with the Makefile or Ninja generators.
  • A new Kate extra generator is available for use with the Makefile or Ninja generators.
  • The Ninja generator learned to use ninja job pools when specified by a new JOB_POOLS global property.

Commands

  • The add_library() command learned a new INTERFACE library type. Interface libraries have no build rules but may have properties defining usage requirements and may be installed, exported, and imported. This is useful to create header-only libraries that have concrete link dependencies on other libraries.
  • The export() command learned a new EXPORT mode that retrieves the list of targets to export from an export set configured by the install(TARGETS) command EXPORT option. This makes it easy to export from the build tree the same targets that are exported from the install tree.
  • The export() command learned to work with multiple dependent export sets, thus allowing multiple packages to be built and exported from a single tree. The feature requires CMake to wait until the generation step to write the output file. This means one should not include() the generated targets file later during project configuration because it will not be available. Use Alias Targets instead. See policy CMP0024.
  • The install(FILES) command learned to support generator expressions in the list of files.
  • The project() command learned to set some version variables to values specified by the new VERSION option or to empty strings. See policy CMP0048.
  • The string() command learned a new CONCAT mode. It is particularly useful in combination with the new Bracket Argument syntax.
  • The unset() command learned a PARENT_SCOPE option matching that of the set() command.
  • The include_external_msproject() command learned to handle non-C++ projects like .vbproj or .csproj.
  • The ctest_update() command learned to update work trees managed by the Perforce (p4) version control tool.
  • The message() command learned a DEPRECATION mode. Such messages are not issued by default, but may be issued as a warning if CMAKE_WARN_DEPRECATED is enabled, or as an error if CMAKE_ERROR_DEPRECATED is enabled.
  • The target_link_libraries() command now allows repeated use of the LINK_PUBLIC and LINK_PRIVATE keywords.

Variables

  • Variable CMAKE_FIND_NO_INSTALL_PREFIX has been introduced to tell CMake not to add the value of CMAKE_INSTALL_PREFIX to the CMAKE_SYSTEM_PREFIX_PATH variable by default. This is useful when building a project that installs some of its own dependencies to avoid finding files it is about to replace.
  • Variable CMAKE_STAGING_PREFIX was introduced for use when cross-compiling to specify an installation prefix on the host system that differs from a CMAKE_INSTALL_PREFIX value meant for the target system.
  • Variable CMAKE_SYSROOT was introduced to specify the toolchain SDK installation prefix, typically for cross-compiling. This is used to pass a --sysroot option to the compiler and as a prefix searched by find_* commands.
  • Variable CMAKE_<LANG>_COMPILER_TARGET was introduced for use when cross-compiling to specify the target platform in the toolchain file specified by the CMAKE_TOOLCHAIN_FILE variable. This is used to pass an option such as --target=<triple> to some cross-compiling compiler drivers.
  • Variable CMAKE_MAP_IMPORTED_CONFIG_<CONFIG> has been introduced to optionally initialize the MAP_IMPORTED_CONFIG_<CONFIG> target property.

Properties

  • The ADDITIONAL_MAKE_CLEAN_FILES directory property learned to support generator expressions.
  • A new directory property CMAKE_CONFIGURE_DEPENDS was introduced to allow projects to specify additional files on which the configuration process depends. CMake will re-run at build time when one of these files is modified. Previously this was only possible to achieve by specifying such files as the input to a configure_file() command.
  • A new AUTORCC feature replaces the need to invoke qt4_add_resources() by allowing .qrc files to be listed as target sources.
  • A new AUTOUIC feature replaces the need to invoke qt4_wrap_ui().
  • Test properties learned to support generator expressions. This is useful to specify per-configuration values for test properties like REQUIRED_FILES and WORKING_DIRECTORY.
  • A new SKIP_RETURN_CODE test property was introduced to tell ctest(1) to treat a particular test return code as if the test were not run. This is useful for test drivers to report that certain test requirements were not available.
  • New types of Compatible Interface Properties were introduced, namely the COMPATIBLE_INTERFACE_NUMBER_MAX and COMPATIBLE_INTERFACE_NUMBER_MIN for calculating numeric maximum and minimum values respectively.

Modules

  • The CheckTypeSize module check_type_size macro and the CheckStructHasMember module check_struct_has_member macro learned a new LANGUAGE option to optionally check C++ types.
  • The ExternalData module learned to work with no URL templates if a local store is available.
  • The ExternalProject function ExternalProject_Add learned a new GIT_SUBMODULES option to specify a subset of available submodules to checkout.
  • A new FindBacktrace module has been added to support find_package(Backtrace) calls.
  • A new FindLua module has been added to support find_package(Lua) calls.
  • The FindBoost module learned a new Boost_NAMESPACE option to change the boost prefix on library names.
  • The FindBoost module learned to control search for libraries with the g tag (for MS debug runtime) with a new Boost_USE_DEBUG_RUNTIME option. It is ON by default to preserve existing behavior.
  • The FindJava and FindJNI modules learned to use a JAVA_HOME CMake variable or environment variable, and then try /usr/libexec/java_home on OS X.
  • The UseJava module add_jar function learned a new MANIFEST option to pass the -m option to jar.
  • A new CMakeFindDependencyMacro module was introduced with a find_dependency macro to find transitive dependencies in a package configuration file. Such dependencies are omitted by the listing of the FeatureSummary module.
  • The FindQt4 module learned to create Imported Targets for Qt executables. This helps disambiguate when using multiple Qt versions in the same buildsystem.
  • The FindRuby module learned to search for Ruby 2.0 and 2.1.

Generator Expressions

  • New $<PLATFORM_ID> and $<PLATFORM_ID:...> generator expressions have been added.
  • The $<CONFIG> generator expression now has a variant which takes no argument. This is equivalent to the $<CONFIGURATION> expression.
  • New $<UPPER_CASE:...> and $<LOWER_CASE:...> generator expressions generator expressions have been added.
  • A new $<MAKE_C_IDENTIFIER:...> generator expression has been added.

Other

  • The cmake(1) -E option learned a new sleep command.
  • The ccmake(1) dialog learned to honor the STRINGS cache entry property to cycle through the enumerated list of possible values.
  • The cmake-gui(1) dialog learned to remember window settings between sessions.
  • The cmake-gui(1) dialog learned to remember the type of a cache entry for completion in the Add Entry dialog.

New Diagnostics

  • Directories named in the INTERFACE_INCLUDE_DIRECTORIES target property of imported targets linked conditionally by a generator expression were not checked for existence. Now they are checked. See policy CMP0027.
  • Build target names must now match a validity pattern and may no longer conflict with CMake-defined targets. See policy CMP0037.
  • Build targets that specify themselves as a link dependency were silently accepted but are now diagnosed. See CMP0038.
  • The target_link_libraries() command used to silently ignore calls specifying as their first argument build targets created by add_custom_target() but now diagnoses this mistake. See policy CMP0039.
  • The add_custom_command() command used to silently ignore calls specifying the TARGET option with a non-existent target but now diagnoses this mistake. See policy CMP0040.
  • Relative paths in the INTERFACE_INCLUDE_DIRECTORIES target property used to be silently accepted if they contained a generator expression but are now rejected. See policy CMP0041.
  • The get_target_property() command learned to reject calls specifying a non-existent target. See policy CMP0045.
  • The add_dependencies() command learned to reject calls specifying a dependency on a non-existent target. See policy CMP0046.
  • Link dependency analysis learned to assume names containing :: refer to Alias Targets or Imported Targets. It will now produce an error if such a linked target is missing. Previously in this case CMake generated a link line that failed at build time. See policy CMP0028.
  • When the project() or enable_language() commands initialize support for a language, it is now an error if the full path to the compiler cannot be found and stored in the corresponding CMAKE_<LANG>_COMPILER variable. This produces nicer error messages up front and stops processing when no working compiler is known to be available.
  • Target sources specified with the add_library() or add_executable() command learned to reject items which require an undocumented extra layer of variable expansion. See policy CMP0049.
  • Use of add_custom_command() undocumented SOURCE signatures now results in an error. See policy CMP0050.

Deprecated and Removed Features

  • Compatibility options supporting code written for CMake versions prior to 2.4 have been removed.
  • Several long-outdated commands that should no longer be called have been disallowed in new code by policies:
    • Policy CMP0029 disallows subdir_depends()
    • Policy CMP0030 disallows use_mangled_mesa()
    • Policy CMP0031 disallows load_command()
    • Policy CMP0032 disallows output_required_files()
    • Policy CMP0033 disallows export_library_dependencies()
    • Policy CMP0034 disallows utility_source()
    • Policy CMP0035 disallows variable_requires()
    • Policy CMP0036 disallows build_name()
  • The cmake(1) -i wizard mode has been removed. Instead use an interactive dialog such as ccmake(1) or use the -D option to set cache values from the command line.
  • The builtin documentation formatters that supported command-line options such as --help-man and --help-html have been removed in favor of the above-mentioned new documentation system. These and other command-line options that used to generate man- and html- formatted pages no longer work. The cmake(1) --help-custom-modules option now produces a warning at runtime and generates a minimal document that reports the limitation.
  • The COMPILE_DEFINITIONS_<CONFIG> directory properties and the COMPILE_DEFINITIONS_<CONFIG> target properties have been deprecated. Instead set the corresponding COMPILE_DEFINITIONS directory property or COMPILE_DEFINITIONS target property and use generator expressions like $<CONFIG:...> to specify per-configuration definitions. See policy CMP0043.
  • The LOCATION target property should no longer be read from non-IMPORTED targets. It does not make sense in multi-configuration generators since the build configuration is not known while configuring the project. It has been superseded by the $<TARGET_FILE> generator expression. See policy CMP0026.
  • The COMPILE_FLAGS target property is now documented as deprecated, though no warning is issued. Use the COMPILE_OPTIONS target property or the target_compile_options() command instead.
  • The GenerateExportHeader module add_compiler_export_flags function is now deprecated. It has been superseded by the <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target properties.

Other Changes

  • The version scheme was changed to use only two components for the feature level instead of three. The third component will now be used for bug-fix releases or the date of development versions. See the CMAKE_VERSION variable documentation for details.

  • The default install locations of CMake itself on Windows and OS X no longer contain the CMake version number. This allows for easy replacement without re-generating local build trees manually.

  • Generators for Visual Studio 10 (2010) and later were renamed to include the product year like generators for older VS versions:

    • Visual Studio 10 -> Visual Studio 10 2010
    • Visual Studio 11 -> Visual Studio 11 2012
    • Visual Studio 12 -> Visual Studio 12 2013

    This clarifies which generator goes with each Visual Studio version. The old names are recognized for compatibility.

  • The CMAKE_<LANG>_COMPILER_ID value for Apple-provided Clang is now AppleClang. It must be distinct from upstream Clang because the version numbers differ. See policy CMP0025.

  • The CMAKE_<LANG>_COMPILER_ID value for qcc on QNX is now QCC. It must be distinct from GNU because the command-line options differ. See policy CMP0047.

  • On 64-bit OS X the CMAKE_HOST_SYSTEM_PROCESSOR value is now correctly detected as x86_64 instead of i386.

  • On OS X, CMake learned to enable behavior specified by the MACOSX_RPATH target property by default. This activates use of @rpath for runtime shared library searches. See policy CMP0042.

  • The build_command() command now returns a cmake(1) --build command line instead of a direct invocation of the native build tool. When using Visual Studio generators, CMake and CTest no longer require CMAKE_MAKE_PROGRAM to be located up front. Selection of the proper msbuild or devenv tool is now performed as late as possible when the solution (.sln) file is available so it can depend on project content.

  • The cmake(1) --build command now shares its own stdout and stderr pipes with the native build tool by default. The --use-stderr option that once activated this is now ignored.

  • The $<C_COMPILER_ID:...> and $<CXX_COMPILER_ID:...> generator expressions used to perform case-insensitive comparison but have now been corrected to perform case-sensitive comparison. See policy CMP0044.

  • The builtin edit_cache target will no longer select ccmake(1) by default when no interactive terminal will be available (e.g. with Ninja or an IDE generator). Instead cmake-gui(1) will be preferred if available.

  • The ExternalProject download step learned to re-attempt download in certain cases to be more robust to temporary network failure.

  • The FeatureSummary no longer lists transitive dependencies since they were not directly requested by the current project.

  • The cmake-mode.el major Emacs editing mode has been cleaned up and enhanced in several ways.

  • Include directories specified in the INTERFACE_INCLUDE_DIRECTORIES of Imported Targets are treated as SYSTEM includes by default when handled as usage requirements.

  • CMake Release Notes »


Index — CMake 3.14.0-rc4 Documentation

  • 3.14.0-rc4 Documentation »

Index

Symbols | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X

Symbols

  • <CONFIG>_OUTPUT_NAME
    • target property
  • <CONFIG>_POSTFIX
    • target property, [1]
  • <LANG>_CLANG_TIDY
    • target property, [1], [2], [3]
  • <LANG>_COMPILER_LAUNCHER
    • target property, [1], [2], [3], [4]
  • <LANG>_CPPCHECK
    • target property, [1], [2], [3]
  • <LANG>_CPPLINT
    • target property, [1], [2]
  • <LANG>_INCLUDE_WHAT_YOU_USE
    • target property, [1], [2]
  • <LANG>_VISIBILITY_PRESET
    • target property, [1], [2], [3], [4], [5], [6], [7]
  • <PackageName>_ROOT
    • envvar, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • <PROJECT-NAME>_BINARY_DIR
    • variable, [1]
  • <PROJECT-NAME>_DESCRIPTION
    • variable, [1]
  • <PROJECT-NAME>_HOMEPAGE_URL
    • variable, [1], [2]
  • <PROJECT-NAME>_SOURCE_DIR
    • variable, [1]
  • <PROJECT-NAME>_VERSION
    • variable, [1], [2], [3], [4], [5]
  • <PROJECT-NAME>_VERSION_MAJOR
    • variable, [1], [2]
  • <PROJECT-NAME>_VERSION_MINOR
    • variable, [1], [2]
  • <PROJECT-NAME>_VERSION_PATCH
    • variable, [1], [2]
  • <PROJECT-NAME>_VERSION_TWEAK
    • variable, [1], [2]

A

  • ABSTRACT
    • source file property
  • add_compile_definitions
    • command, [1], [2], [3], [4], [5]
  • add_compile_options
    • command, [1], [2], [3], [4], [5]
  • add_custom_command
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41]
  • add_custom_target
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28]
  • add_definitions
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • add_dependencies
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
  • add_executable
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44]
  • add_feature_info
    • command, [1]
  • add_library
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56]
  • add_link_options
    • command, [1], [2], [3], [4], [5]
  • add_subdirectory
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22]
  • add_test
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • AddFileDependencies
    • module
  • ADDITIONAL_MAKE_CLEAN_FILES
    • directory property, [1], [2]
  • ADVANCED
    • cache property
  • ALIASED_TARGET
    • target property, [1]
  • ALLOW_DUPLICATE_CUSTOM_TARGETS
    • global property
  • ANDROID
    • variable
  • android_add_test_data
    • command
  • ANDROID_ANT_ADDITIONAL_OPTIONS
    • target property, [1], [2], [3]
  • ANDROID_API
    • target property, [1], [2]
  • ANDROID_API_MIN
    • target property, [1], [2], [3]
  • ANDROID_ARCH
    • target property, [1], [2], [3]
  • ANDROID_ASSETS_DIRECTORIES
    • target property, [1], [2], [3]
  • ANDROID_GUI
    • target property, [1], [2]
  • ANDROID_JAR_DEPENDENCIES
    • target property, [1], [2], [3]
  • ANDROID_JAR_DIRECTORIES
    • target property, [1], [2], [3]
  • ANDROID_JAVA_SOURCE_DIR
    • target property, [1], [2], [3]
  • ANDROID_NATIVE_LIB_DEPENDENCIES
    • target property, [1], [2], [3]
  • ANDROID_NATIVE_LIB_DIRECTORIES
    • target property, [1], [2], [3]
  • ANDROID_PROCESS_MAX
    • target property, [1], [2], [3]
  • ANDROID_PROGUARD
    • target property, [1], [2], [3]
  • ANDROID_PROGUARD_CONFIG_PATH
    • target property, [1], [2], [3]
  • ANDROID_SECURE_PROPS_PATH
    • target property, [1], [2], [3]
  • ANDROID_SKIP_ANT_STEP
    • target property, [1], [2], [3]
  • ANDROID_STL_TYPE
    • target property, [1], [2], [3]
  • AndroidTestUtilities
    • module, [1]
  • APPLE
    • variable, [1]
  • ARCHIVE_OUTPUT_DIRECTORY
    • target property, [1], [2], [3], [4], [5], [6]
  • ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>
    • target property, [1], [2]
  • ARCHIVE_OUTPUT_NAME
    • target property, [1], [2], [3]
  • ARCHIVE_OUTPUT_NAME_<CONFIG>
    • target property, [1], [2]
  • ASM<DIALECT>
    • envvar
  • ASM<DIALECT>FLAGS
    • envvar
  • ATTACHED_FILES
    • test property, [1]
  • ATTACHED_FILES_ON_FAIL
    • test property
  • AUTOGEN_BUILD_DIR
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • AUTOGEN_ORIGIN_DEPENDS
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • AUTOGEN_PARALLEL
    • target property, [1], [2], [3], [4], [5], [6]
  • AUTOGEN_SOURCE_GROUP
    • global property, [1], [2], [3], [4], [5], [6], [7]
  • AUTOGEN_TARGET_DEPENDS
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • AUTOGEN_TARGETS_FOLDER
    • global property, [1], [2], [3], [4]
  • AUTOMOC
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69]
  • AUTOMOC_COMPILER_PREDEFINES
    • target property, [1], [2], [3], [4], [5], [6]
  • AUTOMOC_DEPEND_FILTERS
    • target property, [1], [2], [3], [4], [5]
  • AUTOMOC_EXECUTABLE
    • target property, [1], [2], [3]
  • AUTOMOC_MACRO_NAMES
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
  • AUTOMOC_MOC_OPTIONS
    • target property, [1], [2], [3]
  • AUTOMOC_SOURCE_GROUP
    • global property, [1], [2], [3]
  • AUTOMOC_TARGETS_FOLDER
    • global property
  • AUTORCC
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31]
  • AUTORCC_EXECUTABLE
    • target property, [1], [2], [3]
  • AUTORCC_OPTIONS
    • source file property, [1], [2], [3]
    • target property, [1], [2], [3], [4]
  • AUTORCC_SOURCE_GROUP
    • global property, [1], [2], [3]
  • AUTOUIC
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44]
  • AUTOUIC_EXECUTABLE
    • target property, [1], [2], [3]
  • AUTOUIC_OPTIONS
    • source file property, [1], [2], [3]
    • target property, [1], [2], [3], [4], [5], [6], [7]
  • AUTOUIC_SEARCH_PATHS
    • target property, [1], [2], [3], [4]
  • aux_source_directory
    • command

B

  • BINARY_DIR
    • directory property, [1]
    • target property, [1]
  • BORLAND
    • variable
  • Borland Makefiles
    • generator
  • break
    • command, [1], [2], [3], [4], [5], [6], [7], [8]
  • build_command
    • command, [1], [2], [3], [4]
  • build_name
    • command, [1], [2]
  • BUILD_RPATH
    • target property, [1], [2], [3]
  • BUILD_RPATH_USE_ORIGIN
    • target property, [1], [2]
  • BUILD_SHARED_LIBS
    • variable, [1], [2], [3], [4]
  • BUILD_WITH_INSTALL_NAME_DIR
    • target property, [1], [2], [3], [4]
  • BUILD_WITH_INSTALL_RPATH
    • target property, [1], [2], [3], [4], [5]
  • BUILDSYSTEM_TARGETS
    • directory property, [1]
  • BUNDLE
    • target property, [1], [2], [3], [4], [5], [6]
  • BUNDLE_EXTENSION
    • target property, [1]
  • BundleUtilities
    • module, [1], [2], [3], [4], [5], [6]

C

  • C_EXTENSIONS
    • target property, [1], [2], [3], [4], [5]
  • C_STANDARD
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • C_STANDARD_REQUIRED
    • target property, [1], [2], [3], [4]
  • CACHE
    • variable, [1]
  • cache property
    • ADVANCED
    • HELPSTRING
    • MODIFIED
    • STRINGS, [1], [2]
    • TYPE
    • VALUE
  • CACHE_VARIABLES
    • directory property
  • CC
    • envvar
  • ccmake(1)
    • manual, [1], [2], [3], [4], [5], [6], [7]
  • cdash_coverage_collect_gcov
    • command
  • CFLAGS
    • envvar, [1]
  • check_c_compiler_flag
    • command
  • check_c_source_compiles
    • command
  • check_c_source_runs
    • command
  • check_cxx_compiler_flag
    • command
  • check_cxx_source_compiles
    • command
  • check_cxx_source_runs
    • command
  • CHECK_CXX_SYMBOL_EXISTS
    • command
  • check_fortran_compiler_flag
    • command
  • CHECK_FORTRAN_FUNCTION_EXISTS
    • command
  • check_fortran_source_compiles
    • command
  • check_fortran_source_runs
    • command, [1], [2]
  • check_function_exists
    • command
  • CHECK_INCLUDE_FILE
    • command
  • CHECK_INCLUDE_FILE_CXX
    • command
  • CHECK_INCLUDE_FILES
    • command
  • check_include_files
    • command
  • check_ipo_supported
    • command
  • CHECK_LIBRARY_EXISTS
    • command
  • check_pie_supported
    • command
  • check_prototype_definition
    • command
  • CHECK_STRUCT_HAS_MEMBER
    • command
  • check_symbol_exists
    • command
  • CHECK_TYPE_SIZE
    • command
  • CHECK_VARIABLE_EXISTS
    • command
  • CheckCCompilerFlag
    • module, [1]
  • CheckCSourceCompiles
    • module, [1], [2], [3], [4]
  • CheckCSourceRuns
    • module
  • CheckCXXCompilerFlag
    • module, [1]
  • CheckCXXSourceCompiles
    • module, [1], [2]
  • CheckCXXSourceRuns
    • module
  • CheckCXXSymbolExists
    • module, [1], [2]
  • CheckFortranCompilerFlag
    • module, [1]
  • CheckFortranFunctionExists
    • module
  • CheckFortranSourceCompiles
    • module, [1], [2], [3]
  • CheckFortranSourceRuns
    • module, [1]
  • CheckFunctionExists
    • module, [1]
  • CheckIncludeFile
    • module, [1], [2], [3], [4], [5], [6]
  • CheckIncludeFileCXX
    • module, [1], [2], [3], [4], [5]
  • CheckIncludeFiles
    • module, [1], [2], [3], [4], [5], [6]
  • CheckIPOSupported
    • module, [1], [2], [3], [4], [5], [6]
  • CheckLanguage
    • module, [1]
  • CheckLibraryExists
    • module, [1]
  • CheckPIESupported
    • module, [1], [2], [3], [4], [5]
  • CheckPrototypeDefinition
    • module
  • CheckStructHasMember
    • module, [1]
  • CheckSymbolExists
    • module, [1], [2]
  • CheckTypeSize
    • module, [1], [2], [3], [4]
  • CheckVariableExists
    • module
  • CLEAN_NO_CUSTOM
    • directory property
  • cmake(1)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93]
  • cmake-buildsystem(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50]
  • cmake-commands(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
  • cmake-compile-features(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40]
  • cmake-developer(7)
    • manual, [1], [2]
  • cmake-env-variables(7)
    • manual, [1], [2], [3]
  • cmake-file-api(7)
    • manual, [1]
  • cmake-generator-expressions(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97], [98], [99], [100], [101], [102], [103], [104], [105], [106], [107], [108], [109], [110], [111], [112], [113], [114], [115], [116], [117], [118], [119], [120], [121], [122], [123], [124], [125], [126], [127], [128], [129], [130], [131], [132], [133], [134], [135], [136], [137], [138], [139], [140], [141], [142], [143], [144], [145]
  • cmake-generators(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • cmake-gui(1)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22]
  • cmake-language(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • cmake-modules(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • cmake-packages(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
  • cmake-policies(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97], [98], [99], [100], [101], [102], [103], [104], [105], [106]
  • cmake-properties(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • cmake-qt(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25]
  • cmake-server(7)
    • manual, [1], [2], [3], [4], [5], [6]
  • cmake-toolchains(7)
    • manual, [1]
  • cmake-variables(7)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • CMAKE_<CONFIG>_POSTFIX
    • variable, [1], [2]
  • CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE
    • variable, [1], [2]
  • CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX
    • variable, [1], [2], [3], [4]
  • CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX
    • variable, [1], [2], [3], [4]
  • CMAKE_<LANG>_ARCHIVE_APPEND
    • variable, [1], [2]
  • CMAKE_<LANG>_ARCHIVE_CREATE
    • variable, [1], [2]
  • CMAKE_<LANG>_ARCHIVE_FINISH
    • variable, [1], [2]
  • CMAKE_<LANG>_CLANG_TIDY
    • variable, [1], [2]
  • CMAKE_<LANG>_COMPILE_OBJECT
    • variable, [1]
  • CMAKE_<LANG>_COMPILER
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18]
  • CMAKE_<LANG>_COMPILER_ABI
    • variable
  • CMAKE_<LANG>_COMPILER_AR
    • variable, [1]
  • CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID
    • variable
  • CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN
    • variable, [1]
  • CMAKE_<LANG>_COMPILER_ID
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29]
  • CMAKE_<LANG>_COMPILER_LAUNCHER
    • variable, [1], [2], [3], [4]
  • CMAKE_<LANG>_COMPILER_LOADED
    • variable
  • CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND
    • variable, [1], [2], [3]
  • CMAKE_<LANG>_COMPILER_RANLIB
    • variable, [1]
  • CMAKE_<LANG>_COMPILER_TARGET
    • variable, [1], [2], [3]
  • CMAKE_<LANG>_COMPILER_VERSION
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
  • CMAKE_<LANG>_COMPILER_VERSION_INTERNAL
    • variable
  • CMAKE_<LANG>_CPPCHECK
    • variable, [1], [2], [3]
  • CMAKE_<LANG>_CPPLINT
    • variable, [1], [2]
  • CMAKE_<LANG>_CREATE_SHARED_LIBRARY
    • variable
  • CMAKE_<LANG>_CREATE_SHARED_MODULE
    • variable
  • CMAKE_<LANG>_CREATE_STATIC_LIBRARY
    • variable, [1], [2], [3]
  • CMAKE_<LANG>_FLAGS
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32]
  • CMAKE_<LANG>_FLAGS_<CONFIG>
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_<LANG>_FLAGS_<CONFIG>_INIT
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_<LANG>_FLAGS_DEBUG
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_<LANG>_FLAGS_DEBUG_INIT
    • variable
  • CMAKE_<LANG>_FLAGS_INIT
    • variable, [1], [2], [3]
  • CMAKE_<LANG>_FLAGS_MINSIZEREL
    • variable
  • CMAKE_<LANG>_FLAGS_MINSIZEREL_INIT
    • variable
  • CMAKE_<LANG>_FLAGS_RELEASE
    • variable
  • CMAKE_<LANG>_FLAGS_RELEASE_INIT
    • variable
  • CMAKE_<LANG>_FLAGS_RELWITHDEBINFO
    • variable
  • CMAKE_<LANG>_FLAGS_RELWITHDEBINFO_INIT
    • variable
  • CMAKE_<LANG>_IGNORE_EXTENSIONS
    • variable
  • CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES
    • variable
  • CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
    • variable
  • CMAKE_<LANG>_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES
    • variable
  • CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
    • variable
  • CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE
    • variable, [1], [2]
  • CMAKE_<LANG>_LIBRARY_ARCHITECTURE
    • variable, [1], [2]
  • CMAKE_<LANG>_LINK_EXECUTABLE
    • variable
  • CMAKE_<LANG>_LINKER_PREFERENCE
    • variable, [1]
  • CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES
    • variable, [1]
  • CMAKE_<LANG>_LINKER_WRAPPER_FLAG
    • variable, [1], [2], [3]
  • CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP
    • variable, [1], [2], [3]
  • CMAKE_<LANG>_OUTPUT_EXTENSION
    • variable
  • CMAKE_<LANG>_PLATFORM_ID
    • variable
  • CMAKE_<LANG>_SIMULATE_ID
    • variable
  • CMAKE_<LANG>_SIMULATE_VERSION
    • variable
  • CMAKE_<LANG>_SIZEOF_DATA_PTR
    • variable
  • CMAKE_<LANG>_SOURCE_FILE_EXTENSIONS
    • variable
  • CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES
    • variable, [1], [2]
  • CMAKE_<LANG>_STANDARD_LIBRARIES
    • variable, [1], [2]
  • CMAKE_<LANG>_VISIBILITY_PRESET
    • variable, [1], [2]
  • CMAKE_ABSOLUTE_DESTINATION_FILES
    • variable, [1]
  • CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS
    • variable, [1]
  • CMAKE_ANDROID_API
    • variable, [1], [2]
  • CMAKE_ANDROID_API_MIN
    • variable, [1]
  • CMAKE_ANDROID_ARCH
    • variable, [1], [2]
  • CMAKE_ANDROID_ARCH_ABI
    • variable, [1], [2], [3], [4], [5], [6]
  • CMAKE_ANDROID_ARM_MODE
    • variable, [1], [2], [3]
  • CMAKE_ANDROID_ARM_NEON
    • variable, [1], [2], [3]
  • CMAKE_ANDROID_ASSETS_DIRECTORIES
    • variable, [1]
  • CMAKE_ANDROID_GUI
    • variable, [1]
  • CMAKE_ANDROID_JAR_DEPENDENCIES
    • variable, [1]
  • CMAKE_ANDROID_JAR_DIRECTORIES
    • variable, [1]
  • CMAKE_ANDROID_JAVA_SOURCE_DIR
    • variable, [1]
  • CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES
    • variable, [1]
  • CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES
    • variable, [1]
  • CMAKE_ANDROID_NDK
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_ANDROID_NDK_DEPRECATED_HEADERS
    • variable, [1], [2]
  • CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG
    • variable
  • CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION
    • variable, [1]
  • CMAKE_ANDROID_PROCESS_MAX
    • variable, [1]
  • CMAKE_ANDROID_PROGUARD
    • variable, [1]
  • CMAKE_ANDROID_PROGUARD_CONFIG_PATH
    • variable, [1]
  • CMAKE_ANDROID_SECURE_PROPS_PATH
    • variable, [1]
  • CMAKE_ANDROID_SKIP_ANT_STEP
    • variable, [1]
  • CMAKE_ANDROID_STANDALONE_TOOLCHAIN
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_ANDROID_STL_TYPE
    • variable, [1], [2]
  • CMAKE_APPBUNDLE_PATH
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_AR
    • variable, [1]
  • CMAKE_ARCHIVE_OUTPUT_DIRECTORY
    • variable
  • CMAKE_ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>
    • variable, [1]
  • CMAKE_ARGC
    • variable, [1]
  • CMAKE_ARGV0
    • variable, [1]
  • CMAKE_AUTOGEN_ORIGIN_DEPENDS
    • variable, [1], [2], [3]
  • CMAKE_AUTOGEN_PARALLEL
    • variable, [1], [2], [3]
  • CMAKE_AUTOGEN_VERBOSE
    • variable, [1], [2], [3]
  • CMAKE_AUTOMOC
    • variable, [1], [2], [3], [4], [5], [6]
  • CMAKE_AUTOMOC_COMPILER_PREDEFINES
    • variable, [1], [2]
  • CMAKE_AUTOMOC_DEPEND_FILTERS
    • variable, [1], [2], [3], [4]
  • CMAKE_AUTOMOC_MACRO_NAMES
    • variable, [1], [2], [3]
  • CMAKE_AUTOMOC_MOC_OPTIONS
    • variable, [1]
  • CMAKE_AUTOMOC_RELAXED_MODE
    • variable, [1]
  • CMAKE_AUTORCC
    • variable, [1], [2], [3]
  • CMAKE_AUTORCC_OPTIONS
    • variable, [1], [2]
  • CMAKE_AUTOUIC
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_AUTOUIC_OPTIONS
    • variable, [1], [2]
  • CMAKE_AUTOUIC_SEARCH_PATHS
    • variable, [1], [2]
  • CMAKE_BACKWARDS_COMPATIBILITY
    • variable
  • CMAKE_BINARY_DIR
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • CMAKE_BUILD_PARALLEL_LEVEL
    • envvar, [1]
  • CMAKE_BUILD_RPATH
    • variable, [1], [2]
  • CMAKE_BUILD_RPATH_USE_ORIGIN
    • variable, [1], [2]
  • CMAKE_BUILD_TOOL
    • variable
  • CMAKE_BUILD_TYPE
    • variable, [1], [2], [3], [4], [5], [6], [7], [8]
  • CMAKE_BUILD_WITH_INSTALL_NAME_DIR
    • variable, [1], [2]
  • CMAKE_BUILD_WITH_INSTALL_RPATH
    • variable, [1]
  • CMAKE_C_COMPILE_FEATURES
    • variable, [1], [2], [3]
  • CMAKE_C_EXTENSIONS
    • variable, [1], [2], [3], [4]
  • CMAKE_C_KNOWN_FEATURES
    • global property, [1], [2], [3], [4], [5]
  • CMAKE_C_STANDARD
    • variable, [1], [2], [3], [4]
  • CMAKE_C_STANDARD_REQUIRED
    • variable, [1], [2], [3]
  • CMAKE_CACHE_MAJOR_VERSION
    • variable
  • CMAKE_CACHE_MINOR_VERSION
    • variable
  • CMAKE_CACHE_PATCH_VERSION
    • variable
  • CMAKE_CACHEFILE_DIR
    • variable
  • CMAKE_CFG_INTDIR
    • variable, [1], [2]
  • CMAKE_CL_64
    • variable
  • CMAKE_CODEBLOCKS_COMPILER_ID
    • variable, [1]
  • CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES
    • variable, [1], [2]
  • CMAKE_CODELITE_USE_TARGETS
    • variable, [1], [2], [3]
  • CMAKE_COLOR_MAKEFILE
    • variable
  • CMAKE_COMMAND
    • variable, [1]
  • CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY
    • variable, [1], [2]
  • CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>
    • variable, [1]
  • CMAKE_COMPILER_2005
    • variable
  • CMAKE_COMPILER_IS_GNUCC
    • variable
  • CMAKE_COMPILER_IS_GNUCXX
    • variable
  • CMAKE_COMPILER_IS_GNUG77
    • variable
  • CMAKE_CONFIG_TYPE
    • envvar, [1]
  • CMAKE_CONFIGURATION_TYPES
    • variable, [1], [2], [3]
  • CMAKE_CONFIGURE_DEPENDS
    • directory property, [1]
  • CMAKE_CPACK_COMMAND
    • variable
  • CMAKE_CROSSCOMPILING
    • variable, [1], [2], [3], [4]
  • CMAKE_CROSSCOMPILING_EMULATOR
    • variable, [1], [2], [3]
  • CMAKE_CTEST_COMMAND
    • variable
  • CMAKE_CUDA_EXTENSIONS
    • variable, [1], [2], [3]
  • CMAKE_CUDA_HOST_COMPILER
    • variable, [1], [2]
  • CMAKE_CUDA_SEPARABLE_COMPILATION
    • variable, [1], [2]
  • CMAKE_CUDA_STANDARD
    • variable, [1], [2], [3]
  • CMAKE_CUDA_STANDARD_REQUIRED
    • variable, [1], [2], [3]
  • CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES
    • variable
  • CMAKE_CURRENT_BINARY_DIR
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21]
  • CMAKE_CURRENT_LIST_DIR
    • variable
  • CMAKE_CURRENT_LIST_FILE
    • variable, [1], [2], [3], [4]
  • CMAKE_CURRENT_LIST_LINE
    • variable
  • CMAKE_CURRENT_SOURCE_DIR
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • CMAKE_CXX_COMPILE_FEATURES
    • variable, [1], [2], [3], [4]
  • CMAKE_CXX_EXTENSIONS
    • variable, [1], [2], [3], [4]
  • CMAKE_CXX_KNOWN_FEATURES
    • global property, [1], [2], [3], [4], [5], [6]
  • CMAKE_CXX_STANDARD
    • variable, [1], [2], [3], [4], [5], [6]
  • CMAKE_CXX_STANDARD_REQUIRED
    • variable, [1], [2], [3]
  • CMAKE_DEBUG_POSTFIX
    • variable
  • CMAKE_DEBUG_TARGET_PROPERTIES
    • variable, [1], [2], [3]
  • CMAKE_DEPENDS_IN_PROJECT_ONLY
    • variable, [1]
  • CMAKE_DIRECTORY_LABELS
    • variable, [1], [2]
  • CMAKE_DISABLE_FIND_PACKAGE_<PackageName>
    • variable, [1], [2]
  • CMAKE_DL_LIBS
    • variable
  • CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION
    • variable, [1], [2]
  • CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES
    • variable
  • CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT
    • variable, [1]
  • CMAKE_ECLIPSE_MAKE_ARGUMENTS
    • variable
  • CMAKE_ECLIPSE_VERSION
    • variable
  • CMAKE_EDIT_COMMAND
    • variable
  • CMAKE_ENABLE_EXPORTS
    • variable, [1], [2]
  • CMAKE_ERROR_DEPRECATED
    • variable, [1], [2]
  • CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
    • variable, [1]
  • CMAKE_EXE_LINKER_FLAGS
    • variable, [1], [2], [3], [4], [5], [6], [7]
  • CMAKE_EXE_LINKER_FLAGS_<CONFIG>
    • variable, [1]
  • CMAKE_EXE_LINKER_FLAGS_<CONFIG>_INIT
    • variable, [1]
  • CMAKE_EXE_LINKER_FLAGS_INIT
    • variable, [1], [2], [3]
  • CMAKE_EXECUTABLE_SUFFIX
    • variable
  • CMAKE_EXPORT_COMPILE_COMMANDS
    • variable
  • CMAKE_EXPORT_NO_PACKAGE_REGISTRY
    • variable, [1], [2], [3], [4]
  • CMAKE_EXTRA_GENERATOR
    • variable
  • CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES
    • variable
  • CMAKE_FIND_APPBUNDLE
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_FIND_FRAMEWORK
    • variable, [1], [2], [3], [4], [5], [6], [7], [8]
  • CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_FIND_LIBRARY_PREFIXES
    • variable
  • CMAKE_FIND_LIBRARY_SUFFIXES
    • variable
  • CMAKE_FIND_NO_INSTALL_PREFIX
    • variable, [1], [2], [3]
  • CMAKE_FIND_PACKAGE_NAME
    • variable
  • CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY
    • variable, [1], [2], [3], [4]
  • CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY
    • variable, [1], [2], [3], [4]
  • CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS
    • variable, [1], [2]
  • CMAKE_FIND_PACKAGE_SORT_DIRECTION
    • variable, [1], [2], [3], [4]
  • CMAKE_FIND_PACKAGE_SORT_ORDER
    • variable, [1], [2], [3], [4], [5], [6]
  • CMAKE_FIND_PACKAGE_WARN_NO_MODULE
    • variable
  • CMAKE_FIND_ROOT_PATH
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37]
  • CMAKE_FIND_ROOT_PATH_MODE_INCLUDE
    • variable, [1], [2]
  • CMAKE_FIND_ROOT_PATH_MODE_LIBRARY
    • variable, [1]
  • CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
    • variable, [1]
  • CMAKE_FIND_ROOT_PATH_MODE_PROGRAM
    • variable, [1]
  • CMAKE_FOLDER
    • variable, [1], [2]
  • CMAKE_Fortran_FORMAT
    • variable
  • CMAKE_Fortran_MODDIR_DEFAULT
    • variable
  • CMAKE_Fortran_MODDIR_FLAG
    • variable
  • CMAKE_Fortran_MODOUT_FLAG
    • variable
  • CMAKE_Fortran_MODULE_DIRECTORY
    • variable
  • CMAKE_FRAMEWORK_PATH
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • CMAKE_GENERATOR
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_GENERATOR_INSTANCE
    • variable, [1], [2], [3], [4]
  • CMAKE_GENERATOR_PLATFORM
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
  • CMAKE_GENERATOR_TOOLSET
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25]
  • CMAKE_GHS_NO_SOURCE_GROUP_FILE
    • variable, [1], [2]
  • CMAKE_GLOBAL_AUTOGEN_TARGET
    • variable, [1], [2], [3], [4], [5], [6], [7]
  • CMAKE_GLOBAL_AUTOGEN_TARGET_NAME
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_GLOBAL_AUTORCC_TARGET
    • variable, [1], [2], [3], [4], [5], [6]
  • CMAKE_GLOBAL_AUTORCC_TARGET_NAME
    • variable, [1], [2], [3]
  • CMAKE_GNUtoMS
    • variable, [1]
  • CMAKE_HOME_DIRECTORY
    • variable
  • CMAKE_HOST_APPLE
    • variable
  • CMAKE_HOST_SOLARIS
    • variable, [1]
  • CMAKE_HOST_SYSTEM
    • variable
  • cmake_host_system_information
    • command, [1]
  • CMAKE_HOST_SYSTEM_NAME
    • variable, [1], [2], [3], [4], [5], [6]
  • CMAKE_HOST_SYSTEM_PROCESSOR
    • variable, [1], [2], [3]
  • CMAKE_HOST_SYSTEM_VERSION
    • variable, [1], [2], [3]
  • CMAKE_HOST_UNIX
    • variable
  • CMAKE_HOST_WIN32
    • variable
  • CMAKE_IGNORE_PATH
    • variable, [1], [2]
  • CMAKE_IMPORT_LIBRARY_PREFIX
    • variable
  • CMAKE_IMPORT_LIBRARY_SUFFIX
    • variable
  • CMAKE_INCLUDE_CURRENT_DIR
    • variable, [1]
  • CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE
    • variable, [1], [2]
  • CMAKE_INCLUDE_DIRECTORIES_BEFORE
    • variable, [1]
  • CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE
    • variable
  • CMAKE_INCLUDE_PATH
    • variable, [1], [2], [3], [4], [5], [6], [7]
  • CMAKE_INSTALL_DEFAULT_COMPONENT_NAME
    • variable, [1]
  • CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
    • variable, [1], [2], [3], [4], [5], [6], [7]
  • CMAKE_INSTALL_MESSAGE
    • variable, [1], [2], [3]
  • CMAKE_INSTALL_NAME_DIR
    • variable, [1], [2]
  • CMAKE_INSTALL_PREFIX
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25]
  • CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT
    • variable, [1]
  • CMAKE_INSTALL_RPATH
    • variable, [1], [2]
  • CMAKE_INSTALL_RPATH_USE_LINK_PATH
    • variable
  • CMAKE_INTERNAL_PLATFORM_ABI
    • variable
  • CMAKE_INTERPROCEDURAL_OPTIMIZATION
    • variable, [1], [2], [3]
  • CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
    • variable, [1]
  • CMAKE_IOS_INSTALL_COMBINED
    • variable, [1]
  • CMAKE_JOB_POOL_COMPILE
    • variable, [1], [2]
  • CMAKE_JOB_POOL_LINK
    • variable, [1], [2]
  • CMAKE_JOB_POOLS
    • variable, [1], [2]
  • CMAKE_LIBRARY_ARCHITECTURE
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
  • CMAKE_LIBRARY_ARCHITECTURE_REGEX
    • variable
  • CMAKE_LIBRARY_OUTPUT_DIRECTORY
    • variable
  • CMAKE_LIBRARY_OUTPUT_DIRECTORY_<CONFIG>
    • variable, [1]
  • CMAKE_LIBRARY_PATH
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_LIBRARY_PATH_FLAG
    • variable
  • CMAKE_LINK_DEF_FILE_FLAG
    • variable
  • CMAKE_LINK_DEPENDS_NO_SHARED
    • variable
  • CMAKE_LINK_DIRECTORIES_BEFORE
    • variable, [1]
  • CMAKE_LINK_INTERFACE_LIBRARIES
    • variable, [1]
  • CMAKE_LINK_LIBRARY_FILE_FLAG
    • variable
  • CMAKE_LINK_LIBRARY_FLAG
    • variable
  • CMAKE_LINK_LIBRARY_SUFFIX
    • variable
  • CMAKE_LINK_SEARCH_END_STATIC
    • variable, [1], [2], [3]
  • CMAKE_LINK_SEARCH_START_STATIC
    • variable, [1], [2], [3]
  • CMAKE_LINK_WHAT_YOU_USE
    • variable, [1], [2]
  • CMAKE_MACOSX_BUNDLE
    • variable, [1]
  • CMAKE_MACOSX_RPATH
    • variable, [1]
  • CMAKE_MAJOR_VERSION
    • variable, [1]
  • CMAKE_MAKE_PROGRAM
    • variable, [1], [2], [3], [4], [5], [6]
  • CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>
    • variable, [1], [2]
  • CMAKE_MATCH_<n>
    • variable, [1], [2], [3]
  • CMAKE_MATCH_COUNT
    • variable, [1], [2]
  • CMAKE_MAXIMUM_RECURSION_DEPTH
    • variable, [1]
  • CMAKE_MFC_FLAG
    • variable, [1]
  • cmake_minimum_required
    • command, [1], [2], [3], [4], [5], [6], [7], [8]
  • CMAKE_MINIMUM_REQUIRED_VERSION
    • variable, [1], [2], [3], [4]
  • CMAKE_MINOR_VERSION
    • variable, [1]
  • CMAKE_MODULE_LINKER_FLAGS
    • variable, [1], [2]
  • CMAKE_MODULE_LINKER_FLAGS_<CONFIG>
    • variable, [1]
  • CMAKE_MODULE_LINKER_FLAGS_<CONFIG>_INIT
    • variable, [1]
  • CMAKE_MODULE_LINKER_FLAGS_INIT
    • variable, [1], [2], [3]
  • CMAKE_MODULE_PATH
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • CMAKE_MSVCIDE_RUN_PATH
    • envvar
    • variable, [1]
  • CMAKE_NETRC
    • variable, [1]
  • CMAKE_NETRC_FILE
    • variable, [1]
  • CMAKE_NINJA_OUTPUT_PATH_PREFIX
    • variable, [1]
  • CMAKE_NO_BUILTIN_CHRPATH
    • variable
  • CMAKE_NO_SYSTEM_FROM_IMPORTED
    • variable, [1]
  • CMAKE_NO_VERBOSE
    • envvar, [1]
  • CMAKE_NOT_USING_CONFIG_FLAGS
    • variable
  • CMAKE_OBJECT_PATH_MAX
    • variable
  • CMAKE_OSX_ARCHITECTURES
    • envvar
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_OSX_DEPLOYMENT_TARGET
    • variable, [1], [2], [3], [4]
  • CMAKE_OSX_SYSROOT
    • variable, [1], [2], [3], [4]
  • CMAKE_PARENT_LIST_FILE
    • variable, [1]
  • cmake_parse_arguments
    • command, [1], [2], [3]
  • CMAKE_PATCH_VERSION
    • variable, [1]
  • CMAKE_PDB_OUTPUT_DIRECTORY
    • variable, [1], [2]
  • CMAKE_PDB_OUTPUT_DIRECTORY_<CONFIG>
    • variable, [1]
  • cmake_policy
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43]
  • CMAKE_POLICY_DEFAULT_CMP<NNNN>
    • variable, [1], [2], [3]
  • CMAKE_POLICY_WARNING_CMP<NNNN>
    • variable, [1], [2], [3], [4], [5], [6], [7], [8]
  • CMAKE_POSITION_INDEPENDENT_CODE
    • variable, [1], [2]
  • CMAKE_PREFIX_PATH
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
  • CMAKE_PROGRAM_PATH
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE
    • variable, [1]
  • CMAKE_PROJECT_DESCRIPTION
    • variable, [1], [2], [3]
  • CMAKE_PROJECT_HOMEPAGE_URL
    • variable, [1], [2], [3], [4], [5], [6], [7]
  • CMAKE_PROJECT_NAME
    • variable, [1], [2], [3]
  • CMAKE_PROJECT_VERSION
    • variable, [1], [2], [3], [4], [5], [6]
  • CMAKE_PROJECT_VERSION_MAJOR
    • variable, [1], [2], [3]
  • CMAKE_PROJECT_VERSION_MINOR
    • variable, [1], [2], [3]
  • CMAKE_PROJECT_VERSION_PATCH
    • variable, [1], [2], [3]
  • CMAKE_PROJECT_VERSION_TWEAK
    • variable, [1]
  • CMAKE_RANLIB
    • variable, [1]
  • CMAKE_ROLE
    • global property, [1], [2], [3], [4], [5], [6], [7], [8]
  • CMAKE_ROOT
    • variable, [1]
  • CMAKE_RULE_MESSAGES
    • variable, [1]
  • CMAKE_RUNTIME_OUTPUT_DIRECTORY
    • variable, [1]
  • CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG>
    • variable, [1]
  • CMAKE_SCRIPT_MODE_FILE
    • variable
  • CMAKE_SHARED_LIBRARY_PREFIX
    • variable
  • CMAKE_SHARED_LIBRARY_SUFFIX
    • variable, [1]
  • CMAKE_SHARED_LINKER_FLAGS
    • variable, [1], [2]
  • CMAKE_SHARED_LINKER_FLAGS_<CONFIG>
    • variable, [1]
  • CMAKE_SHARED_LINKER_FLAGS_<CONFIG>_INIT
    • variable, [1]
  • CMAKE_SHARED_LINKER_FLAGS_INIT
    • variable, [1], [2], [3]
  • CMAKE_SHARED_MODULE_PREFIX
    • variable
  • CMAKE_SHARED_MODULE_SUFFIX
    • variable
  • CMAKE_SIZEOF_VOID_P
    • variable, [1]
  • CMAKE_SKIP_BUILD_RPATH
    • variable
  • CMAKE_SKIP_INSTALL_ALL_DEPENDENCY
    • variable, [1]
  • CMAKE_SKIP_INSTALL_RPATH
    • variable, [1], [2], [3]
  • CMAKE_SKIP_INSTALL_RULES
    • variable
  • CMAKE_SKIP_RPATH
    • variable, [1], [2], [3], [4]
  • CMAKE_SOURCE_DIR
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
  • CMAKE_STAGING_PREFIX
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
  • CMAKE_STATIC_LIBRARY_PREFIX
    • variable
  • CMAKE_STATIC_LIBRARY_SUFFIX
    • variable
  • CMAKE_STATIC_LINKER_FLAGS
    • variable, [1]
  • CMAKE_STATIC_LINKER_FLAGS_<CONFIG>
    • variable, [1]
  • CMAKE_STATIC_LINKER_FLAGS_<CONFIG>_INIT
    • variable, [1]
  • CMAKE_STATIC_LINKER_FLAGS_INIT
    • variable, [1]
  • CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS
    • variable, [1]
  • CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE
    • variable, [1]
  • CMAKE_SUPPRESS_REGENERATION
    • variable, [1]
  • CMAKE_Swift_LANGUAGE_VERSION
    • variable, [1]
  • CMAKE_SYSROOT
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29]
  • CMAKE_SYSROOT_COMPILE
    • variable, [1], [2], [3]
  • CMAKE_SYSROOT_LINK
    • variable, [1], [2], [3]
  • CMAKE_SYSTEM
    • variable, [1], [2]
  • CMAKE_SYSTEM_APPBUNDLE_PATH
    • variable, [1]
  • CMAKE_SYSTEM_FRAMEWORK_PATH
    • variable, [1], [2], [3]
  • CMAKE_SYSTEM_IGNORE_PATH
    • variable, [1]
  • CMAKE_SYSTEM_INCLUDE_PATH
    • variable, [1], [2], [3], [4], [5]
  • CMAKE_SYSTEM_LIBRARY_PATH
    • variable, [1], [2], [3], [4]
  • CMAKE_SYSTEM_NAME
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29]
  • CMAKE_SYSTEM_PREFIX_PATH
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
  • CMAKE_SYSTEM_PROCESSOR
    • variable, [1]
  • CMAKE_SYSTEM_PROGRAM_PATH
    • variable, [1], [2], [3], [4]
  • CMAKE_SYSTEM_VERSION
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • CMAKE_TOOLCHAIN_FILE
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30]
  • CMAKE_TRY_COMPILE_CONFIGURATION
    • variable, [1], [2]
  • CMAKE_TRY_COMPILE_PLATFORM_VARIABLES
    • variable, [1], [2]
  • CMAKE_TRY_COMPILE_TARGET_TYPE
    • variable, [1], [2], [3], [4], [5], [6], [7], [8]
  • CMAKE_TWEAK_VERSION
    • variable, [1]
  • CMAKE_USE_RELATIVE_PATHS
    • variable, [1]
  • CMAKE_USER_MAKE_RULES_OVERRIDE
    • variable, [1]
  • CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>
    • variable
  • CMAKE_VERBOSE_MAKEFILE
    • variable, [1]
  • CMAKE_VERSION
    • variable, [1], [2], [3], [4], [5], [6], [7]
  • CMAKE_VISIBILITY_INLINES_HIDDEN
    • variable, [1], [2]
  • CMAKE_VS_DEVENV_COMMAND
    • variable, [1], [2]
  • CMAKE_VS_GLOBALS
    • variable, [1]
  • CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD
    • variable, [1], [2]
  • CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD
    • variable, [1]
  • CMAKE_VS_INTEL_Fortran_PROJECT_VERSION
    • variable
  • CMAKE_VS_MSBUILD_COMMAND
    • variable, [1], [2]
  • CMAKE_VS_NsightTegra_VERSION
    • variable
  • CMAKE_VS_PLATFORM_NAME
    • variable, [1]
  • CMAKE_VS_PLATFORM_TOOLSET
    • variable, [1]
  • CMAKE_VS_PLATFORM_TOOLSET_CUDA
    • variable, [1]
  • CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE
    • variable, [1]
  • CMAKE_VS_PLATFORM_TOOLSET_VERSION
    • variable, [1]
  • CMAKE_VS_SDK_EXCLUDE_DIRECTORIES
    • variable, [1]
  • CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES
    • variable, [1]
  • CMAKE_VS_SDK_INCLUDE_DIRECTORIES
    • variable, [1]
  • CMAKE_VS_SDK_LIBRARY_DIRECTORIES
    • variable, [1]
  • CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES
    • variable, [1]
  • CMAKE_VS_SDK_REFERENCE_DIRECTORIES
    • variable, [1]
  • CMAKE_VS_SDK_SOURCE_DIRECTORIES
    • variable, [1]
  • CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
    • variable, [1], [2], [3], [4]
  • CMAKE_VS_WINRT_BY_DEFAULT
    • variable
  • CMAKE_WARN_DEPRECATED
    • variable, [1], [2], [3], [4]
  • CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
    • variable, [1]
  • CMAKE_WIN32_EXECUTABLE
    • variable, [1]
  • CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS
    • variable, [1]
  • CMAKE_XCODE_ATTRIBUTE_<an-attribute>
    • variable, [1]
  • CMAKE_XCODE_GENERATE_SCHEME
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35]
  • CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY
    • variable, [1]
  • CMAKE_XCODE_PLATFORM_TOOLSET
    • variable
  • CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER
    • variable, [1]
  • CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
    • variable, [1]
  • CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
    • variable, [1]
  • CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
    • variable, [1]
  • CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
    • variable, [1]
  • CMAKE_XCODE_SCHEME_GUARD_MALLOC
    • variable, [1]
  • CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP
    • variable, [1]
  • CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES
    • variable, [1]
  • CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE
    • variable, [1]
  • CMAKE_XCODE_SCHEME_MALLOC_STACK
    • variable, [1]
  • CMAKE_XCODE_SCHEME_THREAD_SANITIZER
    • variable, [1]
  • CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP
    • variable, [1]
  • CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER
    • variable, [1]
  • CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP
    • variable, [1]
  • CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS
    • variable, [1]
  • CMakeAddFortranSubdirectory
    • module
  • CMakeBackwardCompatibilityCXX
    • module
  • CMakeDependentOption
    • module, [1]
  • CMakeDetermineVSServicePack
    • module, [1]
  • CMakeExpandImportedTargets
    • module, [1]
  • CMakeFindDependencyMacro
    • module, [1], [2], [3]
  • CMakeFindFrameworks
    • module
  • CMakeFindPackageMode
    • module
  • CMakeForceCompiler
    • module, [1]
  • CMakeGraphVizOptions
    • module, [1], [2]
  • CMakePackageConfigHelpers
    • module, [1], [2], [3], [4], [5], [6]
  • CMakeParseArguments
    • module, [1]
  • CMakePrintHelpers
    • module
  • CMakePrintSystemInformation
    • module
  • CMakePushCheckState
    • module, [1]
  • CMakeVerifyManifest
    • module
  • CMP0000
    • policy, [1], [2]
  • CMP0001
    • policy, [1]
  • CMP0002
    • policy
  • CMP0003
    • policy, [1], [2], [3]
  • CMP0004
    • policy, [1]
  • CMP0005
    • policy
  • CMP0006
    • policy
  • CMP0007
    • policy
  • CMP0008
    • policy
  • CMP0009
    • policy, [1], [2]
  • CMP0010
    • policy, [1]
  • CMP0011
    • policy, [1]
  • CMP0012
    • policy
  • CMP0013
    • policy
  • CMP0014
    • policy
  • CMP0015
    • policy, [1]
  • CMP0016
    • policy
  • CMP0017
    • policy, [1]
  • CMP0018
    • policy
  • CMP0019
    • policy
  • CMP0020
    • policy
  • CMP0021
    • policy
  • CMP0022
    • policy, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • CMP0023
    • policy
  • CMP0024
    • policy, [1]
  • CMP0025
    • policy, [1], [2]
  • CMP0026
    • policy, [1]
  • CMP0027
    • policy, [1]
  • CMP0028
    • policy, [1], [2], [3]
  • CMP0029
    • policy, [1], [2]
  • CMP0030
    • policy, [1], [2]
  • CMP0031
    • policy, [1], [2]
  • CMP0032
    • policy, [1], [2]
  • CMP0033
    • policy, [1], [2], [3]
  • CMP0034
    • policy, [1], [2]
  • CMP0035
    • policy, [1], [2]
  • CMP0036
    • policy, [1], [2]
  • CMP0037
    • policy, [1], [2]
  • CMP0038
    • policy, [1]
  • CMP0039
    • policy, [1]
  • CMP0040
    • policy, [1]
  • CMP0041
    • policy, [1], [2]
  • CMP0042
    • policy, [1], [2]
  • CMP0043
    • policy, [1], [2], [3], [4]
  • CMP0044
    • policy, [1]
  • CMP0045
    • policy, [1]
  • CMP0046
    • policy, [1]
  • CMP0047
    • policy, [1], [2]
  • CMP0048
    • policy, [1], [2]
  • CMP0049
    • policy, [1]
  • CMP0050
    • policy, [1]
  • CMP0051
    • policy, [1]
  • CMP0052
    • policy, [1]
  • CMP0053
    • policy, [1], [2], [3], [4], [5]
  • CMP0054
    • policy, [1], [2]
  • CMP0055
    • policy, [1]
  • CMP0056
    • policy, [1], [2], [3]
  • CMP0057
    • policy
  • CMP0058
    • policy, [1]
  • CMP0059
    • policy, [1], [2]
  • CMP0060
    • policy, [1], [2], [3], [4]
  • CMP0061
    • policy, [1], [2]
  • CMP0062
    • policy, [1]
  • CMP0063
    • policy, [1], [2], [3]
  • CMP0064
    • policy, [1]
  • CMP0065
    • policy, [1], [2], [3]
  • CMP0066
    • policy, [1], [2]
  • CMP0067
    • policy, [1], [2], [3]
  • CMP0068
    • policy, [1], [2], [3]
  • CMP0069
    • policy, [1], [2], [3]
  • CMP0070
    • policy, [1], [2], [3]
  • CMP0071
    • policy, [1], [2], [3], [4]
  • CMP0072
    • policy, [1], [2], [3]
  • CMP0073
    • policy, [1]
  • CMP0074
    • policy, [1], [2], [3], [4], [5], [6], [7], [8]
  • CMP0075
    • policy, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • CMP0076
    • policy, [1], [2]
  • CMP0077
    • policy, [1], [2]
  • CMP0078
    • policy, [1], [2]
  • CMP0079
    • policy, [1], [2]
  • CMP0080
    • policy, [1]
  • CMP0081
    • policy, [1]
  • CMP0082
    • policy, [1], [2]
  • CMP0083
    • policy, [1], [2], [3], [4], [5], [6]
  • CMP0084
    • policy, [1], [2]
  • CMP0085
    • policy, [1]
  • CMP0086
    • policy, [1], [2]
  • CMP0087
    • policy, [1]
  • CMP0088
    • policy, [1]
  • CodeBlocks
    • generator, [1], [2], [3]
  • CodeLite
    • generator, [1], [2], [3]
  • command
    • CHECK_CXX_SYMBOL_EXISTS
    • CHECK_FORTRAN_FUNCTION_EXISTS
    • CHECK_INCLUDE_FILE
    • CHECK_INCLUDE_FILES
    • CHECK_INCLUDE_FILE_CXX
    • CHECK_LIBRARY_EXISTS
    • CHECK_STRUCT_HAS_MEMBER
    • CHECK_TYPE_SIZE
    • CHECK_VARIABLE_EXISTS
    • ExternalData_Add_Target
    • ExternalData_Add_Test
    • ExternalData_Expand_Arguments
    • ExternalProject_Add
    • ExternalProject_Add_Step
    • ExternalProject_Add_StepDependencies
    • ExternalProject_Add_StepTargets
    • ExternalProject_Get_Property
    • FetchContent_Declare
    • FetchContent_GetProperties
    • FetchContent_MakeAvailable
    • FetchContent_Populate
    • FortranCInterface_HEADER
    • FortranCInterface_VERIFY
    • GNUInstallDirs_get_absolute_install_dir
    • add_compile_definitions, [1], [2], [3], [4], [5]
    • add_compile_options, [1], [2], [3], [4], [5]
    • add_custom_command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41]
    • add_custom_target, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28]
    • add_definitions, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • add_dependencies, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
    • add_executable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44]
    • add_feature_info, [1]
    • add_library, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56]
    • add_link_options, [1], [2], [3], [4], [5]
    • add_subdirectory, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22]
    • add_test, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • android_add_test_data
    • aux_source_directory
    • break, [1], [2], [3], [4], [5], [6], [7], [8]
    • build_command, [1], [2], [3], [4]
    • build_name, [1], [2]
    • cdash_coverage_collect_gcov
    • check_c_compiler_flag
    • check_c_source_compiles
    • check_c_source_runs
    • check_cxx_compiler_flag
    • check_cxx_source_compiles
    • check_cxx_source_runs
    • check_fortran_compiler_flag
    • check_fortran_source_compiles
    • check_fortran_source_runs, [1], [2]
    • check_function_exists
    • check_include_files
    • check_ipo_supported
    • check_pie_supported
    • check_prototype_definition
    • check_symbol_exists
    • cmake_host_system_information, [1]
    • cmake_minimum_required, [1], [2], [3], [4], [5], [6], [7], [8]
    • cmake_parse_arguments, [1], [2], [3]
    • cmake_policy, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43]
    • configure_file, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
    • configure_package_config_file, [1], [2], [3]
    • continue, [1], [2], [3], [4], [5]
    • cpack_add_component, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18]
    • cpack_add_component_group, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • cpack_add_install_type, [1]
    • cpack_configure_downloads, [1]
    • cpack_ifw_add_package_resources, [1], [2]
    • cpack_ifw_add_repository, [1], [2]
    • cpack_ifw_configure_component, [1], [2], [3], [4], [5], [6]
    • cpack_ifw_configure_component_group, [1], [2], [3], [4], [5], [6]
    • cpack_ifw_configure_file, [1]
    • cpack_ifw_update_repository, [1], [2]
    • create_test_sourcelist
    • csharp_get_dependentupon_name, [1]
    • csharp_get_filename_key_base, [1]
    • csharp_get_filename_keys, [1]
    • csharp_set_designer_cs_properties, [1], [2]
    • csharp_set_windows_forms_properties, [1]
    • csharp_set_xaml_cs_properties, [1]
    • ctest_build, [1], [2], [3], [4]
    • ctest_configure, [1], [2]
    • ctest_coverage, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • ctest_empty_binary_directory
    • ctest_memcheck, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • ctest_read_custom_files, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19]
    • ctest_run_script, [1]
    • ctest_sleep
    • ctest_start, [1], [2], [3], [4], [5], [6], [7], [8]
    • ctest_submit, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
    • ctest_test, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19]
    • ctest_update, [1], [2], [3], [4], [5]
    • ctest_upload, [1]
    • define_property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • doxygen_add_docs, [1], [2]
    • else, [1], [2]
    • elseif, [1]
    • enable_language, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
    • enable_testing, [1]
    • endforeach, [1], [2]
    • endfunction, [1], [2]
    • endif, [1], [2]
    • endmacro, [1], [2], [3]
    • endwhile, [1], [2], [3], [4]
    • exec_program, [1]
    • execute_process, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • export, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28]
    • export_library_dependencies, [1], [2], [3]
    • externalproject_add, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20]
    • externalproject_add_step, [1], [2], [3], [4]
    • externalproject_add_steptargets, [1]
    • externalproject_get_property, [1]
    • feature_summary, [1], [2], [3], [4]
    • fetchcontent_declare, [1], [2]
    • fetchcontent_getproperties, [1], [2]
    • fetchcontent_makeavailable, [1], [2], [3]
    • fetchcontent_populate, [1], [2], [3], [4]
    • file, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58]
    • find_dependency
    • find_file, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • find_library, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33]
    • find_package, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97], [98], [99], [100], [101], [102], [103], [104], [105], [106]
    • find_package_handle_standard_args
    • find_path, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • find_program, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • fltk_wrap_ui
    • foreach, [1], [2], [3], [4]
    • function, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
    • get_cmake_property, [1]
    • get_directory_property, [1]
    • get_filename_component, [1], [2], [3], [4]
    • get_property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
    • get_source_file_property, [1]
    • get_target_property, [1], [2], [3], [4]
    • get_test_property, [1]
    • gnuinstalldirs_get_absolute_install_dir
    • gtest_add_tests, [1], [2], [3], [4], [5]
    • gtest_discover_tests, [1], [2], [3], [4], [5], [6]
    • if, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31]
    • include, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
    • include_directories, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • include_external_msproject, [1], [2]
    • include_guard, [1], [2]
    • include_regular_expression, [1]
    • install, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97], [98], [99]
    • install_files, [1], [2], [3]
    • install_programs, [1], [2], [3]
    • install_targets, [1], [2], [3]
    • link_directories, [1], [2], [3], [4]
    • link_libraries, [1], [2]
    • list, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • load_cache
    • load_command, [1], [2]
    • macro, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • make_directory
    • mark_as_advanced
    • math, [1], [2]
    • matlab_add_mex, [1], [2], [3]
    • matlab_add_unit_test, [1], [2], [3]
    • matlab_extract_all_installed_versions_from_registry, [1]
    • matlab_get_all_valid_matlab_roots_from_registry, [1]
    • matlab_get_mex_suffix, [1]
    • matlab_get_release_name_from_version, [1], [2]
    • matlab_get_version_from_matlab_run, [1]
    • matlab_get_version_from_release_name, [1], [2]
    • message, [1], [2], [3]
    • option, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • output_required_files, [1], [2]
    • pkg_check_modules, [1], [2], [3], [4]
    • pkg_get_variable, [1], [2]
    • pkg_search_module, [1], [2]
    • print_disabled_features, [1]
    • print_enabled_features, [1]
    • project, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97]
    • protobuf_generate_cpp, [1], [2]
    • protobuf_generate_python, [1]
    • qt_wrap_cpp
    • qt_wrap_ui
    • remove
    • remove_definitions
    • return, [1], [2], [3], [4], [5]
    • separate_arguments, [1], [2], [3], [4], [5]
    • set, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
    • set_directory_properties, [1], [2], [3]
    • set_feature_info, [1]
    • set_package_info, [1]
    • set_package_properties, [1]
    • set_property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
    • set_source_files_properties, [1], [2]
    • set_target_properties, [1], [2], [3], [4], [5], [6]
    • set_tests_properties, [1]
    • site_name, [1]
    • source_group, [1], [2], [3], [4], [5], [6], [7], [8]
    • string, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21]
    • subdir_depends, [1], [2]
    • subdirs, [1], [2], [3]
    • swig_add_library, [1]
    • swig_link_libraries
    • target_compile_definitions, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • target_compile_features, [1], [2], [3], [4], [5], [6], [7]
    • target_compile_options, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • target_include_directories, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
    • target_link_directories, [1], [2], [3], [4], [5]
    • target_link_libraries, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77]
    • target_link_options, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • target_sources, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • try_compile, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47]
    • try_run, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19]
    • unset, [1], [2], [3], [4], [5], [6], [7]
    • use_mangled_mesa, [1], [2]
    • utility_source, [1], [2]
    • variable_requires, [1], [2]
    • variable_watch, [1], [2]
    • while, [1], [2], [3], [4], [5]
    • write_basic_package_version_file, [1], [2], [3], [4], [5]
    • write_file
    • xctest_add_bundle, [1]
    • xctest_add_test
  • COMMON_LANGUAGE_RUNTIME
    • target property, [1], [2]
  • COMPATIBLE_INTERFACE_BOOL
    • target property, [1], [2]
  • COMPATIBLE_INTERFACE_NUMBER_MAX
    • target property, [1], [2], [3]
  • COMPATIBLE_INTERFACE_NUMBER_MIN
    • target property, [1], [2], [3]
  • COMPATIBLE_INTERFACE_STRING
    • target property, [1], [2], [3], [4]
  • COMPILE_DEFINITIONS
    • directory property, [1], [2], [3], [4], [5], [6], [7], [8]
    • source file property, [1], [2], [3], [4], [5], [6], [7], [8]
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18]
  • COMPILE_DEFINITIONS_<CONFIG>
    • directory property, [1], [2], [3]
    • source file property
    • target property, [1], [2], [3], [4], [5], [6]
  • COMPILE_FEATURES
    • target property, [1], [2], [3], [4]
  • COMPILE_FLAGS
    • source file property, [1], [2], [3]
    • target property, [1]
  • COMPILE_OPTIONS
    • directory property, [1], [2]
    • source file property, [1], [2], [3], [4], [5]
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • COMPILE_PDB_NAME
    • target property, [1], [2], [3]
  • COMPILE_PDB_NAME_<CONFIG>
    • target property, [1]
  • COMPILE_PDB_OUTPUT_DIRECTORY
    • target property, [1], [2], [3], [4]
  • COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>
    • target property, [1], [2]
  • configure_file
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
  • configure_package_config_file
    • command, [1], [2], [3]
  • continue
    • command, [1], [2], [3], [4], [5]
  • COST
    • test property
  • CPack
    • module, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19]
  • CPack Archive Generator
    • cpack generator, [1], [2]
  • CPack Bundle Generator
    • cpack generator, [1]
  • CPack Cygwin Generator
    • cpack generator, [1]
  • CPack DEB Generator
    • cpack generator, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24]
  • CPack DragNDrop Generator
    • cpack generator, [1], [2], [3], [4]
  • CPack External Generator
    • cpack generator, [1]
  • CPack FreeBSD Generator
    • cpack generator, [1], [2]
  • cpack generator
    • CPack Archive Generator, [1], [2]
    • CPack Bundle Generator, [1]
    • CPack Cygwin Generator, [1]
    • CPack DEB Generator, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24]
    • CPack DragNDrop Generator, [1], [2], [3], [4]
    • CPack External Generator, [1]
    • CPack FreeBSD Generator, [1], [2]
    • CPack IFW Generator, [1], [2], [3], [4], [5], [6], [7], [8]
    • CPack NSIS Generator, [1], [2], [3]
    • CPack NuGet Generator, [1], [2]
    • CPack PackageMaker Generator, [1]
    • CPack RPM Generator, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24]
    • CPack WIX Generator, [1], [2], [3], [4], [5], [6], [7], [8]
    • CPack productbuild Generator, [1], [2], [3], [4]
  • CPack IFW Generator
    • cpack generator, [1], [2], [3], [4], [5], [6], [7], [8]
  • CPack NSIS Generator
    • cpack generator, [1], [2], [3]
  • CPack NuGet Generator
    • cpack generator, [1], [2]
  • CPack PackageMaker Generator
    • cpack generator, [1]
  • CPack productbuild Generator
    • cpack generator, [1], [2], [3], [4]
  • CPack RPM Generator
    • cpack generator, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24]
  • CPack WIX Generator
    • cpack generator, [1], [2], [3], [4], [5], [6], [7], [8]
  • cpack(1)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
  • cpack-generators(7)
    • manual, [1]
  • CPACK_<GENNAME>_COMPONENT_INSTALL
    • variable
  • CPACK_ABSOLUTE_DESTINATION_FILES
    • variable
  • cpack_add_component
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18]
  • cpack_add_component_group
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • cpack_add_install_type
    • command, [1]
  • CPACK_ARCHIVE_<component>_FILE_NAME
    • variable, [1]
  • CPACK_ARCHIVE_COMPONENT_INSTALL
    • variable
  • CPACK_ARCHIVE_FILE_NAME
    • variable, [1]
  • CPACK_BINARY_<GENNAME>
    • variable, [1]
  • CPACK_BUILD_SOURCE_DIRS
    • variable, [1], [2], [3]
  • CPACK_BUNDLE_APPLE_CERT_APP
    • variable
  • CPACK_BUNDLE_APPLE_CODESIGN_FILES
    • variable
  • CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER
    • variable
  • CPACK_BUNDLE_APPLE_ENTITLEMENTS
    • variable
  • CPACK_BUNDLE_ICON
    • variable
  • CPACK_BUNDLE_NAME
    • variable
  • CPACK_BUNDLE_PLIST
    • variable
  • CPACK_BUNDLE_STARTUP_COMMAND
    • variable
  • CPACK_CMAKE_GENERATOR
    • variable
  • CPACK_COMMAND_CODESIGN
    • variable
  • CPACK_COMMAND_HDIUTIL
    • variable
  • CPACK_COMMAND_PKGBUILD
    • variable
  • CPACK_COMMAND_PRODUCTBUILD
    • variable
  • CPACK_COMMAND_REZ
    • variable
  • CPACK_COMMAND_SETFILE
    • variable
  • CPACK_COMPONENT_<compName>_DEPENDS
    • variable, [1], [2]
  • CPACK_COMPONENT_<compName>_DESCRIPTION
    • variable, [1], [2]
  • CPACK_COMPONENT_<compName>_DISABLED
    • variable, [1]
  • CPACK_COMPONENT_<compName>_DISPLAY_NAME
    • variable, [1]
  • CPACK_COMPONENT_<compName>_GROUP
    • variable
  • CPACK_COMPONENT_<compName>_HIDDEN
    • variable
  • CPACK_COMPONENT_<compName>_REQUIRED
    • variable
  • CPACK_COMPONENT_<COMPONENT>_DESCRIPTION
    • variable
  • CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY
    • variable, [1]
  • CPACK_COMPONENTS_ALL
    • variable
  • CPACK_COMPONENTS_GROUPING
    • variable, [1]
  • cpack_configure_downloads
    • command, [1]
  • CPACK_CREATE_DESKTOP_LINKS
    • variable
  • CPACK_CYGWIN_BUILD_SCRIPT
    • variable
  • CPACK_CYGWIN_PATCH_FILE
    • variable
  • CPACK_CYGWIN_PATCH_NUMBER
    • variable
  • CPACK_DEB_COMPONENT_INSTALL
    • variable
  • CPACK_DEBIAN_<component>_DEBUGINFO_PACKAGE
    • variable
  • CPACK_DEBIAN_<COMPONENT>_FILE_NAME
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_EXTRA
    • variable
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_STRICT_PERMISSION
    • variable
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS
    • variable, [1], [2], [3]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_NAME
    • variable
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION
    • variable, [1]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS
    • variable, [1], [2]
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SOURCE
    • variable
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS
    • variable, [1]
  • CPACK_DEBIAN_ARCHIVE_TYPE
    • variable, [1], [2]
  • CPACK_DEBIAN_COMPRESSION_TYPE
    • variable, [1]
  • CPACK_DEBIAN_DEBUGINFO_PACKAGE
    • variable
  • CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS
    • variable, [1]
  • CPACK_DEBIAN_FILE_NAME
    • variable, [1], [2]
  • CPACK_DEBIAN_PACKAGE_ARCHITECTURE
    • variable
  • CPACK_DEBIAN_PACKAGE_BREAKS
    • variable, [1], [2]
  • CPACK_DEBIAN_PACKAGE_CONFLICTS
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
    • variable
  • CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_DEBUG
    • variable
  • CPACK_DEBIAN_PACKAGE_DEPENDS
    • variable, [1], [2], [3]
  • CPACK_DEBIAN_PACKAGE_DESCRIPTION
    • variable, [1], [2]
  • CPACK_DEBIAN_PACKAGE_ENHANCES
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_EPOCH
    • variable, [1], [2]
  • CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS
    • variable
  • CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_HOMEPAGE
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_MAINTAINER
    • variable
  • CPACK_DEBIAN_PACKAGE_NAME
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_PREDEPENDS
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_PRIORITY
    • variable
  • CPACK_DEBIAN_PACKAGE_PROVIDES
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_RECOMMENDS
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_RELEASE
    • variable, [1], [2], [3], [4]
  • CPACK_DEBIAN_PACKAGE_REPLACES
    • variable, [1]
  • CPACK_DEBIAN_PACKAGE_SECTION
    • variable
  • CPACK_DEBIAN_PACKAGE_SHLIBDEPS
    • variable, [1], [2], [3]
  • CPACK_DEBIAN_PACKAGE_SOURCE
    • variable, [1], [2]
  • CPACK_DEBIAN_PACKAGE_SUGGESTS
    • variable, [1], [2]
  • CPACK_DEBIAN_PACKAGE_VERSION
    • variable, [1]
  • CPACK_DESKTOP_SHORTCUTS
    • installed file property, [1]
  • CPACK_DMG_BACKGROUND_IMAGE
    • variable, [1]
  • CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK
    • variable, [1]
  • CPACK_DMG_DS_STORE
    • variable
  • CPACK_DMG_DS_STORE_SETUP_SCRIPT
    • variable, [1]
  • CPACK_DMG_FORMAT
    • variable
  • CPACK_DMG_SLA_DIR
    • variable, [1], [2]
  • CPACK_DMG_SLA_LANGUAGES
    • variable, [1]
  • CPACK_DMG_VOLUME_NAME
    • variable
  • CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
    • variable, [1]
  • CPACK_EXTERNAL_ENABLE_STAGING
    • variable, [1]
  • CPACK_EXTERNAL_PACKAGE_SCRIPT
    • variable, [1]
  • CPACK_EXTERNAL_REQUESTED_VERSIONS
    • variable, [1], [2]
  • CPACK_FREEBSD_PACKAGE_CATEGORIES
    • variable
  • CPACK_FREEBSD_PACKAGE_COMMENT
    • variable
  • CPACK_FREEBSD_PACKAGE_DEPS
    • variable
  • CPACK_FREEBSD_PACKAGE_DESCRIPTION
    • variable
  • CPACK_FREEBSD_PACKAGE_LICENSE
    • variable
  • CPACK_FREEBSD_PACKAGE_LICENSE_LOGIC
    • variable
  • CPACK_FREEBSD_PACKAGE_MAINTAINER
    • variable
  • CPACK_FREEBSD_PACKAGE_NAME
    • variable
  • CPACK_FREEBSD_PACKAGE_ORIGIN
    • variable
  • CPACK_FREEBSD_PACKAGE_WWW
    • variable
  • CPACK_GENERATOR
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • cpack_ifw_add_package_resources
    • command, [1], [2]
  • cpack_ifw_add_repository
    • command, [1], [2]
  • CPACK_IFW_ADMIN_TARGET_DIRECTORY
    • variable
  • CPACK_IFW_BINARYCREATOR_EXECUTABLE
    • variable
  • cpack_ifw_configure_component
    • command, [1], [2], [3], [4], [5], [6]
  • cpack_ifw_configure_component_group
    • command, [1], [2], [3], [4], [5], [6]
  • cpack_ifw_configure_file
    • command, [1]
  • CPACK_IFW_DEVTOOL_EXECUTABLE
    • variable
  • CPACK_IFW_DOWNLOAD_ALL
    • variable, [1]
  • CPACK_IFW_FRAMEWORK_VERSION
    • variable
  • CPACK_IFW_INSTALLERBASE_EXECUTABLE
    • variable
  • CPACK_IFW_PACKAGE_ALLOW_NON_ASCII_CHARACTERS
    • variable
  • CPACK_IFW_PACKAGE_ALLOW_SPACE_IN_PATH
    • variable
  • CPACK_IFW_PACKAGE_BACKGROUND
    • variable, [1]
  • CPACK_IFW_PACKAGE_BANNER
    • variable, [1]
  • CPACK_IFW_PACKAGE_CONTROL_SCRIPT
    • variable
  • CPACK_IFW_PACKAGE_FILE_EXTENSION
    • variable, [1]
  • CPACK_IFW_PACKAGE_GROUP
    • variable
  • CPACK_IFW_PACKAGE_ICON
    • variable
  • CPACK_IFW_PACKAGE_LOGO
    • variable
  • CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_INI_FILE
    • variable
  • CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_NAME
    • variable
  • CPACK_IFW_PACKAGE_NAME
    • variable, [1]
  • CPACK_IFW_PACKAGE_PUBLISHER
    • variable
  • CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR
    • variable, [1]
  • CPACK_IFW_PACKAGE_RESOURCES
    • variable, [1]
  • CPACK_IFW_PACKAGE_START_MENU_DIRECTORY
    • variable
  • CPACK_IFW_PACKAGE_TITLE
    • variable
  • CPACK_IFW_PACKAGE_TITLE_COLOR
    • variable, [1]
  • CPACK_IFW_PACKAGE_WATERMARK
    • variable, [1]
  • CPACK_IFW_PACKAGE_WINDOW_ICON
    • variable
  • CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT
    • variable, [1]
  • CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH
    • variable, [1]
  • CPACK_IFW_PACKAGE_WIZARD_STYLE
    • variable, [1]
  • CPACK_IFW_PACKAGES_DIRECTORIES
    • variable
  • CPACK_IFW_PRODUCT_URL
    • variable
  • CPACK_IFW_REPOGEN_EXECUTABLE
    • variable
  • CPACK_IFW_REPOSITORIES_ALL
    • variable, [1], [2]
  • CPACK_IFW_REPOSITORIES_DIRECTORIES
    • variable, [1]
  • CPACK_IFW_RESOLVE_DUPLICATE_NAMES
    • variable
  • CPACK_IFW_ROOT
    • variable, [1], [2]
  • CPACK_IFW_TARGET_DIRECTORY
    • variable
  • cpack_ifw_update_repository
    • command, [1], [2]
  • CPACK_IFW_VERBOSE
    • variable
  • CPACK_INCLUDE_TOPLEVEL_DIRECTORY
    • variable, [1], [2]
  • CPACK_INSTALL_CMAKE_PROJECTS
    • variable, [1], [2]
  • CPACK_INSTALL_COMMANDS
    • variable
  • CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
    • variable, [1], [2]
  • CPACK_INSTALL_SCRIPT
    • variable
  • CPACK_INSTALLED_DIRECTORIES
    • variable, [1]
  • CPACK_MONOLITHIC_INSTALL
    • variable
  • CPACK_NEVER_OVERWRITE
    • installed file property
  • CPACK_NSIS_<compName>_INSTALL_DIRECTORY
    • variable, [1]
  • CPACK_NSIS_COMPRESSOR
    • variable
  • CPACK_NSIS_CONTACT
    • variable
  • CPACK_NSIS_CREATE_ICONS_EXTRA
    • variable
  • CPACK_NSIS_DELETE_ICONS_EXTRA
    • variable
  • CPACK_NSIS_DISPLAY_NAME
    • variable
  • CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL
    • variable, [1]
  • CPACK_NSIS_EXECUTABLES_DIRECTORY
    • variable
  • CPACK_NSIS_EXTRA_INSTALL_COMMANDS
    • variable
  • CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS
    • variable
  • CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS
    • variable
  • CPACK_NSIS_HELP_LINK
    • variable
  • CPACK_NSIS_INSTALL_ROOT
    • variable
  • CPACK_NSIS_INSTALLED_ICON_NAME
    • variable
  • CPACK_NSIS_INSTALLER_MUI_ICON_CODE
    • variable
  • CPACK_NSIS_MENU_LINKS
    • variable
  • CPACK_NSIS_MODIFY_PATH
    • variable
  • CPACK_NSIS_MUI_FINISHPAGE_RUN
    • variable
  • CPACK_NSIS_MUI_ICON
    • variable
  • CPACK_NSIS_MUI_UNIICON
    • variable
  • CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP
    • variable, [1]
  • CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP
    • variable, [1]
  • CPACK_NSIS_PACKAGE_NAME
    • variable
  • CPACK_NSIS_URL_INFO_ABOUT
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_AUTHORS
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_COPYRIGHT
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES_<dependency>_VERSION
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_DESCRIPTION
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_DESCRIPTION_SUMMARY
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_HOMEPAGE_URL
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_ICONURL
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_LICENSEURL
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_NAME
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_OWNERS
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_RELEASE_NOTES
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_TAGS
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_TITLE
    • variable
  • CPACK_NUGET_<compName>_PACKAGE_VERSION
    • variable
  • CPACK_NUGET_COMPONENT_INSTALL
    • variable
  • CPACK_NUGET_PACKAGE_AUTHORS
    • variable
  • CPACK_NUGET_PACKAGE_COPYRIGHT
    • variable
  • CPACK_NUGET_PACKAGE_DEBUG
    • variable
  • CPACK_NUGET_PACKAGE_DEPENDENCIES
    • variable
  • CPACK_NUGET_PACKAGE_DEPENDENCIES_<dependency>_VERSION
    • variable
  • CPACK_NUGET_PACKAGE_DESCRIPTION
    • variable
  • CPACK_NUGET_PACKAGE_DESCRIPTION_SUMMARY
    • variable
  • CPACK_NUGET_PACKAGE_HOMEPAGE_URL
    • variable
  • CPACK_NUGET_PACKAGE_ICONURL
    • variable
  • CPACK_NUGET_PACKAGE_LICENSEURL
    • variable
  • CPACK_NUGET_PACKAGE_NAME
    • variable
  • CPACK_NUGET_PACKAGE_OWNERS
    • variable
  • CPACK_NUGET_PACKAGE_RELEASE_NOTES
    • variable
  • CPACK_NUGET_PACKAGE_TAGS
    • variable
  • CPACK_NUGET_PACKAGE_TITLE
    • variable
  • CPACK_NUGET_PACKAGE_VERSION
    • variable
  • CPACK_OSX_PACKAGE_VERSION
    • variable
  • CPACK_OUTPUT_CONFIG_FILE
    • variable
  • CPACK_PACKAGE_CHECKSUM
    • variable, [1]
  • CPACK_PACKAGE_DESCRIPTION
    • variable, [1], [2]
  • CPACK_PACKAGE_DESCRIPTION_FILE
    • variable, [1], [2], [3]
  • CPACK_PACKAGE_DESCRIPTION_SUMMARY
    • variable, [1], [2], [3], [4], [5], [6]
  • CPACK_PACKAGE_DIRECTORY
    • variable, [1]
  • CPACK_PACKAGE_EXECUTABLES
    • variable, [1]
  • CPACK_PACKAGE_FILE_NAME
    • variable
  • CPACK_PACKAGE_HOMEPAGE_URL
    • variable, [1]
  • CPACK_PACKAGE_ICON
    • variable
  • CPACK_PACKAGE_INSTALL_DIRECTORY
    • variable, [1]
  • CPACK_PACKAGE_INSTALL_REGISTRY_KEY
    • variable
  • CPACK_PACKAGE_NAME
    • variable, [1], [2], [3], [4], [5], [6]
  • CPACK_PACKAGE_VENDOR
    • variable, [1], [2], [3]
  • CPACK_PACKAGE_VERSION
    • variable, [1], [2], [3], [4], [5], [6], [7]
  • CPACK_PACKAGE_VERSION_MAJOR
    • variable, [1], [2]
  • CPACK_PACKAGE_VERSION_MINOR
    • variable, [1], [2]
  • CPACK_PACKAGE_VERSION_PATCH
    • variable, [1], [2]
  • CPACK_PACKAGING_INSTALL_PREFIX
    • variable, [1], [2], [3], [4], [5], [6]
  • CPACK_PERMANENT
    • installed file property
  • CPACK_PKGBUILD_IDENTITY_NAME
    • variable, [1]
  • CPACK_PKGBUILD_KEYCHAIN_PATH
    • variable, [1]
  • CPACK_POSTFLIGHT_<COMP>_SCRIPT
    • variable
  • CPACK_PREFLIGHT_<COMP>_SCRIPT
    • variable
  • CPACK_PRODUCTBUILD_IDENTITY_NAME
    • variable, [1]
  • CPACK_PRODUCTBUILD_KEYCHAIN_PATH
    • variable, [1]
  • CPACK_PRODUCTBUILD_RESOURCES_DIR
    • variable, [1]
  • CPACK_PROJECT_CONFIG_FILE
    • variable, [1], [2], [3], [4], [5], [6]
  • CPACK_RESOURCE_FILE_LICENSE
    • variable, [1]
  • CPACK_RESOURCE_FILE_README
    • variable, [1]
  • CPACK_RESOURCE_FILE_WELCOME
    • variable, [1]
  • CPACK_RPM_<compName>_DEFAULT_DIR_PERMISSIONS
    • variable
  • CPACK_RPM_<compName>_DEFAULT_FILE_PERMISSIONS
    • variable
  • CPACK_RPM_<compName>_DEFAULT_GROUP
    • variable
  • CPACK_RPM_<compName>_DEFAULT_USER
    • variable
  • CPACK_RPM_<component>_BUILD_SOURCE_DIRS_PREFIX
    • variable
  • CPACK_RPM_<component>_DEBUGINFO_FILE_NAME
    • variable
  • CPACK_RPM_<component>_DEBUGINFO_PACKAGE
    • variable, [1]
  • CPACK_RPM_<component>_FILE_NAME
    • variable
  • CPACK_RPM_<component>_PACKAGE_ARCHITECTURE
    • variable, [1]
  • CPACK_RPM_<component>_PACKAGE_AUTOPROV
    • variable
  • CPACK_RPM_<component>_PACKAGE_AUTOREQ
    • variable
  • CPACK_RPM_<component>_PACKAGE_AUTOREQPROV
    • variable
  • CPACK_RPM_<component>_PACKAGE_CONFLICTS
    • variable
  • CPACK_RPM_<component>_PACKAGE_DESCRIPTION
    • variable, [1]
  • CPACK_RPM_<component>_PACKAGE_GROUP
    • variable, [1]
  • CPACK_RPM_<component>_PACKAGE_NAME
    • variable, [1], [2]
  • CPACK_RPM_<component>_PACKAGE_OBSOLETES
    • variable
  • CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX
    • variable, [1], [2]
  • CPACK_RPM_<component>_PACKAGE_PROVIDES
    • variable
  • CPACK_RPM_<component>_PACKAGE_REQUIRES
    • variable
  • CPACK_RPM_<component>_PACKAGE_REQUIRES_POST
    • variable
  • CPACK_RPM_<component>_PACKAGE_REQUIRES_POSTUN
    • variable
  • CPACK_RPM_<component>_PACKAGE_REQUIRES_PRE
    • variable
  • CPACK_RPM_<component>_PACKAGE_REQUIRES_PREUN
    • variable
  • CPACK_RPM_<component>_PACKAGE_SUGGESTS
    • variable
  • CPACK_RPM_<component>_PACKAGE_SUMMARY
    • variable, [1]
  • CPACK_RPM_<component>_PACKAGE_URL
    • variable
  • CPACK_RPM_<COMPONENT>_USER_FILELIST
    • variable
  • CPACK_RPM_<componentName>_USER_BINARY_SPECFILE
    • variable
  • CPACK_RPM_ADDITIONAL_MAN_DIRS
    • variable, [1]
  • CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX
    • variable, [1]
  • CPACK_RPM_BUILDREQUIRES
    • variable
  • CPACK_RPM_CHANGELOG_FILE
    • variable
  • CPACK_RPM_COMPONENT_INSTALL
    • variable, [1], [2]
  • CPACK_RPM_COMPRESSION_TYPE
    • variable
  • CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS
    • variable, [1]
  • CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS_ADDITION
    • variable
  • CPACK_RPM_DEBUGINFO_FILE_NAME
    • variable, [1]
  • CPACK_RPM_DEBUGINFO_PACKAGE
    • variable, [1], [2], [3], [4]
  • CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE
    • variable, [1], [2]
  • CPACK_RPM_DEFAULT_DIR_PERMISSIONS
    • variable, [1]
  • CPACK_RPM_DEFAULT_FILE_PERMISSIONS
    • variable, [1], [2]
  • CPACK_RPM_DEFAULT_GROUP
    • variable, [1]
  • CPACK_RPM_DEFAULT_USER
    • variable, [1]
  • CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
    • variable, [1]
  • CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
    • variable, [1]
  • CPACK_RPM_FILE_NAME
    • variable, [1]
  • CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
    • variable
  • CPACK_RPM_INSTALL_WITH_EXEC
    • variable, [1]
  • CPACK_RPM_MAIN_COMPONENT
    • variable, [1], [2]
  • CPACK_RPM_NO_<COMPONENT>_INSTALL_PREFIX_RELOCATION
    • variable
  • CPACK_RPM_NO_INSTALL_PREFIX_RELOCATION
    • variable
  • CPACK_RPM_PACKAGE_ARCHITECTURE
    • variable
  • CPACK_RPM_PACKAGE_AUTOPROV
    • variable, [1]
  • CPACK_RPM_PACKAGE_AUTOREQ
    • variable, [1]
  • CPACK_RPM_PACKAGE_AUTOREQPROV
    • variable
  • CPACK_RPM_PACKAGE_CONFLICTS
    • variable
  • CPACK_RPM_PACKAGE_DEBUG
    • variable
  • CPACK_RPM_PACKAGE_DESCRIPTION
    • variable
  • CPACK_RPM_PACKAGE_EPOCH
    • variable, [1]
  • CPACK_RPM_PACKAGE_GROUP
    • variable
  • CPACK_RPM_PACKAGE_LICENSE
    • variable, [1]
  • CPACK_RPM_PACKAGE_NAME
    • variable, [1]
  • CPACK_RPM_PACKAGE_OBSOLETES
    • variable
  • CPACK_RPM_PACKAGE_PROVIDES
    • variable
  • CPACK_RPM_PACKAGE_RELEASE
    • variable
  • CPACK_RPM_PACKAGE_RELEASE_DIST
    • variable, [1], [2]
  • CPACK_RPM_PACKAGE_RELOCATABLE
    • variable
  • CPACK_RPM_PACKAGE_REQUIRES
    • variable
  • CPACK_RPM_PACKAGE_REQUIRES_POST
    • variable, [1]
  • CPACK_RPM_PACKAGE_REQUIRES_POSTUN
    • variable, [1]
  • CPACK_RPM_PACKAGE_REQUIRES_PRE
    • variable, [1]
  • CPACK_RPM_PACKAGE_REQUIRES_PREUN
    • variable, [1]
  • CPACK_RPM_PACKAGE_SOURCES
    • variable, [1], [2], [3]
  • CPACK_RPM_PACKAGE_SUGGESTS
    • variable
  • CPACK_RPM_PACKAGE_SUMMARY
    • variable
  • CPACK_RPM_PACKAGE_URL
    • variable
  • CPACK_RPM_PACKAGE_VENDOR
    • variable
  • CPACK_RPM_PACKAGE_VERSION
    • variable, [1]
  • CPACK_RPM_POST_INSTALL_SCRIPT_FILE
    • variable, [1]
  • CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE
    • variable
  • CPACK_RPM_PRE_INSTALL_SCRIPT_FILE
    • variable
  • CPACK_RPM_PRE_UNINSTALL_SCRIPT_FILE
    • variable
  • CPACK_RPM_RELOCATION_PATHS
    • variable, [1], [2]
  • CPACK_RPM_SOURCE_PKG_BUILD_PARAMS
    • variable, [1]
  • CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX
    • variable, [1]
  • CPACK_RPM_SPEC_INSTALL_POST
    • variable
  • CPACK_RPM_SPEC_MORE_DEFINE
    • variable, [1]
  • CPACK_RPM_USER_BINARY_SPECFILE
    • variable, [1]
  • CPACK_RPM_USER_FILELIST
    • variable, [1]
  • CPACK_SET_DESTDIR
    • variable, [1], [2], [3], [4]
  • CPACK_SOURCE_GENERATOR
    • variable
  • CPACK_SOURCE_IGNORE_FILES
    • variable
  • CPACK_SOURCE_OUTPUT_CONFIG_FILE
    • variable
  • CPACK_SOURCE_PACKAGE_FILE_NAME
    • variable
  • CPACK_SOURCE_STRIP_FILES
    • variable
  • CPACK_START_MENU_SHORTCUTS
    • installed file property, [1]
  • CPACK_STARTUP_SHORTCUTS
    • installed file property, [1]
  • CPACK_STRIP_FILES
    • variable, [1]
  • CPACK_SYSTEM_NAME
    • variable
  • CPACK_TOPLEVEL_TAG
    • variable
  • CPACK_VERBATIM_VARIABLES
    • variable
  • CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
    • variable, [1]
  • CPACK_WIX_<TOOL>_EXTENSIONS
    • variable
  • CPACK_WIX_<TOOL>_EXTRA_FLAGS
    • variable
  • CPACK_WIX_ACL
    • installed file property, [1]
  • CPACK_WIX_CMAKE_PACKAGE_REGISTRY
    • variable
  • CPACK_WIX_CULTURES
    • variable
  • CPACK_WIX_EXTENSIONS
    • variable
  • CPACK_WIX_EXTRA_OBJECTS
    • variable
  • CPACK_WIX_EXTRA_SOURCES
    • variable
  • CPACK_WIX_LICENSE_RTF
    • variable
  • CPACK_WIX_PATCH_FILE
    • variable, [1], [2]
  • CPACK_WIX_PRODUCT_GUID
    • variable
  • CPACK_WIX_PRODUCT_ICON
    • variable
  • CPACK_WIX_PROGRAM_MENU_FOLDER
    • variable
  • CPACK_WIX_PROPERTY_<PROPERTY>
    • variable
  • CPACK_WIX_ROOT
    • variable
  • CPACK_WIX_ROOT_FEATURE_DESCRIPTION
    • variable, [1]
  • CPACK_WIX_ROOT_FEATURE_TITLE
    • variable, [1]
  • CPACK_WIX_ROOT_FOLDER_ID
    • variable, [1]
  • CPACK_WIX_SKIP_PROGRAM_FOLDER
    • variable, [1]
  • CPACK_WIX_TEMPLATE
    • variable
  • CPACK_WIX_UI_BANNER
    • variable
  • CPACK_WIX_UI_DIALOG
    • variable
  • CPACK_WIX_UI_REF
    • variable
  • CPACK_WIX_UPGRADE_GUID
    • variable
  • CPackArchive
    • module
  • CPackBundle
    • module
  • CPackComponent
    • module, [1], [2]
  • CPackCygwin
    • module
  • CPackDeb
    • module
  • CPackDMG
    • module
  • CPackFreeBSD
    • module
  • CPackIFW
    • module, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • CPackIFWConfigureFile
    • module, [1]
  • CPackNSIS
    • module
  • CPackNuGet
    • module
  • CPackPackageMaker
    • module
  • CPackProductBuild
    • module, [1]
  • CPackRPM
    • module
  • CPackWIX
    • module
  • create_test_sourcelist
    • command
  • CROSSCOMPILING_EMULATOR
    • target property, [1], [2], [3], [4], [5], [6]
  • CSFLAGS
    • envvar
  • csharp_get_dependentupon_name
    • command, [1]
  • csharp_get_filename_key_base
    • command, [1]
  • csharp_get_filename_keys
    • command, [1]
  • csharp_set_designer_cs_properties
    • command, [1], [2]
  • csharp_set_windows_forms_properties
    • command, [1]
  • csharp_set_xaml_cs_properties
    • command, [1]
  • CSharpUtilities
    • module, [1]
  • CTest
    • module, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64]
  • ctest(1)
    • manual, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96]
  • CTEST_BINARY_DIRECTORY
    • variable, [1], [2], [3], [4], [5], [6], [7]
  • ctest_build
    • command, [1], [2], [3], [4]
  • CTEST_BUILD_COMMAND
    • variable, [1], [2], [3]
  • CTEST_BUILD_NAME
    • variable, [1]
  • CTEST_BZR_COMMAND
    • variable, [1]
  • CTEST_BZR_UPDATE_OPTIONS
    • variable, [1]
  • CTEST_CHANGE_ID
    • variable
  • CTEST_CHECKOUT_COMMAND
    • variable, [1], [2]
  • CTEST_CONFIGURATION_TYPE
    • variable, [1]
  • ctest_configure
    • command, [1], [2]
  • CTEST_CONFIGURE_COMMAND
    • variable, [1]
  • ctest_coverage
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • CTEST_COVERAGE_COMMAND
    • variable, [1], [2]
  • CTEST_COVERAGE_EXTRA_FLAGS
    • variable, [1]
  • CTEST_CURL_OPTIONS
    • variable, [1]
  • CTEST_CUSTOM_COVERAGE_EXCLUDE
    • variable
  • CTEST_CUSTOM_ERROR_EXCEPTION
    • variable
  • CTEST_CUSTOM_ERROR_MATCH
    • variable
  • CTEST_CUSTOM_ERROR_POST_CONTEXT
    • variable
  • CTEST_CUSTOM_ERROR_PRE_CONTEXT
    • variable
  • CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE
    • variable, [1]
  • CTEST_CUSTOM_MAXIMUM_NUMBER_OF_ERRORS
    • variable
  • CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS
    • variable
  • CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE
    • variable, [1]
  • CTEST_CUSTOM_MEMCHECK_IGNORE
    • variable
  • CTEST_CUSTOM_POST_MEMCHECK
    • variable
  • CTEST_CUSTOM_POST_TEST
    • variable
  • CTEST_CUSTOM_PRE_MEMCHECK
    • variable
  • CTEST_CUSTOM_PRE_TEST
    • variable
  • CTEST_CUSTOM_TESTS_IGNORE
    • variable
  • CTEST_CUSTOM_WARNING_EXCEPTION
    • variable
  • CTEST_CUSTOM_WARNING_MATCH
    • variable
  • CTEST_CVS_CHECKOUT
    • variable, [1]
  • CTEST_CVS_COMMAND
    • variable, [1]
  • CTEST_CVS_UPDATE_OPTIONS
    • variable, [1]
  • CTEST_DROP_LOCATION
    • variable, [1]
  • CTEST_DROP_METHOD
    • variable, [1]
  • CTEST_DROP_SITE
    • variable, [1]
  • CTEST_DROP_SITE_CDASH
    • variable, [1]
  • CTEST_DROP_SITE_PASSWORD
    • variable, [1]
  • CTEST_DROP_SITE_USER
    • variable, [1]
  • ctest_empty_binary_directory
    • command
  • CTEST_EXTRA_COVERAGE_GLOB
    • variable, [1]
  • CTEST_GIT_COMMAND
    • variable, [1]
  • CTEST_GIT_INIT_SUBMODULES
    • variable, [1], [2]
  • CTEST_GIT_UPDATE_CUSTOM
    • variable, [1]
  • CTEST_GIT_UPDATE_OPTIONS
    • variable, [1]
  • CTEST_HG_COMMAND
    • variable, [1]
  • CTEST_HG_UPDATE_OPTIONS
    • variable, [1]
  • CTEST_INTERACTIVE_DEBUG_MODE
    • envvar
  • CTEST_LABELS_FOR_SUBPROJECTS
    • variable, [1], [2], [3], [4]
  • ctest_memcheck
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • CTEST_MEMORYCHECK_COMMAND
    • variable, [1]
  • CTEST_MEMORYCHECK_COMMAND_OPTIONS
    • variable, [1]
  • CTEST_MEMORYCHECK_SANITIZER_OPTIONS
    • variable, [1], [2], [3]
  • CTEST_MEMORYCHECK_SUPPRESSIONS_FILE
    • variable, [1], [2]
  • CTEST_MEMORYCHECK_TYPE
    • variable, [1]
  • CTEST_NIGHTLY_START_TIME
    • variable, [1]
  • CTEST_OUTPUT_ON_FAILURE
    • envvar, [1]
  • CTEST_P4_CLIENT
    • variable, [1]
  • CTEST_P4_COMMAND
    • variable, [1]
  • CTEST_P4_OPTIONS
    • variable, [1]
  • CTEST_P4_UPDATE_OPTIONS
    • variable, [1]
  • CTEST_PARALLEL_LEVEL
    • envvar, [1]
  • CTEST_PROGRESS_OUTPUT
    • envvar, [1]
  • ctest_read_custom_files
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19]
  • CTEST_RUN_CURRENT_SCRIPT
    • variable, [1], [2]
  • ctest_run_script
    • command, [1]
  • CTEST_SCP_COMMAND
    • variable, [1]
  • CTEST_SITE
    • variable, [1]
  • ctest_sleep
    • command
  • CTEST_SOURCE_DIRECTORY
    • variable, [1], [2], [3], [4], [5]
  • ctest_start
    • command, [1], [2], [3], [4], [5], [6], [7], [8]
  • ctest_submit
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
  • CTEST_SUBMIT_URL
    • variable, [1], [2], [3]
  • CTEST_SVN_COMMAND
    • variable, [1]
  • CTEST_SVN_OPTIONS
    • variable, [1]
  • CTEST_SVN_UPDATE_OPTIONS
    • variable, [1]
  • ctest_test
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19]
  • CTEST_TEST_LOAD
    • variable, [1], [2], [3]
  • CTEST_TEST_TIMEOUT
    • variable, [1], [2], [3]
  • CTEST_TRIGGER_SITE
    • variable, [1]
  • ctest_update
    • command, [1], [2], [3], [4], [5]
  • CTEST_UPDATE_COMMAND
    • variable, [1]
  • CTEST_UPDATE_OPTIONS
    • variable, [1]
  • CTEST_UPDATE_VERSION_ONLY
    • variable, [1]
  • ctest_upload
    • command, [1]
  • CTEST_USE_LAUNCHERS
    • variable, [1], [2], [3]
  • CTEST_USE_LAUNCHERS_DEFAULT
    • envvar
  • CTestCoverageCollectGCOV
    • module, [1], [2]
  • CTestScriptMode
    • module
  • CTestUseLaunchers
    • module, [1]
  • CUDA_EXTENSIONS
    • target property, [1], [2], [3], [4]
  • CUDA_PTX_COMPILATION
    • target property, [1]
  • CUDA_RESOLVE_DEVICE_SYMBOLS
    • target property, [1]
  • CUDA_SEPARABLE_COMPILATION
    • target property, [1], [2]
  • CUDA_STANDARD
    • target property, [1], [2], [3], [4], [5], [6], [7], [8]
  • CUDA_STANDARD_REQUIRED
    • target property, [1], [2], [3], [4]
  • CUDACXX
    • envvar
  • CUDAFLAGS
    • envvar, [1]
  • CUDAHOSTCXX
    • envvar
  • CXX
    • envvar
  • CXX_EXTENSIONS
    • target property, [1], [2], [3], [4], [5], [6]
  • CXX_STANDARD
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • CXX_STANDARD_REQUIRED
    • target property, [1], [2], [3], [4]
  • CXXFLAGS
    • envvar, [1]
  • CYGWIN
    • variable, [1]

D

  • Dart
    • module
  • DASHBOARD_TEST_FROM_CTEST
    • envvar
  • DEBUG_CONFIGURATIONS
    • global property, [1], [2]
  • DEBUG_POSTFIX
    • target property
  • define_property
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • DEFINE_SYMBOL
    • target property, [1]
  • DEFINITIONS
    • directory property, [1], [2]
  • DEPENDS
    • test property, [1], [2], [3]
  • DEPLOYMENT_ADDITIONAL_FILES
    • target property, [1]
  • DEPLOYMENT_REMOTE_DIRECTORY
    • target property, [1]
  • DeployQt4
    • module
  • DESTDIR
    • envvar, [1], [2]
  • directory property
    • ADDITIONAL_MAKE_CLEAN_FILES, [1], [2]
    • BINARY_DIR, [1]
    • BUILDSYSTEM_TARGETS, [1]
    • CACHE_VARIABLES
    • CLEAN_NO_CUSTOM
    • CMAKE_CONFIGURE_DEPENDS, [1]
    • COMPILE_DEFINITIONS, [1], [2], [3], [4], [5], [6], [7], [8]
    • COMPILE_DEFINITIONS_<CONFIG>, [1], [2], [3]
    • COMPILE_OPTIONS, [1], [2]
    • DEFINITIONS, [1], [2]
    • EXCLUDE_FROM_ALL, [1], [2]
    • IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
    • INCLUDE_DIRECTORIES, [1], [2], [3], [4], [5], [6], [7], [8]
    • INCLUDE_REGULAR_EXPRESSION
    • INTERPROCEDURAL_OPTIMIZATION
    • INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
    • LABELS, [1], [2]
    • LINK_DIRECTORIES, [1], [2], [3], [4]
    • LINK_OPTIONS, [1], [2], [3], [4]
    • LISTFILE_STACK
    • MACROS, [1]
    • PARENT_DIRECTORY
    • RULE_LAUNCH_COMPILE
    • RULE_LAUNCH_CUSTOM
    • RULE_LAUNCH_LINK
    • SOURCE_DIR, [1]
    • SUBDIRECTORIES, [1]
    • TESTS, [1]
    • TEST_INCLUDE_FILE, [1]
    • TEST_INCLUDE_FILES, [1], [2], [3]
    • VARIABLES, [1]
    • VS_GLOBAL_SECTION_POST_<section>
    • VS_GLOBAL_SECTION_PRE_<section>
    • VS_STARTUP_PROJECT, [1]
  • DISABLED
    • test property, [1], [2]
  • DISABLED_FEATURES
    • global property
  • Documentation
    • module
  • DOTNET_TARGET_FRAMEWORK_VERSION
    • target property, [1], [2], [3], [4], [5]
  • doxygen_add_docs
    • command, [1], [2]
  • DOXYGEN_DOT_EXECUTABLE
    • variable
  • DOXYGEN_DOT_FOUND
    • variable
  • DOXYGEN_DOT_MULTI_TARGETS
    • variable
  • DOXYGEN_DOT_PATH
    • variable
  • DOXYGEN_EXCLUDE_PATTERNS
    • variable
  • DOXYGEN_EXECUTABLE
    • variable
  • DOXYGEN_FOUND
    • variable
  • DOXYGEN_GENERATE_LATEX
    • variable
  • DOXYGEN_HAVE_DOT
    • variable
  • DOXYGEN_INPUT
    • variable
  • DOXYGEN_OUTPUT_DIRECTORY
    • variable
  • DOXYGEN_PROJECT_BRIEF
    • variable
  • DOXYGEN_PROJECT_NAME
    • variable
  • DOXYGEN_PROJECT_NUMBER
    • variable
  • DOXYGEN_RECURSIVE
    • variable
  • DOXYGEN_SKIP_DOT
    • variable
  • DOXYGEN_VERSION
    • variable
  • DOXYGEN_WARN_FORMAT
    • variable

E

  • EchoString
    • target property
  • Eclipse CDT4
    • generator
  • ECLIPSE_EXTRA_CPROJECT_CONTENTS
    • global property, [1]
  • ECLIPSE_EXTRA_NATURES
    • global property, [1]
  • else
    • command, [1], [2]
  • elseif
    • command, [1]
  • ENABLE_EXPORTS
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
  • enable_language
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
  • enable_testing
    • command, [1]
  • ENABLED_FEATURES
    • global property
  • ENABLED_LANGUAGES
    • global property, [1]
  • endforeach
    • command, [1], [2]
  • endfunction
    • command, [1], [2]
  • endif
    • command, [1], [2]
  • endmacro
    • command, [1], [2], [3]
  • endwhile
    • command, [1], [2], [3], [4]
  • ENV
    • variable
  • ENVIRONMENT
    • test property
  • envvar
    • <PackageName>_ROOT, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • ASM<DIALECT>
    • ASM<DIALECT>FLAGS
    • CC
    • CFLAGS, [1]
    • CMAKE_BUILD_PARALLEL_LEVEL, [1]
    • CMAKE_CONFIG_TYPE, [1]
    • CMAKE_MSVCIDE_RUN_PATH
    • CMAKE_NO_VERBOSE, [1]
    • CMAKE_OSX_ARCHITECTURES
    • CSFLAGS
    • CTEST_INTERACTIVE_DEBUG_MODE
    • CTEST_OUTPUT_ON_FAILURE, [1]
    • CTEST_PARALLEL_LEVEL, [1]
    • CTEST_PROGRESS_OUTPUT, [1]
    • CTEST_USE_LAUNCHERS_DEFAULT
    • CUDACXX
    • CUDAFLAGS, [1]
    • CUDAHOSTCXX
    • CXX
    • CXXFLAGS, [1]
    • DASHBOARD_TEST_FROM_CTEST
    • DESTDIR, [1], [2]
    • FC
    • FFLAGS, [1]
    • LDFLAGS
    • MACOSX_DEPLOYMENT_TARGET
    • RC
    • RCFLAGS
    • VERBOSE, [1], [2]
  • EXCLUDE_FROM_ALL
    • directory property, [1], [2]
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • EXCLUDE_FROM_DEFAULT_BUILD
    • target property
  • EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>
    • target property
  • exec_program
    • command, [1]
  • EXECUTABLE_OUTPUT_PATH
    • variable
  • execute_process
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • export
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28]
  • export_library_dependencies
    • command, [1], [2], [3]
  • EXPORT_NAME
    • target property
  • EXPORT_PROPERTIES
    • target property, [1]
  • EXTERNAL_OBJECT
    • source file property
  • ExternalData
    • module, [1], [2], [3], [4], [5], [6], [7]
  • ExternalData_Add_Target
    • command
  • ExternalData_Add_Test
    • command
  • ExternalData_BINARY_ROOT
    • variable
  • ExternalData_CUSTOM_ERROR
    • variable
  • ExternalData_CUSTOM_FILE
    • variable
  • ExternalData_CUSTOM_LOCATION
    • variable
  • ExternalData_CUSTOM_SCRIPT_<key>
    • variable
  • ExternalData_Expand_Arguments
    • command
  • ExternalData_LINK_CONTENT
    • variable
  • ExternalData_NO_SYMLINKS
    • variable, [1]
  • ExternalData_OBJECT_STORES
    • variable
  • ExternalData_SERIES_MATCH
    • variable
  • ExternalData_SERIES_PARSE
    • variable
  • ExternalData_SERIES_PARSE_NUMBER
    • variable
  • ExternalData_SERIES_PARSE_PREFIX
    • variable
  • ExternalData_SERIES_PARSE_SUFFIX
    • variable
  • ExternalData_SOURCE_ROOT
    • variable
  • ExternalData_TIMEOUT_ABSOLUTE
    • variable
  • ExternalData_TIMEOUT_INACTIVITY
    • variable
  • ExternalData_URL_ALGO_<algo>_<key>
    • variable, [1]
  • ExternalData_URL_TEMPLATES
    • variable
  • ExternalProject
    • module, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33]
  • ExternalProject_Add
    • command
  • externalproject_add
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20]
  • ExternalProject_Add_Step
    • command
  • externalproject_add_step
    • command, [1], [2], [3], [4]
  • ExternalProject_Add_StepDependencies
    • command
  • ExternalProject_Add_StepTargets
    • command
  • externalproject_add_steptargets
    • command, [1]
  • ExternalProject_Get_Property
    • command
  • externalproject_get_property
    • command, [1]

F

  • FAIL_REGULAR_EXPRESSION
    • test property, [1]
  • FC
    • envvar
  • feature_summary
    • command, [1], [2], [3], [4]
  • FeatureSummary
    • module, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • FeatureSummary_<TYPE>_DESCRIPTION
    • variable, [1], [2]
  • FeatureSummary_DEFAULT_PKG_TYPE
    • variable, [1], [2], [3]
  • FeatureSummary_PKG_TYPES
    • variable, [1], [2], [3], [4], [5]
  • FeatureSummary_REQUIRED_PKG_TYPES
    • variable, [1], [2], [3], [4]
  • FetchContent
    • module, [1], [2]
  • FetchContent_Declare
    • command
  • fetchcontent_declare
    • command, [1], [2]
  • FetchContent_GetProperties
    • command
  • fetchcontent_getproperties
    • command, [1], [2]
  • FetchContent_MakeAvailable
    • command
  • fetchcontent_makeavailable
    • command, [1], [2], [3]
  • FetchContent_Populate
    • command
  • fetchcontent_populate
    • command, [1], [2], [3], [4]
  • FFLAGS
    • envvar, [1]
  • file
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58]
  • find_dependency
    • command
  • find_file
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • find_library
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33]
  • FIND_LIBRARY_USE_LIB32_PATHS
    • global property, [1], [2], [3], [4], [5]
  • FIND_LIBRARY_USE_LIB64_PATHS
    • global property, [1], [2], [3], [4]
  • FIND_LIBRARY_USE_LIBX32_PATHS
    • global property, [1], [2], [3], [4], [5]
  • FIND_LIBRARY_USE_OPENBSD_VERSIONING
    • global property
  • find_package
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97], [98], [99], [100], [101], [102], [103], [104], [105], [106]
  • find_package_handle_standard_args
    • command
  • find_path
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • find_program
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • FindALSA
    • module, [1]
  • FindArmadillo
    • module
  • FindASPELL
    • module
  • FindAVIFile
    • module
  • FindBacktrace
    • module, [1]
  • FindBISON
    • module, [1], [2], [3], [4], [5]
  • FindBLAS
    • module, [1], [2]
  • FindBoost
    • module, [1], [2], [3], [4], [5]
  • FindBullet
    • module
  • FindBZip2
    • module, [1]
  • FindCABLE
    • module
  • FindCoin3D
    • module
  • FindCUDA
    • module, [1], [2], [3], [4], [5]
  • FindCups
    • module
  • FindCURL
    • module, [1], [2], [3]
  • FindCurses
    • module, [1]
  • FindCVS
    • module
  • FindCxxTest
    • module
  • FindCygwin
    • module
  • FindDart
    • module
  • FindDCMTK
    • module
  • FindDevIL
    • module
  • FindDoxygen
    • module, [1], [2], [3]
  • FindEXPAT
    • module, [1]
  • FindFLEX
    • module, [1], [2]
  • FindFLTK
    • module
  • FindFLTK2
    • module
  • FindFontconfig
    • module, [1]
  • FindFreetype
    • module, [1]
  • FindGCCXML
    • module
  • FindGDAL
    • module, [1]
  • FindGettext
    • module, [1]
  • FindGIF
    • module, [1]
  • FindGit
    • module, [1], [2]
  • FindGLEW
    • module, [1]
  • FindGLUT
    • module, [1]
  • FindGnuplot
    • module
  • FindGnuTLS
    • module
  • FindGSL
    • module, [1]
  • FindGTest
    • module, [1], [2], [3], [4]
  • FindGTK
    • module
  • FindGTK2
    • module, [1], [2]
  • FindHDF5
    • module, [1]
  • FindHg
    • module, [1]
  • FindHSPELL
    • module
  • FindHTMLHelp
    • module
  • FindIce
    • module, [1], [2]
  • FindIconv
    • module, [1]
  • FindIcotool
    • module
  • FindICU
    • module, [1]
  • FindImageMagick
    • module
  • FindIntl
    • module, [1], [2]
  • FindITK
    • module, [1]
  • FindJasper
    • module
  • FindJava
    • module, [1], [2]
  • FindJNI
    • module, [1], [2]
  • FindJPEG
    • module, [1]
  • FindKDE3
    • module
  • FindKDE4
    • module
  • FindLAPACK
    • module, [1], [2]
  • FindLATEX
    • module, [1]
  • FindLibArchive
    • module
  • FindLibinput
    • module, [1]
  • FindLibLZMA
    • module, [1]
  • FindLibXml2
    • module, [1]
  • FindLibXslt
    • module
  • FindLTTngUST
    • module, [1]
  • FindLua
    • module, [1]
  • FindLua50
    • module
  • FindLua51
    • module
  • FindMatlab
    • module, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • FindMFC
    • module
  • FindMotif
    • module
  • FindMPEG
    • module
  • FindMPEG2
    • module
  • FindMPI
    • module, [1], [2], [3]
  • FindODBC
    • module, [1]
  • FindOpenACC
    • module, [1]
  • FindOpenAL
    • module
  • FindOpenCL
    • module, [1], [2]
  • FindOpenGL
    • module, [1], [2], [3], [4], [5], [6]
  • FindOpenMP
    • module, [1], [2], [3], [4]
  • FindOpenSceneGraph
    • module
  • FindOpenSSL
    • module, [1], [2], [3], [4]
  • FindOpenThreads
    • module
  • Findosg
    • module
  • Findosg_functions
    • module
  • FindosgAnimation
    • module
  • FindosgDB
    • module
  • FindosgFX
    • module
  • FindosgGA
    • module
  • FindosgIntrospection
    • module
  • FindosgManipulator
    • module
  • FindosgParticle
    • module
  • FindosgPresentation
    • module
  • FindosgProducer
    • module
  • FindosgQt
    • module
  • FindosgShadow
    • module
  • FindosgSim
    • module
  • FindosgTerrain
    • module
  • FindosgText
    • module
  • FindosgUtil
    • module
  • FindosgViewer
    • module
  • FindosgVolume
    • module
  • FindosgWidget
    • module
  • FindPackageHandleStandardArgs
    • module, [1], [2], [3]
  • FindPackageMessage
    • module
  • FindPatch
    • module, [1]
  • FindPerl
    • module
  • FindPerlLibs
    • module
  • FindPHP4
    • module
  • FindPhysFS
    • module
  • FindPike
    • module
  • FindPkgConfig
    • module, [1], [2], [3], [4], [5], [6], [7], [8]
  • FindPNG
    • module, [1]
  • FindPostgreSQL
    • module, [1]
  • FindProducer
    • module
  • FindProtobuf
    • module, [1], [2], [3], [4], [5], [6], [7]
  • FindPython
    • module, [1], [2], [3], [4], [5], [6], [7], [8]
  • FindPython2
    • module, [1], [2], [3], [4], [5], [6], [7], [8]
  • FindPython3
    • module, [1], [2], [3], [4], [5], [6], [7], [8]
  • FindPythonInterp
    • module
  • FindPythonLibs
    • module
  • FindQt
    • module, [1], [2], [3], [4], [5], [6]
  • FindQt3
    • module
  • FindQt4
    • module, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • FindQuickTime
    • module
  • FindRTI
    • module
  • FindRuby
    • module, [1]
  • FindSDL
    • module
  • FindSDL_image
    • module
  • FindSDL_mixer
    • module
  • FindSDL_net
    • module
  • FindSDL_sound
    • module
  • FindSDL_ttf
    • module
  • FindSelfPackers
    • module
  • FindSQLite3
    • module, [1]
  • FindSquish
    • module
  • FindSubversion
    • module, [1]
  • FindSWIG
    • module, [1]
  • FindTCL
    • module
  • FindTclsh
    • module
  • FindTclStub
    • module
  • FindThreads
    • module, [1]
  • FindTIFF
    • module, [1], [2]
  • FindUnixCommands
    • module
  • FindVTK
    • module, [1]
  • FindVulkan
    • module, [1]
  • FindWget
    • module
  • FindWish
    • module
  • FindwxWidgets
    • module, [1], [2]
  • FindwxWindows
    • module
  • FindX11
    • module, [1], [2], [3], [4]
  • FindXalanC
    • module, [1]
  • FindXCTest
    • module, [1], [2]
  • FindXercesC
    • module, [1], [2], [3]
  • FindXMLRPC
    • module
  • FindZLIB
    • module, [1], [2]
  • FIXTURES_CLEANUP
    • test property, [1], [2]
  • FIXTURES_REQUIRED
    • test property, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • FIXTURES_SETUP
    • test property, [1], [2], [3]
  • fltk_wrap_ui
    • command
  • FOLDER
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • foreach
    • command, [1], [2], [3], [4]
  • Fortran_FORMAT
    • source file property
    • target property, [1]
  • Fortran_MODULE_DIRECTORY
    • target property, [1], [2], [3]
  • FortranCInterface
    • module
  • FortranCInterface_HEADER
    • command
  • FortranCInterface_VERIFY
    • command
  • FRAMEWORK
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
  • FRAMEWORK_VERSION
    • target property, [1]
  • function
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]

G

  • GENERATED
    • source file property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20]
  • GenerateExportHeader
    • module, [1], [2], [3], [4]
  • generator
    • Borland Makefiles
    • CodeBlocks, [1], [2], [3]
    • CodeLite, [1], [2], [3]
    • Eclipse CDT4
    • Green Hills MULTI, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • Kate, [1]
    • MSYS Makefiles, [1], [2]
    • MinGW Makefiles, [1], [2], [3], [4], [5], [6]
    • NMake Makefiles, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • NMake Makefiles JOM, [1], [2]
    • Ninja, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56]
    • Sublime Text 2, [1], [2], [3], [4]
    • Unix Makefiles, [1], [2], [3], [4], [5], [6], [7]
    • Visual Studio 10 2010, [1], [2], [3], [4]
    • Visual Studio 11 2012, [1]
    • Visual Studio 12 2013, [1]
    • Visual Studio 14 2015, [1], [2], [3], [4], [5]
    • Visual Studio 15 2017, [1], [2], [3], [4]
    • Visual Studio 16 2019, [1]
    • Visual Studio 6, [1], [2]
    • Visual Studio 7, [1], [2]
    • Visual Studio 7 .NET 2003, [1], [2]
    • Visual Studio 8 2005, [1], [2], [3]
    • Visual Studio 9 2008, [1], [2], [3], [4], [5], [6], [7], [8]
    • Watcom WMake
    • Xcode, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37]
  • GENERATOR_FILE_NAME
    • target property
  • GENERATOR_IS_MULTI_CONFIG
    • global property, [1], [2], [3], [4], [5]
  • get_cmake_property
    • command, [1]
  • get_directory_property
    • command, [1]
  • get_filename_component
    • command, [1], [2], [3], [4]
  • get_property
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
  • get_source_file_property
    • command, [1]
  • get_target_property
    • command, [1], [2], [3], [4]
  • get_test_property
    • command, [1]
  • GetPrerequisites
    • module
  • GHS-MULTI
    • variable
  • GHS_INTEGRITY_APP
    • target property, [1], [2]
  • GHS_NO_SOURCE_GROUP_FILE
    • target property, [1], [2], [3]
  • global property
    • ALLOW_DUPLICATE_CUSTOM_TARGETS
    • AUTOGEN_SOURCE_GROUP, [1], [2], [3], [4], [5], [6], [7]
    • AUTOGEN_TARGETS_FOLDER, [1], [2], [3], [4]
    • AUTOMOC_SOURCE_GROUP, [1], [2], [3]
    • AUTOMOC_TARGETS_FOLDER
    • AUTORCC_SOURCE_GROUP, [1], [2], [3]
    • CMAKE_CXX_KNOWN_FEATURES, [1], [2], [3], [4], [5], [6]
    • CMAKE_C_KNOWN_FEATURES, [1], [2], [3], [4], [5]
    • CMAKE_ROLE, [1], [2], [3], [4], [5], [6], [7], [8]
    • DEBUG_CONFIGURATIONS, [1], [2]
    • DISABLED_FEATURES
    • ECLIPSE_EXTRA_CPROJECT_CONTENTS, [1]
    • ECLIPSE_EXTRA_NATURES, [1]
    • ENABLED_FEATURES
    • ENABLED_LANGUAGES, [1]
    • FIND_LIBRARY_USE_LIB32_PATHS, [1], [2], [3], [4], [5]
    • FIND_LIBRARY_USE_LIB64_PATHS, [1], [2], [3], [4]
    • FIND_LIBRARY_USE_LIBX32_PATHS, [1], [2], [3], [4], [5]
    • FIND_LIBRARY_USE_OPENBSD_VERSIONING
    • GENERATOR_IS_MULTI_CONFIG, [1], [2], [3], [4], [5]
    • GLOBAL_DEPENDS_DEBUG_MODE
    • GLOBAL_DEPENDS_NO_CYCLES
    • IN_TRY_COMPILE
    • JOB_POOLS, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • PACKAGES_FOUND
    • PACKAGES_NOT_FOUND
    • PREDEFINED_TARGETS_FOLDER
    • REPORT_UNDEFINED_PROPERTIES
    • RULE_LAUNCH_COMPILE
    • RULE_LAUNCH_CUSTOM
    • RULE_LAUNCH_LINK
    • RULE_MESSAGES, [1], [2]
    • TARGET_ARCHIVES_MAY_BE_SHARED_LIBS
    • TARGET_MESSAGES, [1]
    • TARGET_SUPPORTS_SHARED_LIBS
    • USE_FOLDERS
    • XCODE_EMIT_EFFECTIVE_PLATFORM_NAME, [1]
  • GLOBAL_DEPENDS_DEBUG_MODE
    • global property
  • GLOBAL_DEPENDS_NO_CYCLES
    • global property
  • GNUInstallDirs
    • module, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • GNUInstallDirs_get_absolute_install_dir
    • command
  • gnuinstalldirs_get_absolute_install_dir
    • command
  • GNUtoMS
    • target property, [1]
  • GoogleTest
    • module, [1], [2], [3], [4]
  • GRAPHVIZ_EXECUTABLES
    • variable
  • GRAPHVIZ_EXTERNAL_LIBS
    • variable
  • GRAPHVIZ_GENERATE_DEPENDERS
    • variable
  • GRAPHVIZ_GENERATE_PER_TARGET
    • variable
  • GRAPHVIZ_GRAPH_HEADER
    • variable
  • GRAPHVIZ_GRAPH_NAME
    • variable
  • GRAPHVIZ_GRAPH_TYPE
    • variable
  • GRAPHVIZ_IGNORE_TARGETS
    • variable
  • GRAPHVIZ_MODULE_LIBS
    • variable
  • GRAPHVIZ_NODE_PREFIX
    • variable
  • GRAPHVIZ_SHARED_LIBS
    • variable
  • GRAPHVIZ_STATIC_LIBS
    • variable
  • Green Hills MULTI
    • generator, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • gtest_add_tests
    • command, [1], [2], [3], [4], [5]
  • gtest_discover_tests
    • command, [1], [2], [3], [4], [5], [6]

H

  • HAS_CXX
    • target property
  • HEADER_FILE_ONLY
    • source file property, [1], [2]
  • HELPSTRING
    • cache property

I

  • Iconv::Iconv
    • variable
  • Iconv_FOUND
    • variable
  • Iconv_INCLUDE_DIR
    • variable
  • Iconv_INCLUDE_DIRS
    • variable
  • Iconv_IS_BUILT_IN
    • variable
  • Iconv_LIBRARIES
    • variable
  • Iconv_LIBRARY
    • variable
  • if
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31]
  • IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
    • directory property
    • target property
  • IMPORT_PREFIX
    • target property
  • IMPORT_SUFFIX
    • target property
  • IMPORTED
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64]
  • IMPORTED_COMMON_LANGUAGE_RUNTIME
    • target property, [1], [2]
  • IMPORTED_CONFIGURATIONS
    • target property, [1]
  • IMPORTED_GLOBAL
    • target property, [1]
  • IMPORTED_IMPLIB
    • target property
  • IMPORTED_IMPLIB_<CONFIG>
    • target property
  • IMPORTED_LIBNAME
    • target property, [1], [2]
  • IMPORTED_LIBNAME_<CONFIG>
    • target property, [1]
  • IMPORTED_LINK_DEPENDENT_LIBRARIES
    • target property
  • IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG>
    • target property
  • IMPORTED_LINK_INTERFACE_LANGUAGES
    • target property
  • IMPORTED_LINK_INTERFACE_LANGUAGES_<CONFIG>
    • target property
  • IMPORTED_LINK_INTERFACE_LIBRARIES
    • target property
  • IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG>
    • target property
  • IMPORTED_LINK_INTERFACE_MULTIPLICITY
    • target property
  • IMPORTED_LINK_INTERFACE_MULTIPLICITY_<CONFIG>
    • target property
  • IMPORTED_LOCATION
    • target property, [1], [2], [3], [4], [5], [6], [7], [8]
  • IMPORTED_LOCATION_<CONFIG>
    • target property, [1], [2], [3]
  • IMPORTED_NO_SONAME
    • target property, [1]
  • IMPORTED_NO_SONAME_<CONFIG>
    • target property
  • IMPORTED_OBJECTS
    • target property, [1], [2]
  • IMPORTED_OBJECTS_<CONFIG>
    • target property, [1], [2]
  • IMPORTED_SONAME
    • target property
  • IMPORTED_SONAME_<CONFIG>
    • target property
  • IN_TRY_COMPILE
    • global property
  • include
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
  • INCLUDE_DIRECTORIES
    • directory property, [1], [2], [3], [4], [5], [6], [7], [8]
    • source file property, [1], [2], [3], [4], [5], [6]
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30]
  • include_directories
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • include_external_msproject
    • command, [1], [2]
  • include_guard
    • command, [1], [2]
  • INCLUDE_REGULAR_EXPRESSION
    • directory property
  • include_regular_expression
    • command, [1]
  • install
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97], [98], [99]
  • install_files
    • command, [1], [2], [3]
  • INSTALL_NAME_DIR
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • install_programs
    • command, [1], [2], [3]
  • INSTALL_RPATH
    • target property, [1], [2], [3], [4], [5], [6]
  • INSTALL_RPATH_USE_LINK_PATH
    • target property, [1]
  • install_targets
    • command, [1], [2], [3]
  • installed file property
    • CPACK_DESKTOP_SHORTCUTS, [1]
    • CPACK_NEVER_OVERWRITE
    • CPACK_PERMANENT
    • CPACK_STARTUP_SHORTCUTS, [1]
    • CPACK_START_MENU_SHORTCUTS, [1]
    • CPACK_WIX_ACL, [1]
  • InstallRequiredSystemLibraries
    • module, [1], [2], [3], [4]
  • INTERFACE_AUTOUIC_OPTIONS
    • target property, [1], [2]
  • INTERFACE_COMPILE_DEFINITIONS
    • target property, [1], [2], [3], [4], [5], [6], [7]
  • INTERFACE_COMPILE_FEATURES
    • target property, [1], [2]
  • INTERFACE_COMPILE_OPTIONS
    • target property, [1], [2], [3], [4], [5], [6], [7]
  • INTERFACE_INCLUDE_DIRECTORIES
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30]
  • INTERFACE_LINK_DEPENDS
    • target property, [1]
  • INTERFACE_LINK_DIRECTORIES
    • target property, [1], [2]
  • INTERFACE_LINK_LIBRARIES
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23]
  • INTERFACE_LINK_OPTIONS
    • target property, [1], [2]
  • INTERFACE_POSITION_INDEPENDENT_CODE
    • target property, [1], [2], [3], [4], [5]
  • INTERFACE_SOURCES
    • target property, [1], [2], [3], [4], [5], [6]
  • INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
    • target property, [1], [2]
  • INTERPROCEDURAL_OPTIMIZATION
    • directory property
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
  • INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
    • directory property
    • target property, [1], [2]
  • IOS
    • variable
  • IOS_INSTALL_COMBINED
    • target property, [1], [2], [3]

J

  • JOB_POOL_COMPILE
    • target property, [1], [2], [3]
  • JOB_POOL_LINK
    • target property, [1], [2], [3]
  • JOB_POOLS
    • global property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]

K

  • Kate
    • generator, [1]
  • KEEP_EXTENSION
    • source file property

L

  • LABELS
    • directory property, [1], [2]
    • source file property, [1]
    • target property, [1]
    • test property, [1]
  • LANGUAGE
    • source file property, [1], [2]
  • LDFLAGS
    • envvar
  • LIBRARY_OUTPUT_DIRECTORY
    • target property, [1], [2], [3], [4], [5], [6]
  • LIBRARY_OUTPUT_DIRECTORY_<CONFIG>
    • target property, [1], [2]
  • LIBRARY_OUTPUT_NAME
    • target property, [1], [2], [3]
  • LIBRARY_OUTPUT_NAME_<CONFIG>
    • target property, [1], [2]
  • LIBRARY_OUTPUT_PATH
    • variable
  • LINK_DEPENDS
    • target property, [1]
  • LINK_DEPENDS_NO_SHARED
    • target property, [1]
  • LINK_DIRECTORIES
    • directory property, [1], [2], [3], [4]
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • link_directories
    • command, [1], [2], [3], [4]
  • LINK_FLAGS
    • target property, [1], [2], [3]
  • LINK_FLAGS_<CONFIG>
    • target property, [1]
  • LINK_INTERFACE_LIBRARIES
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • LINK_INTERFACE_LIBRARIES_<CONFIG>
    • target property, [1], [2]
  • LINK_INTERFACE_MULTIPLICITY
    • target property, [1]
  • LINK_INTERFACE_MULTIPLICITY_<CONFIG>
    • target property
  • LINK_LIBRARIES
    • target property, [1], [2], [3], [4], [5]
  • link_libraries
    • command, [1], [2]
  • LINK_OPTIONS
    • directory property, [1], [2], [3], [4]
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
  • LINK_SEARCH_END_STATIC
    • target property, [1], [2], [3]
  • LINK_SEARCH_START_STATIC
    • target property, [1], [2]
  • LINK_WHAT_YOU_USE
    • target property, [1], [2]
  • LINKER_LANGUAGE
    • target property, [1], [2]
  • list
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • LISTFILE_STACK
    • directory property
  • load_cache
    • command
  • load_command
    • command, [1], [2]
  • LOCATION
    • source file property, [1]
    • target property, [1], [2], [3]
  • LOCATION_<CONFIG>
    • target property

M

  • MACOSX_BUNDLE
    • target property, [1], [2], [3], [4], [5], [6], [7]
  • MACOSX_BUNDLE_INFO_PLIST
    • target property, [1]
  • MACOSX_DEPLOYMENT_TARGET
    • envvar
  • MACOSX_FRAMEWORK_INFO_PLIST
    • target property, [1]
  • MACOSX_PACKAGE_LOCATION
    • source file property
  • MACOSX_RPATH
    • target property, [1], [2], [3], [4]
  • macro
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • MacroAddFileDependencies
    • module
  • MACROS
    • directory property, [1]
  • make_directory
    • command
  • manual
    • ccmake(1), [1], [2], [3], [4], [5], [6], [7]
    • cmake(1), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93]
    • cmake-buildsystem(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50]
    • cmake-commands(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • cmake-compile-features(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40]
    • cmake-developer(7), [1], [2]
    • cmake-env-variables(7), [1], [2], [3]
    • cmake-file-api(7), [1]
    • cmake-generator-expressions(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97], [98], [99], [100], [101], [102], [103], [104], [105], [106], [107], [108], [109], [110], [111], [112], [113], [114], [115], [116], [117], [118], [119], [120], [121], [122], [123], [124], [125], [126], [127], [128], [129], [130], [131], [132], [133], [134], [135], [136], [137], [138], [139], [140], [141], [142], [143], [144], [145]
    • cmake-generators(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • cmake-gui(1), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22]
    • cmake-language(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • cmake-modules(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • cmake-packages(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
    • cmake-policies(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97], [98], [99], [100], [101], [102], [103], [104], [105], [106]
    • cmake-properties(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • cmake-qt(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25]
    • cmake-server(7), [1], [2], [3], [4], [5], [6]
    • cmake-toolchains(7), [1]
    • cmake-variables(7), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • cpack(1), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
    • cpack-generators(7), [1]
    • ctest(1), [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96]
  • MANUALLY_ADDED_DEPENDENCIES
    • target property, [1]
  • MAP_IMPORTED_CONFIG_<CONFIG>
    • target property, [1], [2], [3], [4], [5], [6], [7], [8]
  • mark_as_advanced
    • command
  • math
    • command, [1], [2]
  • matlab_add_mex
    • command, [1], [2], [3]
  • matlab_add_unit_test
    • command, [1], [2], [3]
  • MATLAB_ADDITIONAL_VERSIONS
    • variable, [1], [2]
  • matlab_extract_all_installed_versions_from_registry
    • command, [1]
  • MATLAB_FIND_DEBUG
    • variable, [1], [2]
  • matlab_get_all_valid_matlab_roots_from_registry
    • command, [1]
  • matlab_get_mex_suffix
    • command, [1]
  • matlab_get_release_name_from_version
    • command, [1], [2]
  • matlab_get_version_from_matlab_run
    • command, [1]
  • matlab_get_version_from_release_name
    • command, [1], [2]
  • Matlab_ROOT_DIR
    • variable, [1], [2], [3]
  • MEASUREMENT
    • test property
  • message
    • command, [1], [2], [3]
  • MINGW
    • variable
  • MinGW Makefiles
    • generator, [1], [2], [3], [4], [5], [6]
  • MODIFIED
    • cache property
  • module
    • AddFileDependencies
    • AndroidTestUtilities, [1]
    • BundleUtilities, [1], [2], [3], [4], [5], [6]
    • CMakeAddFortranSubdirectory
    • CMakeBackwardCompatibilityCXX
    • CMakeDependentOption, [1]
    • CMakeDetermineVSServicePack, [1]
    • CMakeExpandImportedTargets, [1]
    • CMakeFindDependencyMacro, [1], [2], [3]
    • CMakeFindFrameworks
    • CMakeFindPackageMode
    • CMakeForceCompiler, [1]
    • CMakeGraphVizOptions, [1], [2]
    • CMakePackageConfigHelpers, [1], [2], [3], [4], [5], [6]
    • CMakeParseArguments, [1]
    • CMakePrintHelpers
    • CMakePrintSystemInformation
    • CMakePushCheckState, [1]
    • CMakeVerifyManifest
    • CPack, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19]
    • CPackArchive
    • CPackBundle
    • CPackComponent, [1], [2]
    • CPackCygwin
    • CPackDMG
    • CPackDeb
    • CPackFreeBSD
    • CPackIFW, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • CPackIFWConfigureFile, [1]
    • CPackNSIS
    • CPackNuGet
    • CPackPackageMaker
    • CPackProductBuild, [1]
    • CPackRPM
    • CPackWIX
    • CSharpUtilities, [1]
    • CTest, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64]
    • CTestCoverageCollectGCOV, [1], [2]
    • CTestScriptMode
    • CTestUseLaunchers, [1]
    • CheckCCompilerFlag, [1]
    • CheckCSourceCompiles, [1], [2], [3], [4]
    • CheckCSourceRuns
    • CheckCXXCompilerFlag, [1]
    • CheckCXXSourceCompiles, [1], [2]
    • CheckCXXSourceRuns
    • CheckCXXSymbolExists, [1], [2]
    • CheckFortranCompilerFlag, [1]
    • CheckFortranFunctionExists
    • CheckFortranSourceCompiles, [1], [2], [3]
    • CheckFortranSourceRuns, [1]
    • CheckFunctionExists, [1]
    • CheckIPOSupported, [1], [2], [3], [4], [5], [6]
    • CheckIncludeFile, [1], [2], [3], [4], [5], [6]
    • CheckIncludeFileCXX, [1], [2], [3], [4], [5]
    • CheckIncludeFiles, [1], [2], [3], [4], [5], [6]
    • CheckLanguage, [1]
    • CheckLibraryExists, [1]
    • CheckPIESupported, [1], [2], [3], [4], [5]
    • CheckPrototypeDefinition
    • CheckStructHasMember, [1]
    • CheckSymbolExists, [1], [2]
    • CheckTypeSize, [1], [2], [3], [4]
    • CheckVariableExists
    • Dart
    • DeployQt4
    • Documentation
    • ExternalData, [1], [2], [3], [4], [5], [6], [7]
    • ExternalProject, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33]
    • FeatureSummary, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • FetchContent, [1], [2]
    • FindALSA, [1]
    • FindASPELL
    • FindAVIFile
    • FindArmadillo
    • FindBISON, [1], [2], [3], [4], [5]
    • FindBLAS, [1], [2]
    • FindBZip2, [1]
    • FindBacktrace, [1]
    • FindBoost, [1], [2], [3], [4], [5]
    • FindBullet
    • FindCABLE
    • FindCUDA, [1], [2], [3], [4], [5]
    • FindCURL, [1], [2], [3]
    • FindCVS
    • FindCoin3D
    • FindCups
    • FindCurses, [1]
    • FindCxxTest
    • FindCygwin
    • FindDCMTK
    • FindDart
    • FindDevIL
    • FindDoxygen, [1], [2], [3]
    • FindEXPAT, [1]
    • FindFLEX, [1], [2]
    • FindFLTK
    • FindFLTK2
    • FindFontconfig, [1]
    • FindFreetype, [1]
    • FindGCCXML
    • FindGDAL, [1]
    • FindGIF, [1]
    • FindGLEW, [1]
    • FindGLUT, [1]
    • FindGSL, [1]
    • FindGTK
    • FindGTK2, [1], [2]
    • FindGTest, [1], [2], [3], [4]
    • FindGettext, [1]
    • FindGit, [1], [2]
    • FindGnuTLS
    • FindGnuplot
    • FindHDF5, [1]
    • FindHSPELL
    • FindHTMLHelp
    • FindHg, [1]
    • FindICU, [1]
    • FindITK, [1]
    • FindIce, [1], [2]
    • FindIconv, [1]
    • FindIcotool
    • FindImageMagick
    • FindIntl, [1], [2]
    • FindJNI, [1], [2]
    • FindJPEG, [1]
    • FindJasper
    • FindJava, [1], [2]
    • FindKDE3
    • FindKDE4
    • FindLAPACK, [1], [2]
    • FindLATEX, [1]
    • FindLTTngUST, [1]
    • FindLibArchive
    • FindLibLZMA, [1]
    • FindLibXml2, [1]
    • FindLibXslt
    • FindLibinput, [1]
    • FindLua, [1]
    • FindLua50
    • FindLua51
    • FindMFC
    • FindMPEG
    • FindMPEG2
    • FindMPI, [1], [2], [3]
    • FindMatlab, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • FindMotif
    • FindODBC, [1]
    • FindOpenACC, [1]
    • FindOpenAL
    • FindOpenCL, [1], [2]
    • FindOpenGL, [1], [2], [3], [4], [5], [6]
    • FindOpenMP, [1], [2], [3], [4]
    • FindOpenSSL, [1], [2], [3], [4]
    • FindOpenSceneGraph
    • FindOpenThreads
    • FindPHP4
    • FindPNG, [1]
    • FindPackageHandleStandardArgs, [1], [2], [3]
    • FindPackageMessage
    • FindPatch, [1]
    • FindPerl
    • FindPerlLibs
    • FindPhysFS
    • FindPike
    • FindPkgConfig, [1], [2], [3], [4], [5], [6], [7], [8]
    • FindPostgreSQL, [1]
    • FindProducer
    • FindProtobuf, [1], [2], [3], [4], [5], [6], [7]
    • FindPython, [1], [2], [3], [4], [5], [6], [7], [8]
    • FindPython2, [1], [2], [3], [4], [5], [6], [7], [8]
    • FindPython3, [1], [2], [3], [4], [5], [6], [7], [8]
    • FindPythonInterp
    • FindPythonLibs
    • FindQt, [1], [2], [3], [4], [5], [6]
    • FindQt3
    • FindQt4, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • FindQuickTime
    • FindRTI
    • FindRuby, [1]
    • FindSDL
    • FindSDL_image
    • FindSDL_mixer
    • FindSDL_net
    • FindSDL_sound
    • FindSDL_ttf
    • FindSQLite3, [1]
    • FindSWIG, [1]
    • FindSelfPackers
    • FindSquish
    • FindSubversion, [1]
    • FindTCL
    • FindTIFF, [1], [2]
    • FindTclStub
    • FindTclsh
    • FindThreads, [1]
    • FindUnixCommands
    • FindVTK, [1]
    • FindVulkan, [1]
    • FindWget
    • FindWish
    • FindX11, [1], [2], [3], [4]
    • FindXCTest, [1], [2]
    • FindXMLRPC
    • FindXalanC, [1]
    • FindXercesC, [1], [2], [3]
    • FindZLIB, [1], [2]
    • Findosg
    • FindosgAnimation
    • FindosgDB
    • FindosgFX
    • FindosgGA
    • FindosgIntrospection
    • FindosgManipulator
    • FindosgParticle
    • FindosgPresentation
    • FindosgProducer
    • FindosgQt
    • FindosgShadow
    • FindosgSim
    • FindosgTerrain
    • FindosgText
    • FindosgUtil
    • FindosgViewer
    • FindosgVolume
    • FindosgWidget
    • Findosg_functions
    • FindwxWidgets, [1], [2]
    • FindwxWindows
    • FortranCInterface
    • GNUInstallDirs, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • GenerateExportHeader, [1], [2], [3], [4]
    • GetPrerequisites
    • GoogleTest, [1], [2], [3], [4]
    • InstallRequiredSystemLibraries, [1], [2], [3], [4]
    • MacroAddFileDependencies
    • ProcessorCount, [1]
    • SelectLibraryConfigurations
    • SquishTestScript
    • TestBigEndian
    • TestCXXAcceptsFlag
    • TestForANSIForScope
    • TestForANSIStreamHeaders
    • TestForSSTREAM
    • TestForSTDNamespace
    • UseEcos
    • UseJava, [1], [2], [3], [4], [5], [6]
    • UseJavaClassFilelist
    • UseJavaSymlinks
    • UsePkgConfig
    • UseSWIG, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
    • Use_wxWindows
    • UsewxWidgets
    • WriteBasicConfigVersionFile
    • WriteCompilerDetectionHeader, [1], [2], [3], [4], [5], [6]
  • MSVC
    • variable
  • MSVC10
    • variable
  • MSVC11
    • variable
  • MSVC12
    • variable
  • MSVC14
    • variable
  • MSVC60
    • variable
  • MSVC70
    • variable
  • MSVC71
    • variable
  • MSVC80
    • variable
  • MSVC90
    • variable
  • MSVC_IDE
    • variable
  • MSVC_TOOLSET_VERSION
    • variable, [1], [2]
  • MSVC_VERSION
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • MSYS
    • variable
  • MSYS Makefiles
    • generator, [1], [2]

N

  • NAME
    • target property, [1]
  • Ninja
    • generator, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56]
  • NMake Makefiles
    • generator, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • NMake Makefiles JOM
    • generator, [1], [2]
  • NO_SONAME
    • target property, [1]
  • NO_SYSTEM_FROM_IMPORTED
    • target property, [1], [2], [3], [4]

O

  • OBJECT_DEPENDS
    • source file property, [1]
  • OBJECT_OUTPUTS
    • source file property
  • ODBC::ODBC
    • variable
  • ODBC_CONFIG
    • variable, [1]
  • ODBC_FOUND
    • variable
  • ODBC_INCLUDE_DIR
    • variable
  • ODBC_INCLUDE_DIRS
    • variable
  • ODBC_LIBRARIES
    • variable
  • ODBC_LIBRARY
    • variable
  • option
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
  • OSX_ARCHITECTURES
    • target property, [1], [2], [3]
  • OSX_ARCHITECTURES_<CONFIG>
    • target property, [1]
  • OUTPUT_NAME
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • OUTPUT_NAME_<CONFIG>
    • target property, [1], [2], [3], [4], [5]
  • output_required_files
    • command, [1], [2]

P

  • PACKAGES_FOUND
    • global property
  • PACKAGES_NOT_FOUND
    • global property
  • PARENT_DIRECTORY
    • directory property
  • PASS_REGULAR_EXPRESSION
    • test property, [1]
  • PDB_NAME
    • target property, [1], [2], [3], [4]
  • PDB_NAME_<CONFIG>
    • target property, [1], [2]
  • PDB_OUTPUT_DIRECTORY
    • target property, [1], [2], [3], [4], [5], [6]
  • PDB_OUTPUT_DIRECTORY_<CONFIG>
    • target property, [1], [2], [3]
  • pkg_check_modules
    • command, [1], [2], [3], [4]
  • PKG_CONFIG_EXECUTABLE
    • variable
  • PKG_CONFIG_USE_CMAKE_PREFIX_PATH
    • variable, [1]
  • pkg_get_variable
    • command, [1], [2]
  • pkg_search_module
    • command, [1], [2]
  • policy
    • CMP0000, [1], [2]
    • CMP0001, [1]
    • CMP0002
    • CMP0003, [1], [2], [3]
    • CMP0004, [1]
    • CMP0005
    • CMP0006
    • CMP0007
    • CMP0008
    • CMP0009, [1], [2]
    • CMP0010, [1]
    • CMP0011, [1]
    • CMP0012
    • CMP0013
    • CMP0014
    • CMP0015, [1]
    • CMP0016
    • CMP0017, [1]
    • CMP0018
    • CMP0019
    • CMP0020
    • CMP0021
    • CMP0022, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • CMP0023
    • CMP0024, [1]
    • CMP0025, [1], [2]
    • CMP0026, [1]
    • CMP0027, [1]
    • CMP0028, [1], [2], [3]
    • CMP0029, [1], [2]
    • CMP0030, [1], [2]
    • CMP0031, [1], [2]
    • CMP0032, [1], [2]
    • CMP0033, [1], [2], [3]
    • CMP0034, [1], [2]
    • CMP0035, [1], [2]
    • CMP0036, [1], [2]
    • CMP0037, [1], [2]
    • CMP0038, [1]
    • CMP0039, [1]
    • CMP0040, [1]
    • CMP0041, [1], [2]
    • CMP0042, [1], [2]
    • CMP0043, [1], [2], [3], [4]
    • CMP0044, [1]
    • CMP0045, [1]
    • CMP0046, [1]
    • CMP0047, [1], [2]
    • CMP0048, [1], [2]
    • CMP0049, [1]
    • CMP0050, [1]
    • CMP0051, [1]
    • CMP0052, [1]
    • CMP0053, [1], [2], [3], [4], [5]
    • CMP0054, [1], [2]
    • CMP0055, [1]
    • CMP0056, [1], [2], [3]
    • CMP0057
    • CMP0058, [1]
    • CMP0059, [1], [2]
    • CMP0060, [1], [2], [3], [4]
    • CMP0061, [1], [2]
    • CMP0062, [1]
    • CMP0063, [1], [2], [3]
    • CMP0064, [1]
    • CMP0065, [1], [2], [3]
    • CMP0066, [1], [2]
    • CMP0067, [1], [2], [3]
    • CMP0068, [1], [2], [3]
    • CMP0069, [1], [2], [3]
    • CMP0070, [1], [2], [3]
    • CMP0071, [1], [2], [3], [4]
    • CMP0072, [1], [2], [3]
    • CMP0073, [1]
    • CMP0074, [1], [2], [3], [4], [5], [6], [7], [8]
    • CMP0075, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • CMP0076, [1], [2]
    • CMP0077, [1], [2]
    • CMP0078, [1], [2]
    • CMP0079, [1], [2]
    • CMP0080, [1]
    • CMP0081, [1]
    • CMP0082, [1], [2]
    • CMP0083, [1], [2], [3], [4], [5], [6]
    • CMP0084, [1], [2]
    • CMP0085, [1]
    • CMP0086, [1], [2]
    • CMP0087, [1]
    • CMP0088, [1]
  • POSITION_INDEPENDENT_CODE
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20]
  • POST_INSTALL_SCRIPT
    • target property, [1]
  • PRE_INSTALL_SCRIPT
    • target property, [1]
  • PREDEFINED_TARGETS_FOLDER
    • global property
  • PREFIX
    • target property
  • print_disabled_features
    • command, [1]
  • print_enabled_features
    • command, [1]
  • PRIVATE_HEADER
    • target property, [1], [2], [3]
  • PROCESSOR_AFFINITY
    • test property, [1], [2]
  • ProcessorCount
    • module, [1]
  • PROCESSORS
    • test property, [1], [2], [3]
  • project
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97]
  • PROJECT_BINARY_DIR
    • variable, [1], [2]
  • PROJECT_DESCRIPTION
    • variable, [1], [2], [3], [4], [5]
  • PROJECT_HOMEPAGE_URL
    • variable, [1], [2], [3]
  • PROJECT_LABEL
    • target property
  • PROJECT_NAME
    • variable, [1], [2], [3], [4]
  • PROJECT_SOURCE_DIR
    • variable, [1], [2], [3]
  • PROJECT_VERSION
    • variable, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • PROJECT_VERSION_MAJOR
    • variable, [1], [2]
  • PROJECT_VERSION_MINOR
    • variable, [1], [2]
  • PROJECT_VERSION_PATCH
    • variable, [1], [2]
  • PROJECT_VERSION_TWEAK
    • variable, [1], [2]
  • protobuf_generate_cpp
    • command, [1], [2]
  • protobuf_generate_python
    • command, [1]
  • PUBLIC_HEADER
    • target property, [1], [2], [3]

Q

  • qt_wrap_cpp
    • command
  • qt_wrap_ui
    • command
  • QTIFWDIR
    • variable, [1]

R

  • RC
    • envvar
  • RCFLAGS
    • envvar
  • remove
    • command
  • remove_definitions
    • command
  • REPORT_UNDEFINED_PROPERTIES
    • global property
  • REQUIRED_FILES
    • test property, [1]
  • RESOURCE
    • target property, [1], [2], [3]
  • RESOURCE_LOCK
    • test property, [1], [2], [3], [4]
  • return
    • command, [1], [2], [3], [4], [5]
  • RULE_LAUNCH_COMPILE
    • directory property
    • global property
    • target property
  • RULE_LAUNCH_CUSTOM
    • directory property
    • global property
    • target property
  • RULE_LAUNCH_LINK
    • directory property
    • global property
    • target property
  • RULE_MESSAGES
    • global property, [1], [2]
  • RUN_SERIAL
    • test property
  • RUNTIME_OUTPUT_DIRECTORY
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • RUNTIME_OUTPUT_DIRECTORY_<CONFIG>
    • target property, [1], [2]
  • RUNTIME_OUTPUT_NAME
    • target property, [1], [2], [3]
  • RUNTIME_OUTPUT_NAME_<CONFIG>
    • target property, [1], [2]

S

  • SelectLibraryConfigurations
    • module
  • separate_arguments
    • command, [1], [2], [3], [4], [5]
  • set
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]
  • set_directory_properties
    • command, [1], [2], [3]
  • set_feature_info
    • command, [1]
  • set_package_info
    • command, [1]
  • set_package_properties
    • command, [1]
  • set_property
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
  • set_source_files_properties
    • command, [1], [2]
  • set_target_properties
    • command, [1], [2], [3], [4], [5], [6]
  • set_tests_properties
    • command, [1]
  • site_name
    • command, [1]
  • SKIP_AUTOGEN
    • source file property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • SKIP_AUTOMOC
    • source file property, [1], [2], [3], [4], [5], [6], [7], [8]
  • SKIP_AUTORCC
    • source file property, [1], [2], [3], [4]
  • SKIP_AUTOUIC
    • source file property, [1], [2], [3], [4], [5], [6], [7], [8], [9]
  • SKIP_BUILD_RPATH
    • target property, [1], [2], [3]
  • SKIP_RETURN_CODE
    • test property, [1], [2]
  • source file property
    • ABSTRACT
    • AUTORCC_OPTIONS, [1], [2], [3]
    • AUTOUIC_OPTIONS, [1], [2], [3]
    • COMPILE_DEFINITIONS, [1], [2], [3], [4], [5], [6], [7], [8]
    • COMPILE_DEFINITIONS_<CONFIG>
    • COMPILE_FLAGS, [1], [2], [3]
    • COMPILE_OPTIONS, [1], [2], [3], [4], [5]
    • EXTERNAL_OBJECT
    • Fortran_FORMAT
    • GENERATED, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20]
    • HEADER_FILE_ONLY, [1], [2]
    • INCLUDE_DIRECTORIES, [1], [2], [3], [4], [5], [6]
    • KEEP_EXTENSION
    • LABELS, [1]
    • LANGUAGE, [1], [2]
    • LOCATION, [1]
    • MACOSX_PACKAGE_LOCATION
    • OBJECT_DEPENDS, [1]
    • OBJECT_OUTPUTS
    • SKIP_AUTOGEN, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • SKIP_AUTOMOC, [1], [2], [3], [4], [5], [6], [7], [8]
    • SKIP_AUTORCC, [1], [2], [3], [4]
    • SKIP_AUTOUIC, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • SYMBOLIC, [1]
    • VS_COPY_TO_OUT_DIR, [1]
    • VS_CSHARP_<tagname>, [1], [2], [3], [4], [5]
    • VS_DEPLOYMENT_CONTENT, [1], [2]
    • VS_DEPLOYMENT_LOCATION, [1]
    • VS_INCLUDE_IN_VSIX, [1]
    • VS_RESOURCE_GENERATOR, [1]
    • VS_SHADER_DISABLE_OPTIMIZATIONS, [1], [2]
    • VS_SHADER_ENABLE_DEBUG, [1], [2]
    • VS_SHADER_ENTRYPOINT, [1]
    • VS_SHADER_FLAGS, [1]
    • VS_SHADER_MODEL, [1]
    • VS_SHADER_OBJECT_FILE_NAME, [1]
    • VS_SHADER_OUTPUT_HEADER_FILE, [1]
    • VS_SHADER_TYPE, [1]
    • VS_SHADER_VARIABLE_NAME, [1]
    • VS_TOOL_OVERRIDE, [1]
    • VS_XAML_TYPE
    • WRAP_EXCLUDE
    • XCODE_EXPLICIT_FILE_TYPE, [1], [2]
    • XCODE_FILE_ATTRIBUTES, [1]
    • XCODE_LAST_KNOWN_FILE_TYPE, [1], [2]
  • SOURCE_DIR
    • directory property, [1]
    • target property, [1], [2]
  • source_group
    • command, [1], [2], [3], [4], [5], [6], [7], [8]
  • SOURCES
    • target property, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
  • SOVERSION
    • target property, [1], [2], [3]
  • SquishTestScript
    • module
  • STATIC_LIBRARY_FLAGS
    • target property, [1], [2], [3]
  • STATIC_LIBRARY_FLAGS_<CONFIG>
    • target property, [1]
  • STATIC_LIBRARY_OPTIONS
    • target property, [1], [2], [3], [4], [5], [6]
  • string
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21]
  • STRINGS
    • cache property, [1], [2]
  • subdir_depends
    • command, [1], [2]
  • SUBDIRECTORIES
    • directory property, [1]
  • subdirs
    • command, [1], [2], [3]
  • Sublime Text 2
    • generator, [1], [2], [3], [4]
  • SUFFIX
    • target property
  • swig_add_library
    • command, [1]
  • swig_link_libraries
    • command
  • SYMBOLIC
    • source file property, [1]

T

  • target property
    • <CONFIG>_OUTPUT_NAME
    • <CONFIG>_POSTFIX, [1]
    • <LANG>_CLANG_TIDY, [1], [2], [3]
    • <LANG>_COMPILER_LAUNCHER, [1], [2], [3], [4]
    • <LANG>_CPPCHECK, [1], [2], [3]
    • <LANG>_CPPLINT, [1], [2]
    • <LANG>_INCLUDE_WHAT_YOU_USE, [1], [2]
    • <LANG>_VISIBILITY_PRESET, [1], [2], [3], [4], [5], [6], [7]
    • ALIASED_TARGET, [1]
    • ANDROID_ANT_ADDITIONAL_OPTIONS, [1], [2], [3]
    • ANDROID_API, [1], [2]
    • ANDROID_API_MIN, [1], [2], [3]
    • ANDROID_ARCH, [1], [2], [3]
    • ANDROID_ASSETS_DIRECTORIES, [1], [2], [3]
    • ANDROID_GUI, [1], [2]
    • ANDROID_JAR_DEPENDENCIES, [1], [2], [3]
    • ANDROID_JAR_DIRECTORIES, [1], [2], [3]
    • ANDROID_JAVA_SOURCE_DIR, [1], [2], [3]
    • ANDROID_NATIVE_LIB_DEPENDENCIES, [1], [2], [3]
    • ANDROID_NATIVE_LIB_DIRECTORIES, [1], [2], [3]
    • ANDROID_PROCESS_MAX, [1], [2], [3]
    • ANDROID_PROGUARD, [1], [2], [3]
    • ANDROID_PROGUARD_CONFIG_PATH, [1], [2], [3]
    • ANDROID_SECURE_PROPS_PATH, [1], [2], [3]
    • ANDROID_SKIP_ANT_STEP, [1], [2], [3]
    • ANDROID_STL_TYPE, [1], [2], [3]
    • ARCHIVE_OUTPUT_DIRECTORY, [1], [2], [3], [4], [5], [6]
    • ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>, [1], [2]
    • ARCHIVE_OUTPUT_NAME, [1], [2], [3]
    • ARCHIVE_OUTPUT_NAME_<CONFIG>, [1], [2]
    • AUTOGEN_BUILD_DIR, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • AUTOGEN_ORIGIN_DEPENDS, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • AUTOGEN_PARALLEL, [1], [2], [3], [4], [5], [6]
    • AUTOGEN_TARGET_DEPENDS, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • AUTOMOC, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69]
    • AUTOMOC_COMPILER_PREDEFINES, [1], [2], [3], [4], [5], [6]
    • AUTOMOC_DEPEND_FILTERS, [1], [2], [3], [4], [5]
    • AUTOMOC_EXECUTABLE, [1], [2], [3]
    • AUTOMOC_MACRO_NAMES, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • AUTOMOC_MOC_OPTIONS, [1], [2], [3]
    • AUTORCC, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31]
    • AUTORCC_EXECUTABLE, [1], [2], [3]
    • AUTORCC_OPTIONS, [1], [2], [3], [4]
    • AUTOUIC, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44]
    • AUTOUIC_EXECUTABLE, [1], [2], [3]
    • AUTOUIC_OPTIONS, [1], [2], [3], [4], [5], [6], [7]
    • AUTOUIC_SEARCH_PATHS, [1], [2], [3], [4]
    • BINARY_DIR, [1]
    • BUILD_RPATH, [1], [2], [3]
    • BUILD_RPATH_USE_ORIGIN, [1], [2]
    • BUILD_WITH_INSTALL_NAME_DIR, [1], [2], [3], [4]
    • BUILD_WITH_INSTALL_RPATH, [1], [2], [3], [4], [5]
    • BUNDLE, [1], [2], [3], [4], [5], [6]
    • BUNDLE_EXTENSION, [1]
    • COMMON_LANGUAGE_RUNTIME, [1], [2]
    • COMPATIBLE_INTERFACE_BOOL, [1], [2]
    • COMPATIBLE_INTERFACE_NUMBER_MAX, [1], [2], [3]
    • COMPATIBLE_INTERFACE_NUMBER_MIN, [1], [2], [3]
    • COMPATIBLE_INTERFACE_STRING, [1], [2], [3], [4]
    • COMPILE_DEFINITIONS, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18]
    • COMPILE_DEFINITIONS_<CONFIG>, [1], [2], [3], [4], [5], [6]
    • COMPILE_FEATURES, [1], [2], [3], [4]
    • COMPILE_FLAGS, [1]
    • COMPILE_OPTIONS, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • COMPILE_PDB_NAME, [1], [2], [3]
    • COMPILE_PDB_NAME_<CONFIG>, [1]
    • COMPILE_PDB_OUTPUT_DIRECTORY, [1], [2], [3], [4]
    • COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>, [1], [2]
    • CROSSCOMPILING_EMULATOR, [1], [2], [3], [4], [5], [6]
    • CUDA_EXTENSIONS, [1], [2], [3], [4]
    • CUDA_PTX_COMPILATION, [1]
    • CUDA_RESOLVE_DEVICE_SYMBOLS, [1]
    • CUDA_SEPARABLE_COMPILATION, [1], [2]
    • CUDA_STANDARD, [1], [2], [3], [4], [5], [6], [7], [8]
    • CUDA_STANDARD_REQUIRED, [1], [2], [3], [4]
    • CXX_EXTENSIONS, [1], [2], [3], [4], [5], [6]
    • CXX_STANDARD, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • CXX_STANDARD_REQUIRED, [1], [2], [3], [4]
    • C_EXTENSIONS, [1], [2], [3], [4], [5]
    • C_STANDARD, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • C_STANDARD_REQUIRED, [1], [2], [3], [4]
    • DEBUG_POSTFIX
    • DEFINE_SYMBOL, [1]
    • DEPLOYMENT_ADDITIONAL_FILES, [1]
    • DEPLOYMENT_REMOTE_DIRECTORY, [1]
    • DOTNET_TARGET_FRAMEWORK_VERSION, [1], [2], [3], [4], [5]
    • ENABLE_EXPORTS, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • EXCLUDE_FROM_ALL, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • EXCLUDE_FROM_DEFAULT_BUILD
    • EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>
    • EXPORT_NAME
    • EXPORT_PROPERTIES, [1]
    • EchoString
    • FOLDER, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • FRAMEWORK, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
    • FRAMEWORK_VERSION, [1]
    • Fortran_FORMAT, [1]
    • Fortran_MODULE_DIRECTORY, [1], [2], [3]
    • GENERATOR_FILE_NAME
    • GHS_INTEGRITY_APP, [1], [2]
    • GHS_NO_SOURCE_GROUP_FILE, [1], [2], [3]
    • GNUtoMS, [1]
    • HAS_CXX
    • IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
    • IMPORTED, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64]
    • IMPORTED_COMMON_LANGUAGE_RUNTIME, [1], [2]
    • IMPORTED_CONFIGURATIONS, [1]
    • IMPORTED_GLOBAL, [1]
    • IMPORTED_IMPLIB
    • IMPORTED_IMPLIB_<CONFIG>
    • IMPORTED_LIBNAME, [1], [2]
    • IMPORTED_LIBNAME_<CONFIG>, [1]
    • IMPORTED_LINK_DEPENDENT_LIBRARIES
    • IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG>
    • IMPORTED_LINK_INTERFACE_LANGUAGES
    • IMPORTED_LINK_INTERFACE_LANGUAGES_<CONFIG>
    • IMPORTED_LINK_INTERFACE_LIBRARIES
    • IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG>
    • IMPORTED_LINK_INTERFACE_MULTIPLICITY
    • IMPORTED_LINK_INTERFACE_MULTIPLICITY_<CONFIG>
    • IMPORTED_LOCATION, [1], [2], [3], [4], [5], [6], [7], [8]
    • IMPORTED_LOCATION_<CONFIG>, [1], [2], [3]
    • IMPORTED_NO_SONAME, [1]
    • IMPORTED_NO_SONAME_<CONFIG>
    • IMPORTED_OBJECTS, [1], [2]
    • IMPORTED_OBJECTS_<CONFIG>, [1], [2]
    • IMPORTED_SONAME
    • IMPORTED_SONAME_<CONFIG>
    • IMPORT_PREFIX
    • IMPORT_SUFFIX
    • INCLUDE_DIRECTORIES, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30]
    • INSTALL_NAME_DIR, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • INSTALL_RPATH, [1], [2], [3], [4], [5], [6]
    • INSTALL_RPATH_USE_LINK_PATH, [1]
    • INTERFACE_AUTOUIC_OPTIONS, [1], [2]
    • INTERFACE_COMPILE_DEFINITIONS, [1], [2], [3], [4], [5], [6], [7]
    • INTERFACE_COMPILE_FEATURES, [1], [2]
    • INTERFACE_COMPILE_OPTIONS, [1], [2], [3], [4], [5], [6], [7]
    • INTERFACE_INCLUDE_DIRECTORIES, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30]
    • INTERFACE_LINK_DEPENDS, [1]
    • INTERFACE_LINK_DIRECTORIES, [1], [2]
    • INTERFACE_LINK_LIBRARIES, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23]
    • INTERFACE_LINK_OPTIONS, [1], [2]
    • INTERFACE_POSITION_INDEPENDENT_CODE, [1], [2], [3], [4], [5]
    • INTERFACE_SOURCES, [1], [2], [3], [4], [5], [6]
    • INTERFACE_SYSTEM_INCLUDE_DIRECTORIES, [1], [2]
    • INTERPROCEDURAL_OPTIMIZATION, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • INTERPROCEDURAL_OPTIMIZATION_<CONFIG>, [1], [2]
    • IOS_INSTALL_COMBINED, [1], [2], [3]
    • JOB_POOL_COMPILE, [1], [2], [3]
    • JOB_POOL_LINK, [1], [2], [3]
    • LABELS, [1]
    • LIBRARY_OUTPUT_DIRECTORY, [1], [2], [3], [4], [5], [6]
    • LIBRARY_OUTPUT_DIRECTORY_<CONFIG>, [1], [2]
    • LIBRARY_OUTPUT_NAME, [1], [2], [3]
    • LIBRARY_OUTPUT_NAME_<CONFIG>, [1], [2]
    • LINKER_LANGUAGE, [1], [2]
    • LINK_DEPENDS, [1]
    • LINK_DEPENDS_NO_SHARED, [1]
    • LINK_DIRECTORIES, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • LINK_FLAGS, [1], [2], [3]
    • LINK_FLAGS_<CONFIG>, [1]
    • LINK_INTERFACE_LIBRARIES, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • LINK_INTERFACE_LIBRARIES_<CONFIG>, [1], [2]
    • LINK_INTERFACE_MULTIPLICITY, [1]
    • LINK_INTERFACE_MULTIPLICITY_<CONFIG>
    • LINK_LIBRARIES, [1], [2], [3], [4], [5]
    • LINK_OPTIONS, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • LINK_SEARCH_END_STATIC, [1], [2], [3]
    • LINK_SEARCH_START_STATIC, [1], [2]
    • LINK_WHAT_YOU_USE, [1], [2]
    • LOCATION, [1], [2], [3]
    • LOCATION_<CONFIG>
    • MACOSX_BUNDLE, [1], [2], [3], [4], [5], [6], [7]
    • MACOSX_BUNDLE_INFO_PLIST, [1]
    • MACOSX_FRAMEWORK_INFO_PLIST, [1]
    • MACOSX_RPATH, [1], [2], [3], [4]
    • MANUALLY_ADDED_DEPENDENCIES, [1]
    • MAP_IMPORTED_CONFIG_<CONFIG>, [1], [2], [3], [4], [5], [6], [7], [8]
    • NAME, [1]
    • NO_SONAME, [1]
    • NO_SYSTEM_FROM_IMPORTED, [1], [2], [3], [4]
    • OSX_ARCHITECTURES, [1], [2], [3]
    • OSX_ARCHITECTURES_<CONFIG>, [1]
    • OUTPUT_NAME, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
    • OUTPUT_NAME_<CONFIG>, [1], [2], [3], [4], [5]
    • PDB_NAME, [1], [2], [3], [4]
    • PDB_NAME_<CONFIG>, [1], [2]
    • PDB_OUTPUT_DIRECTORY, [1], [2], [3], [4], [5], [6]
    • PDB_OUTPUT_DIRECTORY_<CONFIG>, [1], [2], [3]
    • POSITION_INDEPENDENT_CODE, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20]
    • POST_INSTALL_SCRIPT, [1]
    • PREFIX
    • PRE_INSTALL_SCRIPT, [1]
    • PRIVATE_HEADER, [1], [2], [3]
    • PROJECT_LABEL
    • PUBLIC_HEADER, [1], [2], [3]
    • RESOURCE, [1], [2], [3]
    • RULE_LAUNCH_COMPILE
    • RULE_LAUNCH_CUSTOM
    • RULE_LAUNCH_LINK
    • RUNTIME_OUTPUT_DIRECTORY, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • RUNTIME_OUTPUT_DIRECTORY_<CONFIG>, [1], [2]
    • RUNTIME_OUTPUT_NAME, [1], [2], [3]
    • RUNTIME_OUTPUT_NAME_<CONFIG>, [1], [2]
    • SKIP_BUILD_RPATH, [1], [2], [3]
    • SOURCES, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • SOURCE_DIR, [1], [2]
    • SOVERSION, [1], [2], [3]
    • STATIC_LIBRARY_FLAGS, [1], [2], [3]
    • STATIC_LIBRARY_FLAGS_<CONFIG>, [1]
    • STATIC_LIBRARY_OPTIONS, [1], [2], [3], [4], [5], [6]
    • SUFFIX
    • TYPE, [1], [2]
    • VERSION, [1], [2], [3], [4]
    • VISIBILITY_INLINES_HIDDEN, [1], [2], [3], [4], [5], [6], [7]
    • VS_CONFIGURATION_TYPE, [1]
    • VS_DEBUGGER_COMMAND, [1], [2]
    • VS_DEBUGGER_COMMAND_ARGUMENTS, [1]
    • VS_DEBUGGER_ENVIRONMENT, [1]
    • VS_DEBUGGER_WORKING_DIRECTORY, [1], [2]
    • VS_DESKTOP_EXTENSIONS_VERSION
    • VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname>, [1]
    • VS_DOTNET_REFERENCES, [1], [2], [3]
    • VS_DOTNET_REFERENCES_COPY_LOCAL, [1], [2]
    • VS_DOTNET_REFERENCE_<refname>, [1], [2], [3]
    • VS_DOTNET_TARGET_FRAMEWORK_VERSION, [1]
    • VS_GLOBAL_<variable>, [1], [2], [3]
    • VS_GLOBAL_KEYWORD, [1]
    • VS_GLOBAL_PROJECT_TYPES
    • VS_GLOBAL_ROOTNAMESPACE
    • VS_IOT_EXTENSIONS_VERSION
    • VS_IOT_STARTUP_TASK
    • VS_KEYWORD, [1]
    • VS_MOBILE_EXTENSIONS_VERSION
    • VS_SCC_AUXPATH
    • VS_SCC_LOCALPATH
    • VS_SCC_PROJECTNAME
    • VS_SCC_PROVIDER
    • VS_SDK_REFERENCES, [1]
    • VS_USER_PROPS, [1]
    • VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION
    • VS_WINRT_COMPONENT, [1], [2]
    • VS_WINRT_EXTENSIONS
    • VS_WINRT_REFERENCES
    • WIN32_EXECUTABLE, [1], [2], [3], [4], [5]
    • WINDOWS_EXPORT_ALL_SYMBOLS, [1], [2], [3], [4]
    • XCODE_ATTRIBUTE_<an-attribute>, [1], [2]
    • XCODE_EXPLICIT_FILE_TYPE, [1], [2]
    • XCODE_PRODUCT_TYPE, [1], [2]
    • XCODE_SCHEME_ADDRESS_SANITIZER, [1], [2]
    • XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN, [1], [2]
    • XCODE_SCHEME_ARGUMENTS, [1]
    • XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER, [1], [2]
    • XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS, [1], [2]
    • XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE, [1], [2]
    • XCODE_SCHEME_ENVIRONMENT, [1]
    • XCODE_SCHEME_EXECUTABLE, [1]
    • XCODE_SCHEME_GUARD_MALLOC, [1], [2]
    • XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP, [1], [2]
    • XCODE_SCHEME_MALLOC_GUARD_EDGES, [1], [2]
    • XCODE_SCHEME_MALLOC_SCRIBBLE, [1], [2]
    • XCODE_SCHEME_MALLOC_STACK, [1], [2]
    • XCODE_SCHEME_THREAD_SANITIZER, [1], [2]
    • XCODE_SCHEME_THREAD_SANITIZER_STOP, [1], [2]
    • XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER, [1], [2]
    • XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP, [1], [2]
    • XCODE_SCHEME_ZOMBIE_OBJECTS, [1], [2]
    • XCTEST, [1]
  • TARGET_ARCHIVES_MAY_BE_SHARED_LIBS
    • global property
  • target_compile_definitions
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
  • target_compile_features
    • command, [1], [2], [3], [4], [5], [6], [7]
  • target_compile_options
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
  • target_include_directories
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
  • target_link_directories
    • command, [1], [2], [3], [4], [5]
  • target_link_libraries
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77]
  • target_link_options
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]
  • TARGET_MESSAGES
    • global property, [1]
  • target_sources
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
  • TARGET_SUPPORTS_SHARED_LIBS
    • global property
  • test property
    • ATTACHED_FILES, [1]
    • ATTACHED_FILES_ON_FAIL
    • COST
    • DEPENDS, [1], [2], [3]
    • DISABLED, [1], [2]
    • ENVIRONMENT
    • FAIL_REGULAR_EXPRESSION, [1]
    • FIXTURES_CLEANUP, [1], [2]
    • FIXTURES_REQUIRED, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • FIXTURES_SETUP, [1], [2], [3]
    • LABELS, [1]
    • MEASUREMENT
    • PASS_REGULAR_EXPRESSION, [1]
    • PROCESSORS, [1], [2], [3]
    • PROCESSOR_AFFINITY, [1], [2]
    • REQUIRED_FILES, [1]
    • RESOURCE_LOCK, [1], [2], [3], [4]
    • RUN_SERIAL
    • SKIP_RETURN_CODE, [1], [2]
    • TIMEOUT, [1], [2], [3], [4]
    • TIMEOUT_AFTER_MATCH, [1], [2], [3], [4]
    • WILL_FAIL, [1]
    • WORKING_DIRECTORY, [1], [2]
  • TEST_INCLUDE_FILE
    • directory property, [1]
  • TEST_INCLUDE_FILES
    • directory property, [1], [2], [3]
  • TestBigEndian
    • module
  • TestCXXAcceptsFlag
    • module
  • TestForANSIForScope
    • module
  • TestForANSIStreamHeaders
    • module
  • TestForSSTREAM
    • module
  • TestForSTDNamespace
    • module
  • TESTS
    • directory property, [1]
  • TIMEOUT
    • test property, [1], [2], [3], [4]
  • TIMEOUT_AFTER_MATCH
    • test property, [1], [2], [3], [4]
  • try_compile
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47]
  • try_run
    • command, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19]
  • TYPE
    • cache property
    • target property, [1], [2]

U

  • UNIX
    • variable
  • Unix Makefiles
    • generator, [1], [2], [3], [4], [5], [6], [7]
  • unset
    • command, [1], [2], [3], [4], [5], [6], [7]
  • USE_FOLDERS
    • global property
  • use_mangled_mesa
    • command, [1], [2]
  • Use_wxWindows
    • module
  • UseEcos
    • module
  • UseJava
    • module, [1], [2], [3], [4], [5], [6]
  • UseJavaClassFilelist
    • module
  • UseJavaSymlinks
    • module
  • UsePkgConfig
    • module
  • UseSWIG
    • module, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
  • UsewxWidgets
    • module
  • utility_source
    • command, [1], [2]

V

  • VALUE
    • cache property
  • variable
    • <PROJECT-NAME>_BINARY_DIR, [1]
    • <PROJECT-NAME>_DESCRIPTION, [1]
    • <PROJECT-NAME>_HOMEPAGE_URL, [1], [2]
    • <PROJECT-NAME>_SOURCE_DIR, [1]
    • <PROJECT-NAME>_VERSION, [1], [2], [3], [4], [5]
    • <PROJECT-NAME>_VERSION_MAJOR, [1], [2]
    • <PROJECT-NAME>_VERSION_MINOR, [1], [2]
    • <PROJECT-NAME>_VERSION_PATCH, [1], [2]
    • <PROJECT-NAME>_VERSION_TWEAK, [1], [2]
    • <PackageName>_ROOT, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • ANDROID
    • APPLE, [1]
    • BORLAND
    • BUILD_SHARED_LIBS, [1], [2], [3], [4]
    • CACHE, [1]
    • CMAKE_<CONFIG>_POSTFIX, [1], [2]
    • CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE, [1], [2]
    • CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX, [1], [2], [3], [4]
    • CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX, [1], [2], [3], [4]
    • CMAKE_<LANG>_ARCHIVE_APPEND, [1], [2]
    • CMAKE_<LANG>_ARCHIVE_CREATE, [1], [2]
    • CMAKE_<LANG>_ARCHIVE_FINISH, [1], [2]
    • CMAKE_<LANG>_CLANG_TIDY, [1], [2]
    • CMAKE_<LANG>_COMPILER, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18]
    • CMAKE_<LANG>_COMPILER_ABI
    • CMAKE_<LANG>_COMPILER_AR, [1]
    • CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID
    • CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN, [1]
    • CMAKE_<LANG>_COMPILER_ID, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29]
    • CMAKE_<LANG>_COMPILER_LAUNCHER, [1], [2], [3], [4]
    • CMAKE_<LANG>_COMPILER_LOADED
    • CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND, [1], [2], [3]
    • CMAKE_<LANG>_COMPILER_RANLIB, [1]
    • CMAKE_<LANG>_COMPILER_TARGET, [1], [2], [3]
    • CMAKE_<LANG>_COMPILER_VERSION, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
    • CMAKE_<LANG>_COMPILER_VERSION_INTERNAL
    • CMAKE_<LANG>_COMPILE_OBJECT, [1]
    • CMAKE_<LANG>_CPPCHECK, [1], [2], [3]
    • CMAKE_<LANG>_CPPLINT, [1], [2]
    • CMAKE_<LANG>_CREATE_SHARED_LIBRARY
    • CMAKE_<LANG>_CREATE_SHARED_MODULE
    • CMAKE_<LANG>_CREATE_STATIC_LIBRARY, [1], [2], [3]
    • CMAKE_<LANG>_FLAGS, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32]
    • CMAKE_<LANG>_FLAGS_<CONFIG>, [1], [2], [3], [4], [5]
    • CMAKE_<LANG>_FLAGS_<CONFIG>_INIT, [1], [2], [3], [4], [5]
    • CMAKE_<LANG>_FLAGS_DEBUG, [1], [2], [3], [4], [5]
    • CMAKE_<LANG>_FLAGS_DEBUG_INIT
    • CMAKE_<LANG>_FLAGS_INIT, [1], [2], [3]
    • CMAKE_<LANG>_FLAGS_MINSIZEREL
    • CMAKE_<LANG>_FLAGS_MINSIZEREL_INIT
    • CMAKE_<LANG>_FLAGS_RELEASE
    • CMAKE_<LANG>_FLAGS_RELEASE_INIT
    • CMAKE_<LANG>_FLAGS_RELWITHDEBINFO
    • CMAKE_<LANG>_FLAGS_RELWITHDEBINFO_INIT
    • CMAKE_<LANG>_IGNORE_EXTENSIONS
    • CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES
    • CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
    • CMAKE_<LANG>_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES
    • CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
    • CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE, [1], [2]
    • CMAKE_<LANG>_LIBRARY_ARCHITECTURE, [1], [2]
    • CMAKE_<LANG>_LINKER_PREFERENCE, [1]
    • CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES, [1]
    • CMAKE_<LANG>_LINKER_WRAPPER_FLAG, [1], [2], [3]
    • CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP, [1], [2], [3]
    • CMAKE_<LANG>_LINK_EXECUTABLE
    • CMAKE_<LANG>_OUTPUT_EXTENSION
    • CMAKE_<LANG>_PLATFORM_ID
    • CMAKE_<LANG>_SIMULATE_ID
    • CMAKE_<LANG>_SIMULATE_VERSION
    • CMAKE_<LANG>_SIZEOF_DATA_PTR
    • CMAKE_<LANG>_SOURCE_FILE_EXTENSIONS
    • CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES, [1], [2]
    • CMAKE_<LANG>_STANDARD_LIBRARIES, [1], [2]
    • CMAKE_<LANG>_VISIBILITY_PRESET, [1], [2]
    • CMAKE_ABSOLUTE_DESTINATION_FILES, [1]
    • CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS, [1]
    • CMAKE_ANDROID_API, [1], [2]
    • CMAKE_ANDROID_API_MIN, [1]
    • CMAKE_ANDROID_ARCH, [1], [2]
    • CMAKE_ANDROID_ARCH_ABI, [1], [2], [3], [4], [5], [6]
    • CMAKE_ANDROID_ARM_MODE, [1], [2], [3]
    • CMAKE_ANDROID_ARM_NEON, [1], [2], [3]
    • CMAKE_ANDROID_ASSETS_DIRECTORIES, [1]
    • CMAKE_ANDROID_GUI, [1]
    • CMAKE_ANDROID_JAR_DEPENDENCIES, [1]
    • CMAKE_ANDROID_JAR_DIRECTORIES, [1]
    • CMAKE_ANDROID_JAVA_SOURCE_DIR, [1]
    • CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES, [1]
    • CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES, [1]
    • CMAKE_ANDROID_NDK, [1], [2], [3], [4], [5]
    • CMAKE_ANDROID_NDK_DEPRECATED_HEADERS, [1], [2]
    • CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG
    • CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION, [1]
    • CMAKE_ANDROID_PROCESS_MAX, [1]
    • CMAKE_ANDROID_PROGUARD, [1]
    • CMAKE_ANDROID_PROGUARD_CONFIG_PATH, [1]
    • CMAKE_ANDROID_SECURE_PROPS_PATH, [1]
    • CMAKE_ANDROID_SKIP_ANT_STEP, [1]
    • CMAKE_ANDROID_STANDALONE_TOOLCHAIN, [1], [2], [3], [4], [5]
    • CMAKE_ANDROID_STL_TYPE, [1], [2]
    • CMAKE_APPBUNDLE_PATH, [1], [2], [3], [4], [5]
    • CMAKE_AR, [1]
    • CMAKE_ARCHIVE_OUTPUT_DIRECTORY
    • CMAKE_ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>, [1]
    • CMAKE_ARGC, [1]
    • CMAKE_ARGV0, [1]
    • CMAKE_AUTOGEN_ORIGIN_DEPENDS, [1], [2], [3]
    • CMAKE_AUTOGEN_PARALLEL, [1], [2], [3]
    • CMAKE_AUTOGEN_VERBOSE, [1], [2], [3]
    • CMAKE_AUTOMOC, [1], [2], [3], [4], [5], [6]
    • CMAKE_AUTOMOC_COMPILER_PREDEFINES, [1], [2]
    • CMAKE_AUTOMOC_DEPEND_FILTERS, [1], [2], [3], [4]
    • CMAKE_AUTOMOC_MACRO_NAMES, [1], [2], [3]
    • CMAKE_AUTOMOC_MOC_OPTIONS, [1]
    • CMAKE_AUTOMOC_RELAXED_MODE, [1]
    • CMAKE_AUTORCC, [1], [2], [3]
    • CMAKE_AUTORCC_OPTIONS, [1], [2]
    • CMAKE_AUTOUIC, [1], [2], [3], [4], [5]
    • CMAKE_AUTOUIC_OPTIONS, [1], [2]
    • CMAKE_AUTOUIC_SEARCH_PATHS, [1], [2]
    • CMAKE_BACKWARDS_COMPATIBILITY
    • CMAKE_BINARY_DIR, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • CMAKE_BUILD_RPATH, [1], [2]
    • CMAKE_BUILD_RPATH_USE_ORIGIN, [1], [2]
    • CMAKE_BUILD_TOOL
    • CMAKE_BUILD_TYPE, [1], [2], [3], [4], [5], [6], [7], [8]
    • CMAKE_BUILD_WITH_INSTALL_NAME_DIR, [1], [2]
    • CMAKE_BUILD_WITH_INSTALL_RPATH, [1]
    • CMAKE_CACHEFILE_DIR
    • CMAKE_CACHE_MAJOR_VERSION
    • CMAKE_CACHE_MINOR_VERSION
    • CMAKE_CACHE_PATCH_VERSION
    • CMAKE_CFG_INTDIR, [1], [2]
    • CMAKE_CL_64
    • CMAKE_CODEBLOCKS_COMPILER_ID, [1]
    • CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES, [1], [2]
    • CMAKE_CODELITE_USE_TARGETS, [1], [2], [3]
    • CMAKE_COLOR_MAKEFILE
    • CMAKE_COMMAND, [1]
    • CMAKE_COMPILER_2005
    • CMAKE_COMPILER_IS_GNUCC
    • CMAKE_COMPILER_IS_GNUCXX
    • CMAKE_COMPILER_IS_GNUG77
    • CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY, [1], [2]
    • CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>, [1]
    • CMAKE_CONFIGURATION_TYPES, [1], [2], [3]
    • CMAKE_CPACK_COMMAND
    • CMAKE_CROSSCOMPILING, [1], [2], [3], [4]
    • CMAKE_CROSSCOMPILING_EMULATOR, [1], [2], [3]
    • CMAKE_CTEST_COMMAND
    • CMAKE_CUDA_EXTENSIONS, [1], [2], [3]
    • CMAKE_CUDA_HOST_COMPILER, [1], [2]
    • CMAKE_CUDA_SEPARABLE_COMPILATION, [1], [2]
    • CMAKE_CUDA_STANDARD, [1], [2], [3]
    • CMAKE_CUDA_STANDARD_REQUIRED, [1], [2], [3]
    • CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES
    • CMAKE_CURRENT_BINARY_DIR, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21]
    • CMAKE_CURRENT_LIST_DIR
    • CMAKE_CURRENT_LIST_FILE, [1], [2], [3], [4]
    • CMAKE_CURRENT_LIST_LINE
    • CMAKE_CURRENT_SOURCE_DIR, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • CMAKE_CXX_COMPILE_FEATURES, [1], [2], [3], [4]
    • CMAKE_CXX_EXTENSIONS, [1], [2], [3], [4]
    • CMAKE_CXX_STANDARD, [1], [2], [3], [4], [5], [6]
    • CMAKE_CXX_STANDARD_REQUIRED, [1], [2], [3]
    • CMAKE_C_COMPILE_FEATURES, [1], [2], [3]
    • CMAKE_C_EXTENSIONS, [1], [2], [3], [4]
    • CMAKE_C_STANDARD, [1], [2], [3], [4]
    • CMAKE_C_STANDARD_REQUIRED, [1], [2], [3]
    • CMAKE_DEBUG_POSTFIX
    • CMAKE_DEBUG_TARGET_PROPERTIES, [1], [2], [3]
    • CMAKE_DEPENDS_IN_PROJECT_ONLY, [1]
    • CMAKE_DIRECTORY_LABELS, [1], [2]
    • CMAKE_DISABLE_FIND_PACKAGE_<PackageName>, [1], [2]
    • CMAKE_DL_LIBS
    • CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION, [1], [2]
    • CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES
    • CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT, [1]
    • CMAKE_ECLIPSE_MAKE_ARGUMENTS
    • CMAKE_ECLIPSE_VERSION
    • CMAKE_EDIT_COMMAND
    • CMAKE_ENABLE_EXPORTS, [1], [2]
    • CMAKE_ERROR_DEPRECATED, [1], [2]
    • CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION, [1]
    • CMAKE_EXECUTABLE_SUFFIX
    • CMAKE_EXE_LINKER_FLAGS, [1], [2], [3], [4], [5], [6], [7]
    • CMAKE_EXE_LINKER_FLAGS_<CONFIG>, [1]
    • CMAKE_EXE_LINKER_FLAGS_<CONFIG>_INIT, [1]
    • CMAKE_EXE_LINKER_FLAGS_INIT, [1], [2], [3]
    • CMAKE_EXPORT_COMPILE_COMMANDS
    • CMAKE_EXPORT_NO_PACKAGE_REGISTRY, [1], [2], [3], [4]
    • CMAKE_EXTRA_GENERATOR
    • CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES
    • CMAKE_FIND_APPBUNDLE, [1], [2], [3], [4], [5]
    • CMAKE_FIND_FRAMEWORK, [1], [2], [3], [4], [5], [6], [7], [8]
    • CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX, [1], [2], [3], [4], [5]
    • CMAKE_FIND_LIBRARY_PREFIXES
    • CMAKE_FIND_LIBRARY_SUFFIXES
    • CMAKE_FIND_NO_INSTALL_PREFIX, [1], [2], [3]
    • CMAKE_FIND_PACKAGE_NAME
    • CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY, [1], [2], [3], [4]
    • CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY, [1], [2], [3], [4]
    • CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS, [1], [2]
    • CMAKE_FIND_PACKAGE_SORT_DIRECTION, [1], [2], [3], [4]
    • CMAKE_FIND_PACKAGE_SORT_ORDER, [1], [2], [3], [4], [5], [6]
    • CMAKE_FIND_PACKAGE_WARN_NO_MODULE
    • CMAKE_FIND_ROOT_PATH, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37]
    • CMAKE_FIND_ROOT_PATH_MODE_INCLUDE, [1], [2]
    • CMAKE_FIND_ROOT_PATH_MODE_LIBRARY, [1]
    • CMAKE_FIND_ROOT_PATH_MODE_PACKAGE, [1]
    • CMAKE_FIND_ROOT_PATH_MODE_PROGRAM, [1]
    • CMAKE_FOLDER, [1], [2]
    • CMAKE_FRAMEWORK_PATH, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • CMAKE_Fortran_FORMAT
    • CMAKE_Fortran_MODDIR_DEFAULT
    • CMAKE_Fortran_MODDIR_FLAG
    • CMAKE_Fortran_MODOUT_FLAG
    • CMAKE_Fortran_MODULE_DIRECTORY
    • CMAKE_GENERATOR, [1], [2], [3], [4], [5]
    • CMAKE_GENERATOR_INSTANCE, [1], [2], [3], [4]
    • CMAKE_GENERATOR_PLATFORM, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
    • CMAKE_GENERATOR_TOOLSET, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25]
    • CMAKE_GHS_NO_SOURCE_GROUP_FILE, [1], [2]
    • CMAKE_GLOBAL_AUTOGEN_TARGET, [1], [2], [3], [4], [5], [6], [7]
    • CMAKE_GLOBAL_AUTOGEN_TARGET_NAME, [1], [2], [3], [4], [5]
    • CMAKE_GLOBAL_AUTORCC_TARGET, [1], [2], [3], [4], [5], [6]
    • CMAKE_GLOBAL_AUTORCC_TARGET_NAME, [1], [2], [3]
    • CMAKE_GNUtoMS, [1]
    • CMAKE_HOME_DIRECTORY
    • CMAKE_HOST_APPLE
    • CMAKE_HOST_SOLARIS, [1]
    • CMAKE_HOST_SYSTEM
    • CMAKE_HOST_SYSTEM_NAME, [1], [2], [3], [4], [5], [6]
    • CMAKE_HOST_SYSTEM_PROCESSOR, [1], [2], [3]
    • CMAKE_HOST_SYSTEM_VERSION, [1], [2], [3]
    • CMAKE_HOST_UNIX
    • CMAKE_HOST_WIN32
    • CMAKE_IGNORE_PATH, [1], [2]
    • CMAKE_IMPORT_LIBRARY_PREFIX
    • CMAKE_IMPORT_LIBRARY_SUFFIX
    • CMAKE_INCLUDE_CURRENT_DIR, [1]
    • CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE, [1], [2]
    • CMAKE_INCLUDE_DIRECTORIES_BEFORE, [1]
    • CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE
    • CMAKE_INCLUDE_PATH, [1], [2], [3], [4], [5], [6], [7]
    • CMAKE_INSTALL_DEFAULT_COMPONENT_NAME, [1]
    • CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS, [1], [2], [3], [4], [5], [6], [7]
    • CMAKE_INSTALL_MESSAGE, [1], [2], [3]
    • CMAKE_INSTALL_NAME_DIR, [1], [2]
    • CMAKE_INSTALL_PREFIX, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25]
    • CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, [1]
    • CMAKE_INSTALL_RPATH, [1], [2]
    • CMAKE_INSTALL_RPATH_USE_LINK_PATH
    • CMAKE_INTERNAL_PLATFORM_ABI
    • CMAKE_INTERPROCEDURAL_OPTIMIZATION, [1], [2], [3]
    • CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>, [1]
    • CMAKE_IOS_INSTALL_COMBINED, [1]
    • CMAKE_JOB_POOLS, [1], [2]
    • CMAKE_JOB_POOL_COMPILE, [1], [2]
    • CMAKE_JOB_POOL_LINK, [1], [2]
    • CMAKE_LIBRARY_ARCHITECTURE, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
    • CMAKE_LIBRARY_ARCHITECTURE_REGEX
    • CMAKE_LIBRARY_OUTPUT_DIRECTORY
    • CMAKE_LIBRARY_OUTPUT_DIRECTORY_<CONFIG>, [1]
    • CMAKE_LIBRARY_PATH, [1], [2], [3], [4], [5]
    • CMAKE_LIBRARY_PATH_FLAG
    • CMAKE_LINK_DEF_FILE_FLAG
    • CMAKE_LINK_DEPENDS_NO_SHARED
    • CMAKE_LINK_DIRECTORIES_BEFORE, [1]
    • CMAKE_LINK_INTERFACE_LIBRARIES, [1]
    • CMAKE_LINK_LIBRARY_FILE_FLAG
    • CMAKE_LINK_LIBRARY_FLAG
    • CMAKE_LINK_LIBRARY_SUFFIX
    • CMAKE_LINK_SEARCH_END_STATIC, [1], [2], [3]
    • CMAKE_LINK_SEARCH_START_STATIC, [1], [2], [3]
    • CMAKE_LINK_WHAT_YOU_USE, [1], [2]
    • CMAKE_MACOSX_BUNDLE, [1]
    • CMAKE_MACOSX_RPATH, [1]
    • CMAKE_MAJOR_VERSION, [1]
    • CMAKE_MAKE_PROGRAM, [1], [2], [3], [4], [5], [6]
    • CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>, [1], [2]
    • CMAKE_MATCH_<n>, [1], [2], [3]
    • CMAKE_MATCH_COUNT, [1], [2]
    • CMAKE_MAXIMUM_RECURSION_DEPTH, [1]
    • CMAKE_MFC_FLAG, [1]
    • CMAKE_MINIMUM_REQUIRED_VERSION, [1], [2], [3], [4]
    • CMAKE_MINOR_VERSION, [1]
    • CMAKE_MODULE_LINKER_FLAGS, [1], [2]
    • CMAKE_MODULE_LINKER_FLAGS_<CONFIG>, [1]
    • CMAKE_MODULE_LINKER_FLAGS_<CONFIG>_INIT, [1]
    • CMAKE_MODULE_LINKER_FLAGS_INIT, [1], [2], [3]
    • CMAKE_MODULE_PATH, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • CMAKE_MSVCIDE_RUN_PATH, [1]
    • CMAKE_NETRC, [1]
    • CMAKE_NETRC_FILE, [1]
    • CMAKE_NINJA_OUTPUT_PATH_PREFIX, [1]
    • CMAKE_NOT_USING_CONFIG_FLAGS
    • CMAKE_NO_BUILTIN_CHRPATH
    • CMAKE_NO_SYSTEM_FROM_IMPORTED, [1]
    • CMAKE_OBJECT_PATH_MAX
    • CMAKE_OSX_ARCHITECTURES, [1], [2], [3], [4], [5]
    • CMAKE_OSX_DEPLOYMENT_TARGET, [1], [2], [3], [4]
    • CMAKE_OSX_SYSROOT, [1], [2], [3], [4]
    • CMAKE_PARENT_LIST_FILE, [1]
    • CMAKE_PATCH_VERSION, [1]
    • CMAKE_PDB_OUTPUT_DIRECTORY, [1], [2]
    • CMAKE_PDB_OUTPUT_DIRECTORY_<CONFIG>, [1]
    • CMAKE_POLICY_DEFAULT_CMP<NNNN>, [1], [2], [3]
    • CMAKE_POLICY_WARNING_CMP<NNNN>, [1], [2], [3], [4], [5], [6], [7], [8]
    • CMAKE_POSITION_INDEPENDENT_CODE, [1], [2]
    • CMAKE_PREFIX_PATH, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16]
    • CMAKE_PROGRAM_PATH, [1], [2], [3], [4], [5]
    • CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE, [1]
    • CMAKE_PROJECT_DESCRIPTION, [1], [2], [3]
    • CMAKE_PROJECT_HOMEPAGE_URL, [1], [2], [3], [4], [5], [6], [7]
    • CMAKE_PROJECT_NAME, [1], [2], [3]
    • CMAKE_PROJECT_VERSION, [1], [2], [3], [4], [5], [6]
    • CMAKE_PROJECT_VERSION_MAJOR, [1], [2], [3]
    • CMAKE_PROJECT_VERSION_MINOR, [1], [2], [3]
    • CMAKE_PROJECT_VERSION_PATCH, [1], [2], [3]
    • CMAKE_PROJECT_VERSION_TWEAK, [1]
    • CMAKE_RANLIB, [1]
    • CMAKE_ROOT, [1]
    • CMAKE_RULE_MESSAGES, [1]
    • CMAKE_RUNTIME_OUTPUT_DIRECTORY, [1]
    • CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG>, [1]
    • CMAKE_SCRIPT_MODE_FILE
    • CMAKE_SHARED_LIBRARY_PREFIX
    • CMAKE_SHARED_LIBRARY_SUFFIX, [1]
    • CMAKE_SHARED_LINKER_FLAGS, [1], [2]
    • CMAKE_SHARED_LINKER_FLAGS_<CONFIG>, [1]
    • CMAKE_SHARED_LINKER_FLAGS_<CONFIG>_INIT, [1]
    • CMAKE_SHARED_LINKER_FLAGS_INIT, [1], [2], [3]
    • CMAKE_SHARED_MODULE_PREFIX
    • CMAKE_SHARED_MODULE_SUFFIX
    • CMAKE_SIZEOF_VOID_P, [1]
    • CMAKE_SKIP_BUILD_RPATH
    • CMAKE_SKIP_INSTALL_ALL_DEPENDENCY, [1]
    • CMAKE_SKIP_INSTALL_RPATH, [1], [2], [3]
    • CMAKE_SKIP_INSTALL_RULES
    • CMAKE_SKIP_RPATH, [1], [2], [3], [4]
    • CMAKE_SOURCE_DIR, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]
    • CMAKE_STAGING_PREFIX, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
    • CMAKE_STATIC_LIBRARY_PREFIX
    • CMAKE_STATIC_LIBRARY_SUFFIX
    • CMAKE_STATIC_LINKER_FLAGS, [1]
    • CMAKE_STATIC_LINKER_FLAGS_<CONFIG>, [1]
    • CMAKE_STATIC_LINKER_FLAGS_<CONFIG>_INIT, [1]
    • CMAKE_STATIC_LINKER_FLAGS_INIT, [1]
    • CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS, [1]
    • CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE, [1]
    • CMAKE_SUPPRESS_REGENERATION, [1]
    • CMAKE_SYSROOT, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29]
    • CMAKE_SYSROOT_COMPILE, [1], [2], [3]
    • CMAKE_SYSROOT_LINK, [1], [2], [3]
    • CMAKE_SYSTEM, [1], [2]
    • CMAKE_SYSTEM_APPBUNDLE_PATH, [1]
    • CMAKE_SYSTEM_FRAMEWORK_PATH, [1], [2], [3]
    • CMAKE_SYSTEM_IGNORE_PATH, [1]
    • CMAKE_SYSTEM_INCLUDE_PATH, [1], [2], [3], [4], [5]
    • CMAKE_SYSTEM_LIBRARY_PATH, [1], [2], [3], [4]
    • CMAKE_SYSTEM_NAME, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29]
    • CMAKE_SYSTEM_PREFIX_PATH, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]
    • CMAKE_SYSTEM_PROCESSOR, [1]
    • CMAKE_SYSTEM_PROGRAM_PATH, [1], [2], [3], [4]
    • CMAKE_SYSTEM_VERSION, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • CMAKE_Swift_LANGUAGE_VERSION, [1]
    • CMAKE_TOOLCHAIN_FILE, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30]
    • CMAKE_TRY_COMPILE_CONFIGURATION, [1], [2]
    • CMAKE_TRY_COMPILE_PLATFORM_VARIABLES, [1], [2]
    • CMAKE_TRY_COMPILE_TARGET_TYPE, [1], [2], [3], [4], [5], [6], [7], [8]
    • CMAKE_TWEAK_VERSION, [1]
    • CMAKE_USER_MAKE_RULES_OVERRIDE, [1]
    • CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>
    • CMAKE_USE_RELATIVE_PATHS, [1]
    • CMAKE_VERBOSE_MAKEFILE, [1]
    • CMAKE_VERSION, [1], [2], [3], [4], [5], [6], [7]
    • CMAKE_VISIBILITY_INLINES_HIDDEN, [1], [2]
    • CMAKE_VS_DEVENV_COMMAND, [1], [2]
    • CMAKE_VS_GLOBALS, [1]
    • CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD, [1], [2]
    • CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD, [1]
    • CMAKE_VS_INTEL_Fortran_PROJECT_VERSION
    • CMAKE_VS_MSBUILD_COMMAND, [1], [2]
    • CMAKE_VS_NsightTegra_VERSION
    • CMAKE_VS_PLATFORM_NAME, [1]
    • CMAKE_VS_PLATFORM_TOOLSET, [1]
    • CMAKE_VS_PLATFORM_TOOLSET_CUDA, [1]
    • CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE, [1]
    • CMAKE_VS_PLATFORM_TOOLSET_VERSION, [1]
    • CMAKE_VS_SDK_EXCLUDE_DIRECTORIES, [1]
    • CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES, [1]
    • CMAKE_VS_SDK_INCLUDE_DIRECTORIES, [1]
    • CMAKE_VS_SDK_LIBRARY_DIRECTORIES, [1]
    • CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES, [1]
    • CMAKE_VS_SDK_REFERENCE_DIRECTORIES, [1]
    • CMAKE_VS_SDK_SOURCE_DIRECTORIES, [1]
    • CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION, [1], [2], [3], [4]
    • CMAKE_VS_WINRT_BY_DEFAULT
    • CMAKE_WARN_DEPRECATED, [1], [2], [3], [4]
    • CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION, [1]
    • CMAKE_WIN32_EXECUTABLE, [1]
    • CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS, [1]
    • CMAKE_XCODE_ATTRIBUTE_<an-attribute>, [1]
    • CMAKE_XCODE_GENERATE_SCHEME, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35]
    • CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY, [1]
    • CMAKE_XCODE_PLATFORM_TOOLSET
    • CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER, [1]
    • CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN, [1]
    • CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER, [1]
    • CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS, [1]
    • CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE, [1]
    • CMAKE_XCODE_SCHEME_GUARD_MALLOC, [1]
    • CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP, [1]
    • CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES, [1]
    • CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE, [1]
    • CMAKE_XCODE_SCHEME_MALLOC_STACK, [1]
    • CMAKE_XCODE_SCHEME_THREAD_SANITIZER, [1]
    • CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP, [1]
    • CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER, [1]
    • CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP, [1]
    • CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS, [1]
    • CPACK_<GENNAME>_COMPONENT_INSTALL
    • CPACK_ABSOLUTE_DESTINATION_FILES
    • CPACK_ARCHIVE_<component>_FILE_NAME, [1]
    • CPACK_ARCHIVE_COMPONENT_INSTALL
    • CPACK_ARCHIVE_FILE_NAME, [1]
    • CPACK_BINARY_<GENNAME>, [1]
    • CPACK_BUILD_SOURCE_DIRS, [1], [2], [3]
    • CPACK_BUNDLE_APPLE_CERT_APP
    • CPACK_BUNDLE_APPLE_CODESIGN_FILES
    • CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER
    • CPACK_BUNDLE_APPLE_ENTITLEMENTS
    • CPACK_BUNDLE_ICON
    • CPACK_BUNDLE_NAME
    • CPACK_BUNDLE_PLIST
    • CPACK_BUNDLE_STARTUP_COMMAND
    • CPACK_CMAKE_GENERATOR
    • CPACK_COMMAND_CODESIGN
    • CPACK_COMMAND_HDIUTIL
    • CPACK_COMMAND_PKGBUILD
    • CPACK_COMMAND_PRODUCTBUILD
    • CPACK_COMMAND_REZ
    • CPACK_COMMAND_SETFILE
    • CPACK_COMPONENTS_ALL
    • CPACK_COMPONENTS_GROUPING, [1]
    • CPACK_COMPONENT_<COMPONENT>_DESCRIPTION
    • CPACK_COMPONENT_<compName>_DEPENDS, [1], [2]
    • CPACK_COMPONENT_<compName>_DESCRIPTION, [1], [2]
    • CPACK_COMPONENT_<compName>_DISABLED, [1]
    • CPACK_COMPONENT_<compName>_DISPLAY_NAME, [1]
    • CPACK_COMPONENT_<compName>_GROUP
    • CPACK_COMPONENT_<compName>_HIDDEN
    • CPACK_COMPONENT_<compName>_REQUIRED
    • CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY, [1]
    • CPACK_CREATE_DESKTOP_LINKS
    • CPACK_CYGWIN_BUILD_SCRIPT
    • CPACK_CYGWIN_PATCH_FILE
    • CPACK_CYGWIN_PATCH_NUMBER
    • CPACK_DEBIAN_<COMPONENT>_FILE_NAME, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_EXTRA
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_STRICT_PERMISSION
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS, [1], [2], [3]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_NAME
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION, [1]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS, [1], [2]
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SOURCE
    • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS, [1]
    • CPACK_DEBIAN_<component>_DEBUGINFO_PACKAGE
    • CPACK_DEBIAN_ARCHIVE_TYPE, [1], [2]
    • CPACK_DEBIAN_COMPRESSION_TYPE, [1]
    • CPACK_DEBIAN_DEBUGINFO_PACKAGE
    • CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS, [1]
    • CPACK_DEBIAN_FILE_NAME, [1], [2]
    • CPACK_DEBIAN_PACKAGE_ARCHITECTURE
    • CPACK_DEBIAN_PACKAGE_BREAKS, [1], [2]
    • CPACK_DEBIAN_PACKAGE_CONFLICTS, [1]
    • CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
    • CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION, [1]
    • CPACK_DEBIAN_PACKAGE_DEBUG
    • CPACK_DEBIAN_PACKAGE_DEPENDS, [1], [2], [3]
    • CPACK_DEBIAN_PACKAGE_DESCRIPTION, [1], [2]
    • CPACK_DEBIAN_PACKAGE_ENHANCES, [1]
    • CPACK_DEBIAN_PACKAGE_EPOCH, [1], [2]
    • CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS
    • CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY, [1]
    • CPACK_DEBIAN_PACKAGE_HOMEPAGE, [1]
    • CPACK_DEBIAN_PACKAGE_MAINTAINER
    • CPACK_DEBIAN_PACKAGE_NAME, [1]
    • CPACK_DEBIAN_PACKAGE_PREDEPENDS, [1]
    • CPACK_DEBIAN_PACKAGE_PRIORITY
    • CPACK_DEBIAN_PACKAGE_PROVIDES, [1]
    • CPACK_DEBIAN_PACKAGE_RECOMMENDS, [1]
    • CPACK_DEBIAN_PACKAGE_RELEASE, [1], [2], [3], [4]
    • CPACK_DEBIAN_PACKAGE_REPLACES, [1]
    • CPACK_DEBIAN_PACKAGE_SECTION
    • CPACK_DEBIAN_PACKAGE_SHLIBDEPS, [1], [2], [3]
    • CPACK_DEBIAN_PACKAGE_SOURCE, [1], [2]
    • CPACK_DEBIAN_PACKAGE_SUGGESTS, [1], [2]
    • CPACK_DEBIAN_PACKAGE_VERSION, [1]
    • CPACK_DEB_COMPONENT_INSTALL
    • CPACK_DMG_BACKGROUND_IMAGE, [1]
    • CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK, [1]
    • CPACK_DMG_DS_STORE
    • CPACK_DMG_DS_STORE_SETUP_SCRIPT, [1]
    • CPACK_DMG_FORMAT
    • CPACK_DMG_SLA_DIR, [1], [2]
    • CPACK_DMG_SLA_LANGUAGES, [1]
    • CPACK_DMG_VOLUME_NAME
    • CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION, [1]
    • CPACK_EXTERNAL_ENABLE_STAGING, [1]
    • CPACK_EXTERNAL_PACKAGE_SCRIPT, [1]
    • CPACK_EXTERNAL_REQUESTED_VERSIONS, [1], [2]
    • CPACK_FREEBSD_PACKAGE_CATEGORIES
    • CPACK_FREEBSD_PACKAGE_COMMENT
    • CPACK_FREEBSD_PACKAGE_DEPS
    • CPACK_FREEBSD_PACKAGE_DESCRIPTION
    • CPACK_FREEBSD_PACKAGE_LICENSE
    • CPACK_FREEBSD_PACKAGE_LICENSE_LOGIC
    • CPACK_FREEBSD_PACKAGE_MAINTAINER
    • CPACK_FREEBSD_PACKAGE_NAME
    • CPACK_FREEBSD_PACKAGE_ORIGIN
    • CPACK_FREEBSD_PACKAGE_WWW
    • CPACK_GENERATOR, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]
    • CPACK_IFW_ADMIN_TARGET_DIRECTORY
    • CPACK_IFW_BINARYCREATOR_EXECUTABLE
    • CPACK_IFW_DEVTOOL_EXECUTABLE
    • CPACK_IFW_DOWNLOAD_ALL, [1]
    • CPACK_IFW_FRAMEWORK_VERSION
    • CPACK_IFW_INSTALLERBASE_EXECUTABLE
    • CPACK_IFW_PACKAGES_DIRECTORIES
    • CPACK_IFW_PACKAGE_ALLOW_NON_ASCII_CHARACTERS
    • CPACK_IFW_PACKAGE_ALLOW_SPACE_IN_PATH
    • CPACK_IFW_PACKAGE_BACKGROUND, [1]
    • CPACK_IFW_PACKAGE_BANNER, [1]
    • CPACK_IFW_PACKAGE_CONTROL_SCRIPT
    • CPACK_IFW_PACKAGE_FILE_EXTENSION, [1]
    • CPACK_IFW_PACKAGE_GROUP
    • CPACK_IFW_PACKAGE_ICON
    • CPACK_IFW_PACKAGE_LOGO
    • CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_INI_FILE
    • CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_NAME
    • CPACK_IFW_PACKAGE_NAME, [1]
    • CPACK_IFW_PACKAGE_PUBLISHER
    • CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR, [1]
    • CPACK_IFW_PACKAGE_RESOURCES, [1]
    • CPACK_IFW_PACKAGE_START_MENU_DIRECTORY
    • CPACK_IFW_PACKAGE_TITLE
    • CPACK_IFW_PACKAGE_TITLE_COLOR, [1]
    • CPACK_IFW_PACKAGE_WATERMARK, [1]
    • CPACK_IFW_PACKAGE_WINDOW_ICON
    • CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT, [1]
    • CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH, [1]
    • CPACK_IFW_PACKAGE_WIZARD_STYLE, [1]
    • CPACK_IFW_PRODUCT_URL
    • CPACK_IFW_REPOGEN_EXECUTABLE
    • CPACK_IFW_REPOSITORIES_ALL, [1], [2]
    • CPACK_IFW_REPOSITORIES_DIRECTORIES, [1]
    • CPACK_IFW_RESOLVE_DUPLICATE_NAMES
    • CPACK_IFW_ROOT, [1], [2]
    • CPACK_IFW_TARGET_DIRECTORY
    • CPACK_IFW_VERBOSE
    • CPACK_INCLUDE_TOPLEVEL_DIRECTORY, [1], [2]
    • CPACK_INSTALLED_DIRECTORIES, [1]
    • CPACK_INSTALL_CMAKE_PROJECTS, [1], [2]
    • CPACK_INSTALL_COMMANDS
    • CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS, [1], [2]
    • CPACK_INSTALL_SCRIPT
    • CPACK_MONOLITHIC_INSTALL
    • CPACK_NSIS_<compName>_INSTALL_DIRECTORY, [1]
    • CPACK_NSIS_COMPRESSOR
    • CPACK_NSIS_CONTACT
    • CPACK_NSIS_CREATE_ICONS_EXTRA
    • CPACK_NSIS_DELETE_ICONS_EXTRA
    • CPACK_NSIS_DISPLAY_NAME
    • CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL, [1]
    • CPACK_NSIS_EXECUTABLES_DIRECTORY
    • CPACK_NSIS_EXTRA_INSTALL_COMMANDS
    • CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS
    • CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS
    • CPACK_NSIS_HELP_LINK
    • CPACK_NSIS_INSTALLED_ICON_NAME
    • CPACK_NSIS_INSTALLER_MUI_ICON_CODE
    • CPACK_NSIS_INSTALL_ROOT
    • CPACK_NSIS_MENU_LINKS
    • CPACK_NSIS_MODIFY_PATH
    • CPACK_NSIS_MUI_FINISHPAGE_RUN
    • CPACK_NSIS_MUI_ICON
    • CPACK_NSIS_MUI_UNIICON
    • CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP, [1]
    • CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP, [1]
    • CPACK_NSIS_PACKAGE_NAME
    • CPACK_NSIS_URL_INFO_ABOUT
    • CPACK_NUGET_<compName>_PACKAGE_AUTHORS
    • CPACK_NUGET_<compName>_PACKAGE_COPYRIGHT
    • CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES
    • CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES_<dependency>_VERSION
    • CPACK_NUGET_<compName>_PACKAGE_DESCRIPTION
    • CPACK_NUGET_<compName>_PACKAGE_DESCRIPTION_SUMMARY
    • CPACK_NUGET_<compName>_PACKAGE_HOMEPAGE_URL
    • CPACK_NUGET_<compName>_PACKAGE_ICONURL
    • CPACK_NUGET_<compName>_PACKAGE_LICENSEURL
    • CPACK_NUGET_<compName>_PACKAGE_NAME
    • CPACK_NUGET_<compName>_PACKAGE_OWNERS
    • CPACK_NUGET_<compName>_PACKAGE_RELEASE_NOTES
    • CPACK_NUGET_<compName>_PACKAGE_TAGS
    • CPACK_NUGET_<compName>_PACKAGE_TITLE
    • CPACK_NUGET_<compName>_PACKAGE_VERSION
    • CPACK_NUGET_COMPONENT_INSTALL
    • CPACK_NUGET_PACKAGE_AUTHORS
    • CPACK_NUGET_PACKAGE_COPYRIGHT
    • CPACK_NUGET_PACKAGE_DEBUG
    • CPACK_NUGET_PACKAGE_DEPENDENCIES
    • CPACK_NUGET_PACKAGE_DEPENDENCIES_<dependency>_VERSION
    • CPACK_NUGET_PACKAGE_DESCRIPTION
    • CPACK_NUGET_PACKAGE_DESCRIPTION_SUMMARY
    • CPACK_NUGET_PACKAGE_HOMEPAGE_URL
    • CPACK_NUGET_PACKAGE_ICONURL
    • CPACK_NUGET_PACKAGE_LICENSEURL
    • CPACK_NUGET_PACKAGE_NAME
    • CPACK_NUGET_PACKAGE_OWNERS
    • CPACK_NUGET_PACKAGE_RELEASE_NOTES
    • CPACK_NUGET_PACKAGE_TAGS
    • CPACK_NUGET_PACKAGE_TITLE
    • CPACK_NUGET_PACKAGE_VERSION
    • CPACK_OSX_PACKAGE_VERSION
    • CPACK_OUTPUT_CONFIG_FILE
    • CPACK_PACKAGE_CHECKSUM, [1]
    • CPACK_PACKAGE_DESCRIPTION, [1], [2]
    • CPACK_PACKAGE_DESCRIPTION_FILE, [1], [2], [3]
    • CPACK_PACKAGE_DESCRIPTION_SUMMARY, [1], [2], [3], [4], [5], [6]
    • CPACK_PACKAGE_DIRECTORY, [1]
    • CPACK_PACKAGE_EXECUTABLES, [1]
    • CPACK_PACKAGE_FILE_NAME
    • CPACK_PACKAGE_HOMEPAGE_URL, [1]
    • CPACK_PACKAGE_ICON
    • CPACK_PACKAGE_INSTALL_DIRECTORY, [1]
    • CPACK_PACKAGE_INSTALL_REGISTRY_KEY
    • CPACK_PACKAGE_NAME, [1], [2], [3], [4], [5], [6]
    • CPACK_PACKAGE_VENDOR, [1], [2], [3]
    • CPACK_PACKAGE_VERSION, [1], [2], [3], [4], [5], [6], [7]
    • CPACK_PACKAGE_VERSION_MAJOR, [1], [2]
    • CPACK_PACKAGE_VERSION_MINOR, [1], [2]
    • CPACK_PACKAGE_VERSION_PATCH, [1], [2]
    • CPACK_PACKAGING_INSTALL_PREFIX, [1], [2], [3], [4], [5], [6]
    • CPACK_PKGBUILD_IDENTITY_NAME, [1]
    • CPACK_PKGBUILD_KEYCHAIN_PATH, [1]
    • CPACK_POSTFLIGHT_<COMP>_SCRIPT
    • CPACK_PREFLIGHT_<COMP>_SCRIPT
    • CPACK_PRODUCTBUILD_IDENTITY_NAME, [1]
    • CPACK_PRODUCTBUILD_KEYCHAIN_PATH, [1]
    • CPACK_PRODUCTBUILD_RESOURCES_DIR, [1]
    • CPACK_PROJECT_CONFIG_FILE, [1], [2], [3], [4], [5], [6]
    • CPACK_RESOURCE_FILE_LICENSE, [1]
    • CPACK_RESOURCE_FILE_README, [1]
    • CPACK_RESOURCE_FILE_WELCOME, [1]
    • CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX, [1], [2]
    • CPACK_RPM_<COMPONENT>_USER_FILELIST
    • CPACK_RPM_<compName>_DEFAULT_DIR_PERMISSIONS
    • CPACK_RPM_<compName>_DEFAULT_FILE_PERMISSIONS
    • CPACK_RPM_<compName>_DEFAULT_GROUP
    • CPACK_RPM_<compName>_DEFAULT_USER
    • CPACK_RPM_<component>_BUILD_SOURCE_DIRS_PREFIX
    • CPACK_RPM_<component>_DEBUGINFO_FILE_NAME
    • CPACK_RPM_<component>_DEBUGINFO_PACKAGE, [1]
    • CPACK_RPM_<component>_FILE_NAME
    • CPACK_RPM_<component>_PACKAGE_ARCHITECTURE, [1]
    • CPACK_RPM_<component>_PACKAGE_AUTOPROV
    • CPACK_RPM_<component>_PACKAGE_AUTOREQ
    • CPACK_RPM_<component>_PACKAGE_AUTOREQPROV
    • CPACK_RPM_<component>_PACKAGE_CONFLICTS
    • CPACK_RPM_<component>_PACKAGE_DESCRIPTION, [1]
    • CPACK_RPM_<component>_PACKAGE_GROUP, [1]
    • CPACK_RPM_<component>_PACKAGE_NAME, [1], [2]
    • CPACK_RPM_<component>_PACKAGE_OBSOLETES
    • CPACK_RPM_<component>_PACKAGE_PROVIDES
    • CPACK_RPM_<component>_PACKAGE_REQUIRES
    • CPACK_RPM_<component>_PACKAGE_REQUIRES_POST
    • CPACK_RPM_<component>_PACKAGE_REQUIRES_POSTUN
    • CPACK_RPM_<component>_PACKAGE_REQUIRES_PRE
    • CPACK_RPM_<component>_PACKAGE_REQUIRES_PREUN
    • CPACK_RPM_<component>_PACKAGE_SUGGESTS
    • CPACK_RPM_<component>_PACKAGE_SUMMARY, [1]
    • CPACK_RPM_<component>_PACKAGE_URL
    • CPACK_RPM_<componentName>_USER_BINARY_SPECFILE
    • CPACK_RPM_ADDITIONAL_MAN_DIRS, [1]
    • CPACK_RPM_BUILDREQUIRES
    • CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX, [1]
    • CPACK_RPM_CHANGELOG_FILE
    • CPACK_RPM_COMPONENT_INSTALL, [1], [2]
    • CPACK_RPM_COMPRESSION_TYPE
    • CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS, [1]
    • CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS_ADDITION
    • CPACK_RPM_DEBUGINFO_FILE_NAME, [1]
    • CPACK_RPM_DEBUGINFO_PACKAGE, [1], [2], [3], [4]
    • CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE, [1], [2]
    • CPACK_RPM_DEFAULT_DIR_PERMISSIONS, [1]
    • CPACK_RPM_DEFAULT_FILE_PERMISSIONS, [1], [2]
    • CPACK_RPM_DEFAULT_GROUP, [1]
    • CPACK_RPM_DEFAULT_USER, [1]
    • CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST, [1]
    • CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION, [1]
    • CPACK_RPM_FILE_NAME, [1]
    • CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
    • CPACK_RPM_INSTALL_WITH_EXEC, [1]
    • CPACK_RPM_MAIN_COMPONENT, [1], [2]
    • CPACK_RPM_NO_<COMPONENT>_INSTALL_PREFIX_RELOCATION
    • CPACK_RPM_NO_INSTALL_PREFIX_RELOCATION
    • CPACK_RPM_PACKAGE_ARCHITECTURE
    • CPACK_RPM_PACKAGE_AUTOPROV, [1]
    • CPACK_RPM_PACKAGE_AUTOREQ, [1]
    • CPACK_RPM_PACKAGE_AUTOREQPROV
    • CPACK_RPM_PACKAGE_CONFLICTS
    • CPACK_RPM_PACKAGE_DEBUG
    • CPACK_RPM_PACKAGE_DESCRIPTION
    • CPACK_RPM_PACKAGE_EPOCH, [1]
    • CPACK_RPM_PACKAGE_GROUP
    • CPACK_RPM_PACKAGE_LICENSE, [1]
    • CPACK_RPM_PACKAGE_NAME, [1]
    • CPACK_RPM_PACKAGE_OBSOLETES
    • CPACK_RPM_PACKAGE_PROVIDES
    • CPACK_RPM_PACKAGE_RELEASE
    • CPACK_RPM_PACKAGE_RELEASE_DIST, [1], [2]
    • CPACK_RPM_PACKAGE_RELOCATABLE
    • CPACK_RPM_PACKAGE_REQUIRES
    • CPACK_RPM_PACKAGE_REQUIRES_POST, [1]
    • CPACK_RPM_PACKAGE_REQUIRES_POSTUN, [1]
    • CPACK_RPM_PACKAGE_REQUIRES_PRE, [1]
    • CPACK_RPM_PACKAGE_REQUIRES_PREUN, [1]
    • CPACK_RPM_PACKAGE_SOURCES, [1], [2], [3]
    • CPACK_RPM_PACKAGE_SUGGESTS
    • CPACK_RPM_PACKAGE_SUMMARY
    • CPACK_RPM_PACKAGE_URL
    • CPACK_RPM_PACKAGE_VENDOR
    • CPACK_RPM_PACKAGE_VERSION, [1]
    • CPACK_RPM_POST_INSTALL_SCRIPT_FILE, [1]
    • CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE
    • CPACK_RPM_PRE_INSTALL_SCRIPT_FILE
    • CPACK_RPM_PRE_UNINSTALL_SCRIPT_FILE
    • CPACK_RPM_RELOCATION_PATHS, [1], [2]
    • CPACK_RPM_SOURCE_PKG_BUILD_PARAMS, [1]
    • CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX, [1]
    • CPACK_RPM_SPEC_INSTALL_POST
    • CPACK_RPM_SPEC_MORE_DEFINE, [1]
    • CPACK_RPM_USER_BINARY_SPECFILE, [1]
    • CPACK_RPM_USER_FILELIST, [1]
    • CPACK_SET_DESTDIR, [1], [2], [3], [4]
    • CPACK_SOURCE_GENERATOR
    • CPACK_SOURCE_IGNORE_FILES
    • CPACK_SOURCE_OUTPUT_CONFIG_FILE
    • CPACK_SOURCE_PACKAGE_FILE_NAME
    • CPACK_SOURCE_STRIP_FILES
    • CPACK_STRIP_FILES, [1]
    • CPACK_SYSTEM_NAME
    • CPACK_TOPLEVEL_TAG
    • CPACK_VERBATIM_VARIABLES
    • CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION, [1]
    • CPACK_WIX_<TOOL>_EXTENSIONS
    • CPACK_WIX_<TOOL>_EXTRA_FLAGS
    • CPACK_WIX_CMAKE_PACKAGE_REGISTRY
    • CPACK_WIX_CULTURES
    • CPACK_WIX_EXTENSIONS
    • CPACK_WIX_EXTRA_OBJECTS
    • CPACK_WIX_EXTRA_SOURCES
    • CPACK_WIX_LICENSE_RTF
    • CPACK_WIX_PATCH_FILE, [1], [2]
    • CPACK_WIX_PRODUCT_GUID
    • CPACK_WIX_PRODUCT_ICON
    • CPACK_WIX_PROGRAM_MENU_FOLDER
    • CPACK_WIX_PROPERTY_<PROPERTY>
    • CPACK_WIX_ROOT
    • CPACK_WIX_ROOT_FEATURE_DESCRIPTION, [1]
    • CPACK_WIX_ROOT_FEATURE_TITLE, [1]
    • CPACK_WIX_ROOT_FOLDER_ID, [1]
    • CPACK_WIX_SKIP_PROGRAM_FOLDER, [1]
    • CPACK_WIX_TEMPLATE
    • CPACK_WIX_UI_BANNER
    • CPACK_WIX_UI_DIALOG
    • CPACK_WIX_UI_REF
    • CPACK_WIX_UPGRADE_GUID
    • CTEST_BINARY_DIRECTORY, [1], [2], [3], [4], [5], [6], [7]
    • CTEST_BUILD_COMMAND, [1], [2], [3]
    • CTEST_BUILD_NAME, [1]
    • CTEST_BZR_COMMAND, [1]
    • CTEST_BZR_UPDATE_OPTIONS, [1]
    • CTEST_CHANGE_ID
    • CTEST_CHECKOUT_COMMAND, [1], [2]
    • CTEST_CONFIGURATION_TYPE, [1]
    • CTEST_CONFIGURE_COMMAND, [1]
    • CTEST_COVERAGE_COMMAND, [1], [2]
    • CTEST_COVERAGE_EXTRA_FLAGS, [1]
    • CTEST_CURL_OPTIONS, [1]
    • CTEST_CUSTOM_COVERAGE_EXCLUDE
    • CTEST_CUSTOM_ERROR_EXCEPTION
    • CTEST_CUSTOM_ERROR_MATCH
    • CTEST_CUSTOM_ERROR_POST_CONTEXT
    • CTEST_CUSTOM_ERROR_PRE_CONTEXT
    • CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE, [1]
    • CTEST_CUSTOM_MAXIMUM_NUMBER_OF_ERRORS
    • CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS
    • CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE, [1]
    • CTEST_CUSTOM_MEMCHECK_IGNORE
    • CTEST_CUSTOM_POST_MEMCHECK
    • CTEST_CUSTOM_POST_TEST
    • CTEST_CUSTOM_PRE_MEMCHECK
    • CTEST_CUSTOM_PRE_TEST
    • CTEST_CUSTOM_TESTS_IGNORE
    • CTEST_CUSTOM_WARNING_EXCEPTION
    • CTEST_CUSTOM_WARNING_MATCH
    • CTEST_CVS_CHECKOUT, [1]
    • CTEST_CVS_COMMAND, [1]
    • CTEST_CVS_UPDATE_OPTIONS, [1]
    • CTEST_DROP_LOCATION, [1]
    • CTEST_DROP_METHOD, [1]
    • CTEST_DROP_SITE, [1]
    • CTEST_DROP_SITE_CDASH, [1]
    • CTEST_DROP_SITE_PASSWORD, [1]
    • CTEST_DROP_SITE_USER, [1]
    • CTEST_EXTRA_COVERAGE_GLOB, [1]
    • CTEST_GIT_COMMAND, [1]
    • CTEST_GIT_INIT_SUBMODULES, [1], [2]
    • CTEST_GIT_UPDATE_CUSTOM, [1]
    • CTEST_GIT_UPDATE_OPTIONS, [1]
    • CTEST_HG_COMMAND, [1]
    • CTEST_HG_UPDATE_OPTIONS, [1]
    • CTEST_LABELS_FOR_SUBPROJECTS, [1], [2], [3], [4]
    • CTEST_MEMORYCHECK_COMMAND, [1]
    • CTEST_MEMORYCHECK_COMMAND_OPTIONS, [1]
    • CTEST_MEMORYCHECK_SANITIZER_OPTIONS, [1], [2], [3]
    • CTEST_MEMORYCHECK_SUPPRESSIONS_FILE, [1], [2]
    • CTEST_MEMORYCHECK_TYPE, [1]
    • CTEST_NIGHTLY_START_TIME, [1]
    • CTEST_P4_CLIENT, [1]
    • CTEST_P4_COMMAND, [1]
    • CTEST_P4_OPTIONS, [1]
    • CTEST_P4_UPDATE_OPTIONS, [1]
    • CTEST_RUN_CURRENT_SCRIPT, [1], [2]
    • CTEST_SCP_COMMAND, [1]
    • CTEST_SITE, [1]
    • CTEST_SOURCE_DIRECTORY, [1], [2], [3], [4], [5]
    • CTEST_SUBMIT_URL, [1], [2], [3]
    • CTEST_SVN_COMMAND, [1]
    • CTEST_SVN_OPTIONS, [1]
    • CTEST_SVN_UPDATE_OPTIONS, [1]
    • CTEST_TEST_LOAD, [1], [2], [3]
    • CTEST_TEST_TIMEOUT, [1], [2], [3]
    • CTEST_TRIGGER_SITE, [1]
    • CTEST_UPDATE_COMMAND, [1]
    • CTEST_UPDATE_OPTIONS, [1]
    • CTEST_UPDATE_VERSION_ONLY, [1]
    • CTEST_USE_LAUNCHERS, [1], [2], [3]
    • CYGWIN, [1]
    • DOXYGEN_DOT_EXECUTABLE
    • DOXYGEN_DOT_FOUND
    • DOXYGEN_DOT_MULTI_TARGETS
    • DOXYGEN_DOT_PATH
    • DOXYGEN_EXCLUDE_PATTERNS
    • DOXYGEN_EXECUTABLE
    • DOXYGEN_FOUND
    • DOXYGEN_GENERATE_LATEX
    • DOXYGEN_HAVE_DOT
    • DOXYGEN_INPUT
    • DOXYGEN_OUTPUT_DIRECTORY
    • DOXYGEN_PROJECT_BRIEF
    • DOXYGEN_PROJECT_NAME
    • DOXYGEN_PROJECT_NUMBER
    • DOXYGEN_RECURSIVE
    • DOXYGEN_SKIP_DOT
    • DOXYGEN_VERSION
    • DOXYGEN_WARN_FORMAT
    • ENV
    • EXECUTABLE_OUTPUT_PATH
    • ExternalData_BINARY_ROOT
    • ExternalData_CUSTOM_ERROR
    • ExternalData_CUSTOM_FILE
    • ExternalData_CUSTOM_LOCATION
    • ExternalData_CUSTOM_SCRIPT_<key>
    • ExternalData_LINK_CONTENT
    • ExternalData_NO_SYMLINKS, [1]
    • ExternalData_OBJECT_STORES
    • ExternalData_SERIES_MATCH
    • ExternalData_SERIES_PARSE
    • ExternalData_SERIES_PARSE_NUMBER
    • ExternalData_SERIES_PARSE_PREFIX
    • ExternalData_SERIES_PARSE_SUFFIX
    • ExternalData_SOURCE_ROOT
    • ExternalData_TIMEOUT_ABSOLUTE
    • ExternalData_TIMEOUT_INACTIVITY
    • ExternalData_URL_ALGO_<algo>_<key>, [1]
    • ExternalData_URL_TEMPLATES
    • FeatureSummary_<TYPE>_DESCRIPTION, [1], [2]
    • FeatureSummary_DEFAULT_PKG_TYPE, [1], [2], [3]
    • FeatureSummary_PKG_TYPES, [1], [2], [3], [4], [5]
    • FeatureSummary_REQUIRED_PKG_TYPES, [1], [2], [3], [4]
    • GHS-MULTI
    • GRAPHVIZ_EXECUTABLES
    • GRAPHVIZ_EXTERNAL_LIBS
    • GRAPHVIZ_GENERATE_DEPENDERS
    • GRAPHVIZ_GENERATE_PER_TARGET
    • GRAPHVIZ_GRAPH_HEADER
    • GRAPHVIZ_GRAPH_NAME
    • GRAPHVIZ_GRAPH_TYPE
    • GRAPHVIZ_IGNORE_TARGETS
    • GRAPHVIZ_MODULE_LIBS
    • GRAPHVIZ_NODE_PREFIX
    • GRAPHVIZ_SHARED_LIBS
    • GRAPHVIZ_STATIC_LIBS
    • IOS
    • Iconv::Iconv
    • Iconv_FOUND
    • Iconv_INCLUDE_DIR
    • Iconv_INCLUDE_DIRS
    • Iconv_IS_BUILT_IN
    • Iconv_LIBRARIES
    • Iconv_LIBRARY
    • LIBRARY_OUTPUT_PATH
    • MATLAB_ADDITIONAL_VERSIONS, [1], [2]
    • MATLAB_FIND_DEBUG, [1], [2]
    • MINGW
    • MSVC
    • MSVC10
    • MSVC11
    • MSVC12
    • MSVC14
    • MSVC60
    • MSVC70
    • MSVC71
    • MSVC80
    • MSVC90
    • MSVC_IDE
    • MSVC_TOOLSET_VERSION, [1], [2]
    • MSVC_VERSION, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]
    • MSYS
    • Matlab_ROOT_DIR, [1], [2], [3]
    • ODBC::ODBC
    • ODBC_CONFIG, [1]
    • ODBC_FOUND
    • ODBC_INCLUDE_DIR
    • ODBC_INCLUDE_DIRS
    • ODBC_LIBRARIES
    • ODBC_LIBRARY
    • PKG_CONFIG_EXECUTABLE
    • PKG_CONFIG_USE_CMAKE_PREFIX_PATH, [1]
    • PROJECT_BINARY_DIR, [1], [2]
    • PROJECT_DESCRIPTION, [1], [2], [3], [4], [5]
    • PROJECT_HOMEPAGE_URL, [1], [2], [3]
    • PROJECT_NAME, [1], [2], [3], [4]
    • PROJECT_SOURCE_DIR, [1], [2], [3]
    • PROJECT_VERSION, [1], [2], [3], [4], [5], [6], [7], [8], [9]
    • PROJECT_VERSION_MAJOR, [1], [2]
    • PROJECT_VERSION_MINOR, [1], [2]
    • PROJECT_VERSION_PATCH, [1], [2]
    • PROJECT_VERSION_TWEAK, [1], [2]
    • QTIFWDIR, [1]
    • UNIX
    • WIN32
    • WINCE
    • WINDOWS_PHONE
    • WINDOWS_STORE
    • XCODE
    • XCODE_VERSION
    • XCTest_EXECUTABLE
    • XCTest_FOUND
    • XCTest_INCLUDE_DIRS
    • XCTest_LIBRARIES
  • variable_requires
    • command, [1], [2]
  • variable_watch
    • command, [1], [2]
  • VARIABLES
    • directory property, [1]
  • VERBOSE
    • envvar, [1], [2]
  • VERSION
    • target property, [1], [2], [3], [4]
  • VISIBILITY_INLINES_HIDDEN
    • target property, [1], [2], [3], [4], [5], [6], [7]
  • Visual Studio 10 2010
    • generator, [1], [2], [3], [4]
  • Visual Studio 11 2012
    • generator, [1]
  • Visual Studio 12 2013
    • generator, [1]
  • Visual Studio 14 2015
    • generator, [1], [2], [3], [4], [5]
  • Visual Studio 15 2017
    • generator, [1], [2], [3], [4]
  • Visual Studio 16 2019
    • generator, [1]
  • Visual Studio 6
    • generator, [1], [2]
  • Visual Studio 7
    • generator, [1], [2]
  • Visual Studio 7 .NET 2003
    • generator, [1], [2]
  • Visual Studio 8 2005
    • generator, [1], [2], [3]
  • Visual Studio 9 2008
    • generator, [1], [2], [3], [4], [5], [6], [7], [8]
  • VS_CONFIGURATION_TYPE
    • target property, [1]
  • VS_COPY_TO_OUT_DIR
    • source file property, [1]
  • VS_CSHARP_<tagname>
    • source file property, [1], [2], [3], [4], [5]
  • VS_DEBUGGER_COMMAND
    • target property, [1], [2]
  • VS_DEBUGGER_COMMAND_ARGUMENTS
    • target property, [1]
  • VS_DEBUGGER_ENVIRONMENT
    • target property, [1]
  • VS_DEBUGGER_WORKING_DIRECTORY
    • target property, [1], [2]
  • VS_DEPLOYMENT_CONTENT
    • source file property, [1], [2]
  • VS_DEPLOYMENT_LOCATION
    • source file property, [1]
  • VS_DESKTOP_EXTENSIONS_VERSION
    • target property
  • VS_DOTNET_REFERENCE_<refname>
    • target property, [1], [2], [3]
  • VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname>
    • target property, [1]
  • VS_DOTNET_REFERENCES
    • target property, [1], [2], [3]
  • VS_DOTNET_REFERENCES_COPY_LOCAL
    • target property, [1], [2]
  • VS_DOTNET_TARGET_FRAMEWORK_VERSION
    • target property, [1]
  • VS_GLOBAL_<variable>
    • target property, [1], [2], [3]
  • VS_GLOBAL_KEYWORD
    • target property, [1]
  • VS_GLOBAL_PROJECT_TYPES
    • target property
  • VS_GLOBAL_ROOTNAMESPACE
    • target property
  • VS_GLOBAL_SECTION_POST_<section>
    • directory property
  • VS_GLOBAL_SECTION_PRE_<section>
    • directory property
  • VS_INCLUDE_IN_VSIX
    • source file property, [1]
  • VS_IOT_EXTENSIONS_VERSION
    • target property
  • VS_IOT_STARTUP_TASK
    • target property
  • VS_KEYWORD
    • target property, [1]
  • VS_MOBILE_EXTENSIONS_VERSION
    • target property
  • VS_RESOURCE_GENERATOR
    • source file property, [1]
  • VS_SCC_AUXPATH
    • target property
  • VS_SCC_LOCALPATH
    • target property
  • VS_SCC_PROJECTNAME
    • target property
  • VS_SCC_PROVIDER
    • target property
  • VS_SDK_REFERENCES
    • target property, [1]
  • VS_SHADER_DISABLE_OPTIMIZATIONS
    • source file property, [1], [2]
  • VS_SHADER_ENABLE_DEBUG
    • source file property, [1], [2]
  • VS_SHADER_ENTRYPOINT
    • source file property, [1]
  • VS_SHADER_FLAGS
    • source file property, [1]
  • VS_SHADER_MODEL
    • source file property, [1]
  • VS_SHADER_OBJECT_FILE_NAME
    • source file property, [1]
  • VS_SHADER_OUTPUT_HEADER_FILE
    • source file property, [1]
  • VS_SHADER_TYPE
    • source file property, [1]
  • VS_SHADER_VARIABLE_NAME
    • source file property, [1]
  • VS_STARTUP_PROJECT
    • directory property, [1]
  • VS_TOOL_OVERRIDE
    • source file property, [1]
  • VS_USER_PROPS
    • target property, [1]
  • VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION
    • target property
  • VS_WINRT_COMPONENT
    • target property, [1], [2]
  • VS_WINRT_EXTENSIONS
    • target property
  • VS_WINRT_REFERENCES
    • target property
  • VS_XAML_TYPE
    • source file property

W

  • Watcom WMake
    • generator
  • while
    • command, [1], [2], [3], [4], [5]
  • WILL_FAIL
    • test property, [1]
  • WIN32
    • variable
  • WIN32_EXECUTABLE
    • target property, [1], [2], [3], [4], [5]
  • WINCE
    • variable
  • WINDOWS_EXPORT_ALL_SYMBOLS
    • target property, [1], [2], [3], [4]
  • WINDOWS_PHONE
    • variable
  • WINDOWS_STORE
    • variable
  • WORKING_DIRECTORY
    • test property, [1], [2]
  • WRAP_EXCLUDE
    • source file property
  • write_basic_package_version_file
    • command, [1], [2], [3], [4], [5]
  • write_file
    • command
  • WriteBasicConfigVersionFile
    • module
  • WriteCompilerDetectionHeader
    • module, [1], [2], [3], [4], [5], [6]

X

  • XCODE
    • variable
  • Xcode
    • generator, [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37]
  • XCODE_ATTRIBUTE_<an-attribute>
    • target property, [1], [2]
  • XCODE_EMIT_EFFECTIVE_PLATFORM_NAME
    • global property, [1]
  • XCODE_EXPLICIT_FILE_TYPE
    • source file property, [1], [2]
    • target property, [1], [2]
  • XCODE_FILE_ATTRIBUTES
    • source file property, [1]
  • XCODE_LAST_KNOWN_FILE_TYPE
    • source file property, [1], [2]
  • XCODE_PRODUCT_TYPE
    • target property, [1], [2]
  • XCODE_SCHEME_ADDRESS_SANITIZER
    • target property, [1], [2]
  • XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
    • target property, [1], [2]
  • XCODE_SCHEME_ARGUMENTS
    • target property, [1]
  • XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
    • target property, [1], [2]
  • XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
    • target property, [1], [2]
  • XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
    • target property, [1], [2]
  • XCODE_SCHEME_ENVIRONMENT
    • target property, [1]
  • XCODE_SCHEME_EXECUTABLE
    • target property, [1]
  • XCODE_SCHEME_GUARD_MALLOC
    • target property, [1], [2]
  • XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP
    • target property, [1], [2]
  • XCODE_SCHEME_MALLOC_GUARD_EDGES
    • target property, [1], [2]
  • XCODE_SCHEME_MALLOC_SCRIBBLE
    • target property, [1], [2]
  • XCODE_SCHEME_MALLOC_STACK
    • target property, [1], [2]
  • XCODE_SCHEME_THREAD_SANITIZER
    • target property, [1], [2]
  • XCODE_SCHEME_THREAD_SANITIZER_STOP
    • target property, [1], [2]
  • XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER
    • target property, [1], [2]
  • XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP
    • target property, [1], [2]
  • XCODE_SCHEME_ZOMBIE_OBJECTS
    • target property, [1], [2]
  • XCODE_VERSION
    • variable
  • XCTEST
    • target property, [1]
  • xctest_add_bundle
    • command, [1]
  • xctest_add_test
    • command
  • XCTest_EXECUTABLE
    • variable
  • XCTest_FOUND
    • variable
  • XCTest_INCLUDE_DIRS
    • variable
  • XCTest_LIBRARIES
    • variable