code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>install — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="link_directories" href="link_directories.html" />
    <link rel="prev" title="include_regular_expression" href="include_regular_expression.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

install

install¶

Contents

install

Synopsis

Introduction

Signatures

Examples

Example: Install Targets with Per-Artifact Components

Example: Install Targets to Per-Config Destinations

Generated Installation Script

Specify rules to run at install time.

Synopsis¶

install(TARGETS <target>... [...])
install(IMPORTED_RUNTIME_ARTIFACTS <target>... [...])
install({FILES | PROGRAMS} <file>... [...])
install(DIRECTORY <dir>... [...])
install(SCRIPT <file> [...])
install(CODE <code> [...])
install(EXPORT <export-name> [...])
install(RUNTIME_DEPENDENCY_SET <set-name> [...])

Introduction¶

This command generates installation rules for a project.  Install rules
specified by calls to the install() command within a source directory
are executed in order during installation.

Changed in version 3.14: Install rules in subdirectories
added by calls to the add_subdirectory() command are interleaved
with those in the parent directory to run in the order declared (see
policy CMP0082).

Changed in version 3.22: The environment variable CMAKE_INSTALL_MODE can override the
default copying behavior of install().

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

Specify the directory on disk to which a file will be installed.
<dir> should be a relative path.  An absolute path is allowed,
but not recommended.

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

As absolute paths do not work with the cmake --install command's
--prefix option, or with the
cpack installer generators, it is strongly recommended
to use relative paths throughout for best support by package maintainers.
In particular, there is no need to make paths absolute by prepending
CMAKE_INSTALL_PREFIX; this prefix is used by default if
the DESTINATION is a relative path.

If an absolute path (with a leading slash or drive letter) is given
it is used verbatim.

PERMISSIONS <permission>...

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.

If this option is used multiple times in a single call, its list
of permissions accumulates.  If an install(TARGETS) call
uses <artifact-kind> arguments, a separate list of permissions
is accumulated for each kind of artifact.

CONFIGURATIONS <config>...

Specify a list of build configurations for which the install rule
applies (Debug, Release, etc.).

If this option is used multiple times in a single call, its list
of configurations accumulates.  If an install(TARGETS)
call uses <artifact-kind> arguments, a separate list of
configurations is accumulated for each kind of artifact.

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

New in version 3.6.

Specify that the file is excluded from a full installation and only
installed as part of a component-specific installation

RENAME <name>

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.

New in version 3.1: Command signatures that install files may print messages during
installation.  Use the CMAKE_INSTALL_MESSAGE variable
to control which messages are printed.

New in version 3.11: 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.

Signatures¶

install(TARGETS <target>... [...])¶

Install target Output Artifacts and associated files:

install(TARGETS <target>... [EXPORT <export-name>]
        [RUNTIME_DEPENDENCIES <arg>...|RUNTIME_DEPENDENCY_SET <set-name>]
        [<artifact-option>...]
        [<artifact-kind> <artifact-option>...]...
        [INCLUDES DESTINATION [<dir> ...]]
        )

where <artifact-option>... group may contain:

[DESTINATION <dir>]
[PERMISSIONS <permission>...]
[CONFIGURATIONS <config>...]
[COMPONENT <component>]
[NAMELINK_COMPONENT <component>]
[OPTIONAL] [EXCLUDE_FROM_ALL]
[NAMELINK_ONLY|NAMELINK_SKIP]

The first <artifact-option>... group applies to target
Output Artifacts that do not have a dedicated group specified
later in the same call.

Each <artifact-kind> <artifact-option>... group applies to
Output Artifacts of the specified artifact kind:

ARCHIVE

Target artifacts of this kind include:

Static libraries
(except on macOS when marked as FRAMEWORK, see below);

DLL import libraries
(on all Windows-based systems including Cygwin; they have extension
.lib, in contrast to the .dll libraries that go to RUNTIME);

On AIX, the linker import file created for executables with
ENABLE_EXPORTS enabled.

On macOS, the linker import file created for shared libraries with
ENABLE_EXPORTS enabled (except when marked as FRAMEWORK,
see below).

LIBRARY

Target artifacts of this kind include:

Shared libraries, except

DLLs (these go to RUNTIME, see below),

on macOS when marked as FRAMEWORK (see below).

RUNTIME

Target artifacts of this kind include:

Executables
(except on macOS when marked as MACOSX_BUNDLE, see BUNDLE below);

DLLs (on all Windows-based systems including Cygwin; note that the
accompanying import libraries are of kind ARCHIVE).

OBJECTS

New in version 3.9.

Object files associated with object libraries.

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.

FILE_SET <set-name>

New in version 3.23.

File sets are defined by the target_sources(FILE_SET) command.
If the file set <set-name> exists and is PUBLIC or INTERFACE,
any files in the set are installed under the destination (see below).
The directory structure relative to the file set's base directories is
preserved. For example, a file added to the file set as
/blah/include/myproj/here.h with a base directory /blah/include
would be installed to myproj/here.h below the destination.

CXX_MODULES_BMI

New in version 3.28.

Any module files from C++ modules from PUBLIC sources in a file set of
type CXX_MODULES will be installed to the given DESTINATION. All
modules are placed directly in the destination as no directory structure is
derived from the names of the modules. An empty DESTINATION may be used
to suppress installing these files (for use in generic code).

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 file
sets, and 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).

For shared libraries on DLL platforms, if neither RUNTIME nor ARCHIVE
destinations are specified, both the RUNTIME and ARCHIVE components are
installed to their default destinations. If either a RUNTIME or ARCHIVE
destination is specified, the component is installed to that destination, and
the other component is not installed. If both RUNTIME and ARCHIVE
destinations are specified, then both components are installed to their
respective destinations.

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

FILE_SET (type HEADERS)

${CMAKE_INSTALL_INCLUDEDIR}

include

Projects wishing to follow the common practice of installing headers into a
project-specific subdirectory may prefer using file sets with appropriate
paths and base directories. Otherwise, they must provide a DESTINATION
instead of being able to rely on the above (see next example below).

To make packages compliant with distribution filesystem layout policies, if
projects must specify a DESTINATION, it is strongly recommended that they use
a path that begins with the appropriate relative 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 without using file sets:

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

New in version 3.12.

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.

Changed in version 3.27: This parameter is also usable for an ARCHIVE block to manage
the linker import file created, on macOS, for shared libraries with
ENABLE_EXPORTS enabled.

See the Example: Install Targets with Per-Artifact Components
for an example using NAMELINK_COMPONENT.

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.

Changed in version 3.27: This parameter is also usable for an ARCHIVE block to manage
the linker import file created, on macOS, for shared libraries with
ENABLE_EXPORTS enabled.

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.

Changed in version 3.27: This parameter is also usable for an ARCHIVE block to manage
the linker import file created, on macOS, for shared libraries with
ENABLE_EXPORTS enabled.

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.
See documentation of the EXPORT_NAME target property to change
the name of the exported target.

If EXPORT is used and the targets include PUBLIC or INTERFACE
file sets, all of them must be specified with FILE_SET arguments. All
PUBLIC or INTERFACE file sets associated with a target are included
in the export.

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

RUNTIME_DEPENDENCY_SET <set-name>

New in version 3.21.

This option causes all runtime dependencies of installed executable, shared
library, and module targets to be added to the specified runtime dependency
set. This set can then be installed with an
install(RUNTIME_DEPENDENCY_SET) command.

This keyword and the RUNTIME_DEPENDENCIES keyword are mutually
exclusive.

RUNTIME_DEPENDENCIES <arg>...

New in version 3.21.

This option causes all runtime dependencies of installed executable, shared
library, and module targets to be installed along with the targets
themselves. The RUNTIME, LIBRARY, FRAMEWORK, and generic
arguments are used to determine the properties (DESTINATION,
COMPONENT, etc.) of the installation of these dependencies.

RUNTIME_DEPENDENCIES is semantically equivalent to the following pair
of calls:

install(TARGETS ... RUNTIME_DEPENDENCY_SET <set-name>)
install(RUNTIME_DEPENDENCY_SET <set-name> <arg>...)

where <set-name> will be a randomly generated set name.
<arg>... may include any of the following keywords supported by
the install(RUNTIME_DEPENDENCY_SET) command:

DIRECTORIES

PRE_INCLUDE_REGEXES

PRE_EXCLUDE_REGEXES

POST_INCLUDE_REGEXES

POST_EXCLUDE_REGEXES

POST_INCLUDE_FILES

POST_EXCLUDE_FILES

The RUNTIME_DEPENDENCIES and RUNTIME_DEPENDENCY_SET keywords are
mutually exclusive.

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.

New in version 3.3: 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.

New in version 3.13: 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.

install(IMPORTED_RUNTIME_ARTIFACTS <target>... [...])¶

New in version 3.21.

Install runtime artifacts of imported targets:

install(IMPORTED_RUNTIME_ARTIFACTS <target>...
        [RUNTIME_DEPENDENCY_SET <set-name>]
        [[LIBRARY|RUNTIME|FRAMEWORK|BUNDLE]
         [DESTINATION <dir>]
         [PERMISSIONS <permission>...]
         [CONFIGURATIONS <config>...]
         [COMPONENT <component>]
         [OPTIONAL] [EXCLUDE_FROM_ALL]
        ] [...]
        )

The IMPORTED_RUNTIME_ARTIFACTS form specifies rules for installing the
runtime artifacts of imported targets. Projects may do this if they want to
bundle outside executables or modules inside their installation. The
LIBRARY, RUNTIME, FRAMEWORK, and BUNDLE arguments have the
same semantics that they do in the TARGETS mode. Only the runtime artifacts
of imported targets are installed (except in the case of FRAMEWORK
libraries, MACOSX_BUNDLE executables, and BUNDLE
CFBundles.) For example, headers and import libraries associated with DLLs are
not installed. In the case of FRAMEWORK libraries,
MACOSX_BUNDLE executables, and BUNDLE CFBundles, the
entire directory is installed.

The RUNTIME_DEPENDENCY_SET option causes the runtime artifacts of the
imported executable, shared library, and module library targets to be
added to the <set-name> runtime dependency set. This set can then be
installed with an install(RUNTIME_DEPENDENCY_SET) command.

install(FILES <file>... [...])¶

install(PROGRAMS <program>... [...])¶

Note

If installing header files, consider using file sets defined by
target_sources(FILE_SET) instead. File sets associate
headers with a target and they install as part of the target.

Install files or programs:

install(<FILES|PROGRAMS> <file>...
        TYPE <type> | DESTINATION <dir>
        [PERMISSIONS <permission>...]
        [CONFIGURATIONS <config>...]
        [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. Using file sets for headers instead of install(FILES)
would be even better (see target_sources(FILE_SET)).

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 strongly recommended that they use
a path that begins with the appropriate relative 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 an image to a project-specific documentation
subdirectory:

include(GNUInstallDirs)
install(FILES logo.png
        DESTINATION ${CMAKE_INSTALL_DOCDIR}/myproj
)

New in version 3.4: 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.

New in version 3.20: An install rename given as a RENAME argument may
use "generator expressions" with the syntax $<...>.  See the
cmake-generator-expressions(7) manual for available expressions.

install(DIRECTORY <dir>... [...])¶

Note

To install a directory sub-tree of headers, consider using file sets
defined by target_sources(FILE_SET) instead. File sets not only
preserve directory structure, they also associate headers with a target
and install as part of the target.

Install the contents of one or more directories:

install(DIRECTORY dirs...
        TYPE <type> | DESTINATION <dir>
        [FILE_PERMISSIONS <permission>...]
        [DIRECTORY_PERMISSIONS <permission>...]
        [USE_SOURCE_PERMISSIONS] [OPTIONAL] [MESSAGE_NEVER]
        [CONFIGURATIONS <config>...]
        [COMPONENT <component>] [EXCLUDE_FROM_ALL]
        [FILES_MATCHING]
        [[PATTERN <pattern> | REGEX <regex>]
         [EXCLUDE] [PERMISSIONS <permission>...]] [...])

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.

New in version 3.1: 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 doc/myproj
        FILES_MATCHING PATTERN "*.png")

will extract and install images from a source tree.

Some options may follow a PATTERN or REGEX expression as described
under string(REGEX) 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 strongly recommended that they use
a path that begins with the appropriate relative GNUInstallDirs variable.
This allows package maintainers to control the install destination by setting
the appropriate cache variables.

New in version 3.4: 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.

New in version 3.5: The list of dirs... given to DIRECTORY may use
"generator expressions" too.

install(SCRIPT <file> [...])¶

install(CODE <code> [...])¶

Invoke CMake scripts or code during installation:

install([[SCRIPT <file>] [CODE <code>]]
        [ALL_COMPONENTS | 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.

New in version 3.21: When the ALL_COMPONENTS option is given, the custom installation
script code will be executed for every component of a component-specific
installation.  This option is mutually exclusive with the COMPONENT
option.

New in version 3.14: <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.

install(EXPORT <export-name> [...])¶

Install a CMake file exporting targets for dependent projects:

install(EXPORT <export-name> DESTINATION <dir>
        [NAMESPACE <namespace>] [FILE <name>.cmake]
        [PERMISSIONS <permission>...]
        [CONFIGURATIONS <config>...]
        [CXX_MODULES_DIRECTORY <directory>]
        [EXPORT_LINK_INTERFACE_LIBRARIES]
        [COMPONENT <component>]
        [EXCLUDE_FROM_ALL]
        [EXPORT_PACKAGE_DEPENDENCIES])
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.  See the CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>
variable to map configurations of dependent projects to the installed
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.

Note

The installed <export-name>.cmake file may come with additional
per-configuration <export-name>-*.cmake files to be loaded by
globbing.  Do not use an export name that is the same as the package
name in combination with installing a <package-name>-config.cmake
file or the latter may be incorrectly matched by the glob and loaded.

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.

New in version 3.7: In addition to cmake language files, the EXPORT_ANDROID_MK mode may be
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.

CXX_MODULES_DIRECTORY

New in version 3.28.

Specify a subdirectory to store C++ module information for targets in the
export set. This directory will be populated with files which add the
necessary target property information to the relevant targets. Note that
without this information, none of the C++ modules which are part of the
targets in the export set will support being imported in consuming targets.

EXPORT_PACKAGE_DEPENDENCIES

New in version 3.29.

Specify that find_dependency() calls should be exported. If this
argument is specified, CMake examines all targets in the export set and
gathers their INTERFACE link targets. If any such targets either were
found with find_package() or have the
EXPORT_FIND_PACKAGE_NAME property set, and such package
dependency was not disabled by passing ENABLED OFF to
export(SETUP), then a find_dependency() call is
written with the target's corresponding package name, a REQUIRED
argument, and any additional arguments specified by the EXTRA_ARGS
argument of export(SETUP). Any package dependencies that were
manually specified by passing ENABLED ON to export(SETUP)
are also added, even if the exported targets don't depend on any targets
from them.

The find_dependency() calls are written in the following order:

Any package dependencies that were listed in export(SETUP)
are written in the order they were first specified, regardless of
whether or not they contain INTERFACE dependencies of the
exported targets.

Any package dependencies that contain INTERFACE link dependencies
of the exported targets and that were never specified in
export(SETUP) are written in the order they were first
found.

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

install(RUNTIME_DEPENDENCY_SET <set-name> [...])¶

New in version 3.21.

Installs a runtime dependency set:

install(RUNTIME_DEPENDENCY_SET <set-name>
        [[LIBRARY|RUNTIME|FRAMEWORK]
         [DESTINATION <dir>]
         [PERMISSIONS <permission>...]
         [CONFIGURATIONS <config>...]
         [COMPONENT <component>]
         [NAMELINK_COMPONENT <component>]
         [OPTIONAL] [EXCLUDE_FROM_ALL]
        ] [...]
        [PRE_INCLUDE_REGEXES <regex>...]
        [PRE_EXCLUDE_REGEXES <regex>...]
        [POST_INCLUDE_REGEXES <regex>...]
        [POST_EXCLUDE_REGEXES <regex>...]
        [POST_INCLUDE_FILES <file>...]
        [POST_EXCLUDE_FILES <file>...]
        [DIRECTORIES <dir>...]
        )

Installs a runtime dependency set previously created by one or more
install(TARGETS) or install(IMPORTED_RUNTIME_ARTIFACTS)
commands.  The dependencies of targets belonging to a runtime dependency set
are installed in the RUNTIME destination and component on DLL platforms,
and in the LIBRARY destination and component on non-DLL platforms.
macOS frameworks are installed in the FRAMEWORK destination and component.
Targets built within the build tree will never be installed as runtime
dependencies, nor will their own dependencies, unless the targets themselves
are installed with install(TARGETS).

The generated install script calls file(GET_RUNTIME_DEPENDENCIES)
on the build-tree files to calculate the runtime dependencies. The build-tree
executable files are passed as the EXECUTABLES argument, the build-tree
shared libraries as the LIBRARIES argument, and the build-tree modules as
the MODULES argument. On macOS, if one of the executables is a
MACOSX_BUNDLE, that executable is passed as the
BUNDLE_EXECUTABLE argument. At most one such bundle executable may be in
the runtime dependency set on macOS. The MACOSX_BUNDLE property
has no effect on other platforms. Note that
file(GET_RUNTIME_DEPENDENCIES) only supports collecting the runtime
dependencies for Windows, Linux and macOS platforms, so
install(RUNTIME_DEPENDENCY_SET) has the same limitation.

The following sub-arguments are forwarded through as the corresponding
arguments to file(GET_RUNTIME_DEPENDENCIES) (for those that provide
a non-empty list of directories, regular expressions or files).  They all
support generator expressions.

DIRECTORIES <dir>...

PRE_INCLUDE_REGEXES <regex>...

PRE_EXCLUDE_REGEXES <regex>...

POST_INCLUDE_REGEXES <regex>...

POST_EXCLUDE_REGEXES <regex>...

POST_INCLUDE_FILES <file>...

POST_EXCLUDE_FILES <file>...

Examples¶

Example: Install Targets with Per-Artifact Components¶

Consider a project that defines targets with different artifact kinds:

add_executable(myExe myExe.c)
add_library(myStaticLib STATIC myStaticLib.c)
target_sources(myStaticLib PUBLIC FILE_SET HEADERS FILES myStaticLib.h)
add_library(mySharedLib SHARED mySharedLib.c)
target_sources(mySharedLib PUBLIC FILE_SET HEADERS FILES mySharedLib.h)
set_property(TARGET mySharedLib PROPERTY SOVERSION 1)

We may call install(TARGETS) with <artifact-kind> arguments
to specify different options for each kind of artifact:

install(TARGETS
          myExe
          mySharedLib
          myStaticLib
        RUNTIME           # Following options apply to runtime artifacts.
          COMPONENT Runtime
        LIBRARY           # Following options apply to library artifacts.
          COMPONENT Runtime
          NAMELINK_COMPONENT Development
        ARCHIVE           # Following options apply to archive artifacts.
          COMPONENT Development
          DESTINATION lib/static
        FILE_SET HEADERS  # Following options apply to file set HEADERS.
          COMPONENT Development
        )

This will:

Install myExe to <prefix>/bin, the default RUNTIME artifact
destination, as part of the Runtime component.

On non-DLL platforms:

Install libmySharedLib.so.1 to <prefix>/lib, the default
LIBRARY artifact destination, as part of the Runtime component.

Install the libmySharedLib.so "namelink" (symbolic link) to
<prefix>/lib, the default LIBRARY artifact destination, as part
of the Development component.

On DLL platforms:

Install mySharedLib.dll to <prefix>/bin, the default RUNTIME
artifact destination, as part of the Runtime component.

Install mySharedLib.lib to <prefix>/lib/static, the specified
ARCHIVE artifact destination, as part of the Development component.

Install myStaticLib to <prefix>/lib/static, the specified
ARCHIVE artifact destination, as part of the Development component.

Install mySharedLib.h and myStaticLib.h to <prefix>/include,
the default destination for a file set of type HEADERS, as part of the
Development component.

Example: Install Targets to Per-Config Destinations¶

Each install(TARGETS) call installs a given target
output artifact to at most one DESTINATION,
but the install rule itself may be filtered by the CONFIGURATIONS option.
In order to install to a different destination for each configuration, one
call per configuration is needed.  For example, the code:

install(TARGETS myExe
        CONFIGURATIONS Debug
        RUNTIME
          DESTINATION Debug/bin
        )
install(TARGETS myExe
        CONFIGURATIONS Release
        RUNTIME
          DESTINATION Release/bin
        )

will install myExe to <prefix>/Debug/bin in the Debug configuration,
and to <prefix>/Release/bin in the Release configuration.

Generated Installation Script¶

Note

Use of this feature is not recommended. Please consider using the
cmake --install instead.

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.

Table of Contents

install

Synopsis

Introduction

Signatures

Examples

Example: Install Targets with Per-Artifact Components

Example: Install Targets to Per-Config Destinations

Generated Installation Script

Previous topic

include_regular_expression

Next topic

link_directories

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

install

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>install_files — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="install_programs" href="install_programs.html" />
    <link rel="prev" title="export_library_dependencies" href="export_library_dependencies.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

install_files

install_files¶

Deprecated since version 3.0: Use the install(FILES) command instead.

This command has been superseded 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.

Previous topic

export_library_dependencies

Next topic

install_programs

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

install_files

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>install_programs — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="install_targets" href="install_targets.html" />
    <link rel="prev" title="install_files" href="install_files.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

install_programs

install_programs¶

Deprecated since version 3.0: Use the install(PROGRAMS) command instead.

This command has been superseded 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.

Previous topic

install_files

Next topic

install_targets

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

install_programs

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>install_targets — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="load_command" href="load_command.html" />
    <link rel="prev" title="install_programs" href="install_programs.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

install_targets

install_targets¶

Deprecated since version 3.0: Use the install(TARGETS) command instead.

This command has been superseded 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.

Previous topic

install_programs

Next topic

load_command

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

install_targets

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>link_directories — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="link_libraries" href="link_libraries.html" />
    <link rel="prev" title="install" href="install.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

link_directories

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 command will apply only to targets created after it is called.

New in version 3.13: The directories are added to the LINK_DIRECTORIES directory
property for the current CMakeLists.txt file, converting relative
paths to absolute as needed.  See the cmake-buildsystem(7)
manual for more on defining buildsystem properties.

New in version 3.13: 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.

New in version 3.13: Arguments to link_directories may use "generator expressions" with
the syntax "$<...>".  See the cmake-generator-expressions(7)
manual for available expressions.

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.

See Also¶

target_link_directories()

target_link_libraries()

Table of Contents

link_directories

See Also

Previous topic

install

Next topic

link_libraries

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

link_directories

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>link_libraries — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="load_cache" href="load_cache.html" />
    <link rel="prev" title="link_directories" href="link_directories.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

link_libraries

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.

Previous topic

link_directories

Next topic

load_cache

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

link_libraries

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>load_cache — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="project" href="project.html" />
    <link rel="prev" title="link_libraries" href="link_libraries.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

load_cache

load_cache¶

Load in the values from another project's CMake cache.

load_cache(pathToBuildDirectory 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(pathToBuildDirectory [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.

Previous topic

link_libraries

Next topic

project

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

load_cache

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>load_command — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="make_directory" href="make_directory.html" />
    <link rel="prev" title="install_targets" href="install_targets.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

load_command

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.

Previous topic

install_targets

Next topic

make_directory

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

load_command

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>macro — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="mark_as_advanced" href="mark_as_advanced.html" />
    <link rel="prev" title="list" href="list.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

macro

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()
cmake_language(CALL 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.

New in version 3.18: The cmake_language(CALL ...) command can also be used to
invoke the macro.

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.

Unlike a function, the CMAKE_CURRENT_FUNCTION,
CMAKE_CURRENT_FUNCTION_LIST_DIR,
CMAKE_CURRENT_FUNCTION_LIST_FILE,
CMAKE_CURRENT_FUNCTION_LIST_LINE variables are not
set for a macro.

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.

See Also¶

cmake_parse_arguments()

endmacro()

Table of Contents

macro

Invocation

Arguments

Macro vs Function

Argument Caveats

See Also

Previous topic

list

Next topic

mark_as_advanced

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

macro

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>make_directory — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="output_required_files" href="output_required_files.html" />
    <link rel="prev" title="load_command" href="load_command.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

make_directory

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.

Previous topic

load_command

Next topic

output_required_files

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

make_directory

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>mark_as_advanced — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="math" href="math.html" />
    <link rel="prev" title="macro" href="macro.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

mark_as_advanced

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.

Changed in version 3.17: Variables passed to this command which are not already in the cache
are ignored. See policy CMP0102.

Previous topic

macro

Next topic

math

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

mark_as_advanced

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>math — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="message" href="message.html" />
    <link rel="prev" title="mark_as_advanced" href="mark_as_advanced.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

math

math¶

Evaluate a mathematical expression.

math(EXPR <variable> "<expression>" [OUTPUT_FORMAT <format>])

Evaluates a mathematical <expression> and sets <variable> to the
resulting value.  The result of the expression must be representable as a
64-bit signed integer. Floating point inputs are invalid e.g. 1.1 * 10.
Non-integer results e.g. 3 / 2 are truncated.

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.

New in version 3.13: Hexadecimal numbers are recognized when prefixed with 0x, as in C code.

New in version 3.13: 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"

Previous topic

mark_as_advanced

Next topic

message

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

math

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>message — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="option" href="option.html" />
    <link rel="prev" title="math" href="math.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

message

message¶

Log a message.

Synopsis¶

General messages
  message([<mode>] "message text" ...)

Reporting checks
  message(<checkState> "message text" ...)

Configure Log
  message(CONFIGURE_LOG <text>...)

General messages¶

message([<mode>] "message text" ...)

Record the specified message text in the log.  If more than one message
string is given, they are concatenated into a single message with no
separator between the strings.

The optional <mode> keyword determines the type of message, which
influences the way the message is handled:

FATAL_ERROR

CMake Error, stop processing and generation.

The cmake(1) executable will return a non-zero
exit code.

SEND_ERROR

CMake Error, continue processing, but skip generation.

WARNING

CMake Warning, continue processing.

AUTHOR_WARNING

CMake Warning (dev), continue processing.

DEPRECATION

CMake Deprecation Error or Warning if variable
CMAKE_ERROR_DEPRECATED or CMAKE_WARN_DEPRECATED
is enabled, respectively, else no message.

(none) or NOTICE

Important message printed to stderr to attract user's attention.

STATUS

The main interesting messages that project users might be interested in.
Ideally these should be concise, no more than a single line, but still
informative.

VERBOSE

Detailed informational messages intended for project users.  These messages
should provide additional details that won't be of interest in most cases,
but which may be useful to those building the project when they want deeper
insight into what's happening.

DEBUG

Detailed informational messages intended for developers working on the
project itself as opposed to users who just want to build it.  These messages
will not typically be of interest to other users building the project and
will often be closely related to internal implementation details.

TRACE

Fine-grained messages with very low-level implementation details.  Messages
using this log level would normally only be temporary and would expect to be
removed before releasing the project, packaging up the files, etc.

New in version 3.15: Added the NOTICE, VERBOSE, DEBUG, and TRACE levels.

The CMake command-line tool displays STATUS to TRACE messages on stdout
with the message preceded by two hyphens and a space.  All other message types
are sent to stderr and are not prefixed with hyphens.  The
CMake GUI displays all messages in its log area.
The curses interface shows STATUS to TRACE
messages one at a time on a status line and other messages in an
interactive pop-up box.  The --log-level
command-line option to each of these tools can be used to control which
messages will be shown.

New in version 3.17: To make a log level persist between CMake runs, the
CMAKE_MESSAGE_LOG_LEVEL variable can be set instead.
Note that the command line option takes precedence over the cache variable.

New in version 3.16: Messages of log levels NOTICE and below will have each line preceded
by the content of the CMAKE_MESSAGE_INDENT variable (converted to
a single string by concatenating its list items).  For STATUS to TRACE
messages, this indenting content will be inserted after the hyphens.

New in version 3.17: Messages of log levels NOTICE and below can also have each line preceded
with context of the form [some.context.example].  The content between the
square brackets is obtained by converting the CMAKE_MESSAGE_CONTEXT
list variable to a dot-separated string.  The message context will always
appear before any indenting content but after any automatically added leading
hyphens. By default, message context is not shown, it has to be explicitly
enabled by giving the cmake --log-context
command-line option or by setting the CMAKE_MESSAGE_CONTEXT_SHOW
variable to true.  See the CMAKE_MESSAGE_CONTEXT documentation for
usage examples.

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.

Reporting checks¶

New in version 3.17.

A common pattern in CMake output is a message indicating the start of some
sort of check, followed by another message reporting the result of that check.
For example:

message(STATUS "Looking for someheader.h")
#... do the checks, set checkSuccess with the result
if(checkSuccess)
  message(STATUS "Looking for someheader.h - found")
else()
  message(STATUS "Looking for someheader.h - not found")
endif()

This can be more robustly and conveniently expressed using the CHECK_...
keyword form of the message() command:

message(<checkState> "message" ...)

where <checkState> must be one of the following:

CHECK_START

Record a concise message about the check about to be performed.

CHECK_PASS

Record a successful result for a check.

CHECK_FAIL

Record an unsuccessful result for a check.

When recording a check result, the command repeats the message from the most
recently started check for which no result has yet been reported, then some
separator characters and then the message text provided after the
CHECK_PASS or CHECK_FAIL keyword.  Check messages are always reported
at STATUS log level.

Checks may be nested and every CHECK_START should have exactly one
matching CHECK_PASS or CHECK_FAIL.
The CMAKE_MESSAGE_INDENT variable can also be used to add
indenting to nested checks if desired.  For example:

message(CHECK_START "Finding my things")
list(APPEND CMAKE_MESSAGE_INDENT "  ")
unset(missingComponents)

message(CHECK_START "Finding partA")
# ... do check, assume we find A
message(CHECK_PASS "found")

message(CHECK_START "Finding partB")
# ... do check, assume we don't find B
list(APPEND missingComponents B)
message(CHECK_FAIL "not found")

list(POP_BACK CMAKE_MESSAGE_INDENT)
if(missingComponents)
  message(CHECK_FAIL "missing components: ${missingComponents}")
else()
  message(CHECK_PASS "all components found")
endif()

Output from the above would appear something like the following:

-- Finding my things
--   Finding partA
--   Finding partA - found
--   Finding partB
--   Finding partB - not found
-- Finding my things - missing components: B

Configure Log¶

New in version 3.26.

message(CONFIGURE_LOG <text>...)

Record a configure-log message event
with the specified <text>.  By convention, if the text contains more
than one line, the first line should be a summary of the event.

This mode is intended to record the details of a system inspection check
or other one-time operation guarded by a cache entry, but that is not
performed using try_compile() or try_run(), which
automatically log their details.  Projects should avoid calling it every
time CMake runs.  For example:

if (NOT DEFINED MY_CHECK_RESULT)
  # Print check summary in configure output.
  message(CHECK_START "My Check")

  # ... perform system inspection, e.g., with execute_process ...

  # Cache the result so we do not run the check again.
  set(MY_CHECK_RESULT "${MY_CHECK_RESULT}" CACHE INTERNAL "My Check")

  # Record the check details in the cmake-configure-log.
  message(CONFIGURE_LOG
    "My Check Result: ${MY_CHECK_RESULT}\n"
    "${details}"
  )

  # Print check result in configure output.
  if(MY_CHECK_RESULT)
    message(CHECK_PASS "passed")
  else()
    message(CHECK_FAIL "failed")
  endif()
endif()

If no project is currently being configured, such as in
cmake -P script mode,
this command does nothing.

See Also¶

cmake_language(GET_MESSAGE_LOG_LEVEL)

Table of Contents

message

Synopsis

General messages

Reporting checks

Configure Log

See Also

Previous topic

math

Next topic

option

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

message

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>option — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="return" href="return.html" />
    <link rel="prev" title="message" href="message.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

option

option¶

Provide a boolean option that the user can optionally select.

option(<variable> "<help_text>" [value])

If no initial <value> is provided, boolean OFF is the default value.
If <variable> is already set as a normal or cache variable,
then the command does nothing (see policy CMP0077).

For options that depend on the values of other options, see
the module help for CMakeDependentOption.

In CMake project mode, a boolean cache variable is created with the option
value. In CMake script mode, a boolean variable is set with the option value.

Previous topic

message

Next topic

return

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

option

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>output_required_files — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="qt_wrap_cpp" href="qt_wrap_cpp.html" />
    <link rel="prev" title="make_directory" href="make_directory.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

output_required_files

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.

Previous topic

make_directory

Next topic

qt_wrap_cpp

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

output_required_files

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>project — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="remove_definitions" href="remove_definitions.html" />
    <link rel="prev" title="load_cache" href="load_cache.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

project

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

Absolute path to the source directory for the project.

PROJECT_BINARY_DIR, <PROJECT-NAME>_BINARY_DIR

Absolute path to the binary directory for the project.

PROJECT_IS_TOP_LEVEL, <PROJECT-NAME>_IS_TOP_LEVEL

New in version 3.21.

Boolean value indicating whether the project is top-level.

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.

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.

New in version 3.12: 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>

New in version 3.9.

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.

New in version 3.12: Added the <PROJECT-NAME>_DESCRIPTION variable.

HOMEPAGE_URL <url-string>

New in version 3.12.

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 are C, CXX (i.e.  C++), CSharp (i.e.  C#), CUDA,
OBJC (i.e. Objective-C), OBJCXX (i.e. Objective-C++), Fortran, HIP,
ISPC, Swift, ASM, ASM_NASM, ASM_MARMASM, ASM_MASM, and ASM-ATT.

New in version 3.8: Added CSharp and CUDA support.

New in version 3.15: Added Swift support.

New in version 3.16: Added OBJC and OBJCXX support.

New in version 3.18: Added ISPC support.

New in version 3.21: Added HIP support.

New in version 3.26: Added ASM_MARMASM support.

If enabling ASM, list it last so that CMake can check whether
compilers for other languages like C work for assembly too.

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.

The variables set through the VERSION, DESCRIPTION and HOMEPAGE_URL
options are intended for use as default values in package metadata and documentation.

Code Injection¶

A number of variables can be defined by the user to specify files to include
at different points during the execution of the project() command.
The following outlines the steps performed during a project() call:

New in version 3.15: For every project() call regardless of the project
name, include the file named by CMAKE_PROJECT_INCLUDE_BEFORE,
if set.

New in version 3.17: If the project() command specifies <PROJECT-NAME> as its project
name, include the file named by
CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE, if set.

Set the various project-specific variables detailed in the Synopsis
and Options sections above.

For the very first project() call only:

If CMAKE_TOOLCHAIN_FILE is set, read it at least once.
It may be read multiple times and it may also be read again when
enabling languages later (see below).

Set the variables describing the host and target platforms.
Language-specific variables might or might not be set at this point.
On the first run, the only language-specific variables that might be
defined are those a toolchain file may have set. On subsequent runs,
language-specific variables cached from a previous run may be set.

New in version 3.24: Include each file listed in CMAKE_PROJECT_TOP_LEVEL_INCLUDES,
if set. The variable is ignored by CMake thereafter.

Enable any languages specified in the call, or the default languages if
none were provided. The toolchain file may be re-read when enabling a
language for the first time.

New in version 3.15: For every project() call regardless of the project
name, include the file named by CMAKE_PROJECT_INCLUDE,
if set.

If the project() command specifies <PROJECT-NAME> as its project
name, include the file named by
CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE, if set.

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 issue a warning and pretend there is a
project(Project) at the top to enable the default languages
(C and CXX).

Note

Call the project() command near the top of the top-level
CMakeLists.txt, but after calling cmake_minimum_required().
It is important to establish version and policy settings before invoking
other commands whose behavior they may affect and for this reason the
project() command will issue a warning if this order is not kept.
See also policy CMP0000.

Table of Contents

project

Synopsis

Options

Code Injection

Usage

Previous topic

load_cache

Next topic

remove_definitions

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

project

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>qt_wrap_cpp — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="qt_wrap_ui" href="qt_wrap_ui.html" />
    <link rel="prev" title="output_required_files" href="output_required_files.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

qt_wrap_cpp

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.

Previous topic

output_required_files

Next topic

qt_wrap_ui

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-commands(7) »

qt_wrap_cpp

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.