install¶
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(PACKAGE_INFO <package-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()
.
Changed in version 3.31: Projects can enable INSTALL_PARALLEL
to enable a parallel
installation. When using the parallel install, subdirectories added by calls
to the add_subdirectory()
command are installed independently
and the order that install rules added in different subdirectories will run is
not guaranteed.
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 theDESTDIR
mechanism explained in theCMAKE_INSTALL_PREFIX
variable documentation.As absolute paths do not work with the
cmake --install
command's--prefix
option, or with thecpack
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 prependingCMAKE_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.
Changed in version 3.31:
<dir>
will be normalized according to the same normalization rules as thecmake_path()
command.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
, andSETGID
. 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
orDevelopment
. 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 withEXCLUDE_FROM_ALL
. IfCOMPONENT
is not provided a default component "Unspecified" is created. The default component name may be controlled with theCMAKE_INSTALL_DEFAULT_COMPONENT_NAME
variable.EXCLUDE_FROM_ALL
Added in version 3.6.
Specify that the file is excluded from a full installation and only installed as part of a component-specific installation
OPTIONAL
Specify that it is not an error if the file to be installed does not exist.
Added 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.
Added 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 toRUNTIME
);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 asFRAMEWORK
, 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
, seeBUNDLE
below);DLLs (on all Windows-based systems including Cygwin; note that the accompanying import libraries are of kind
ARCHIVE
).
OBJECTS
Added in version 3.9.
Object files associated with object libraries.
FRAMEWORK
Both static and shared libraries marked with the
FRAMEWORK
property are treated asFRAMEWORK
targets on macOS.BUNDLE
Executables marked with the
MACOSX_BUNDLE
property are treated asBUNDLE
targets on macOS.PUBLIC_HEADER
Any
PUBLIC_HEADER
files associated with a library are installed in the destination specified by thePUBLIC_HEADER
argument on non-Apple platforms. Rules defined by this argument are ignored forFRAMEWORK
libraries on Apple platforms because the associated files are installed into the appropriate locations inside the framework folder. SeePUBLIC_HEADER
for details.PRIVATE_HEADER
Similar to
PUBLIC_HEADER
, but forPRIVATE_HEADER
files. SeePRIVATE_HEADER
for details.RESOURCE
Similar to
PUBLIC_HEADER
andPRIVATE_HEADER
, but forRESOURCE
files. SeeRESOURCE
for details.FILE_SET <set-name>
Added in version 3.23.
File sets are defined by the
target_sources(FILE_SET)
command. If the file set<set-name>
exists and isPUBLIC
orINTERFACE
, 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 tomyproj/here.h
below the destination.CXX_MODULES_BMI
Added in version 3.28.
Any module files from C++ modules from
PUBLIC
sources in a file set of typeCXX_MODULES
will be installed to the givenDESTINATION
. All modules are placed directly in the destination as no directory structure is derived from the names of the modules. An emptyDESTINATION
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, whenDESTINATION
is omitted, a default destination will be taken from the appropriate variable fromGNUInstallDirs
, 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 thePUBLIC_HEADER
andPRIVATE_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
norARCHIVE
destinations are specified, both theRUNTIME
andARCHIVE
components are installed to their default destinations. If either aRUNTIME
orARCHIVE
destination is specified, the component is installed to that destination, and the other component is not installed. If bothRUNTIME
andARCHIVE
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
(typeHEADERS
)${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 relativeGNUInstallDirs
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 byGNUInstallDirs
, 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
Added 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 andlib<name>.so
is a "namelink" allowing linkers to find the library when given-l<name>
. TheNAMELINK_COMPONENT
option is similar to theCOMPONENT
option, but it changes the installation component of a shared library namelink if one is generated. If not specified, this defaults to the value ofCOMPONENT
. It is an error to use this parameter outside of aLIBRARY
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 withENABLE_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
andSOVERSION
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 aLIBRARY
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 withENABLE_EXPORTS
enabled.When
NAMELINK_ONLY
is given, eitherNAMELINK_COMPONENT
orCOMPONENT
may be used to specify the installation component of the namelink, butCOMPONENT
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 neitherNAMELINK_ONLY
orNAMELINK_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 aLIBRARY
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 withENABLE_EXPORTS
enabled.If
NAMELINK_SKIP
is specified,NAMELINK_COMPONENT
has no effect. It is not recommended to useNAMELINK_SKIP
in conjunction withNAMELINK_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, callinstall(EXPORT)
, documented below. See documentation of theEXPORT_NAME
target property to change the name of the exported target.If
EXPORT
is used and the targets includePUBLIC
orINTERFACE
file sets, all of them must be specified withFILE_SET
arguments. AllPUBLIC
orINTERFACE
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 theinstall(EXPORT)
command. If a relative path is specified, it is treated as relative to the$<INSTALL_PREFIX>
.Unlike other
DESTINATION
arguments for the variousinstall()
subcommands, paths given afterINCLUDES DESTINATION
are used as given. They are not normalized, nor assumed to be normalized, although it is recommended that they are given in normalized form (see Normalization).RUNTIME_DEPENDENCY_SET <set-name>
Added 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>...
Added 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 theinstall(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
andRUNTIME_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 toTRUE
has undefined behavior.Added in version 3.3: An install destination given as a
DESTINATION
argument may use "generator expressions" with the syntax$<...>
. See thecmake-generator-expressions(7)
manual for available expressions.Added in version 3.13:
install(TARGETS)
can install targets that were created in other directories. When using such cross-directory install rules, runningmake install
(or similar) from a subdirectory will not guarantee that targets from other directories are up-to-date. You can usetarget_link_libraries()
oradd_dependencies()
to ensure that such out-of-directory targets are built before the subdirectory-specific install rules are run.
- install(IMPORTED_RUNTIME_ARTIFACTS <target>... [...])¶
Added 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. TheLIBRARY
,RUNTIME
,FRAMEWORK
, andBUNDLE
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 ofFRAMEWORK
libraries,MACOSX_BUNDLE
executables, andBUNDLE
CFBundles.) For example, headers and import libraries associated with DLLs are not installed. In the case ofFRAMEWORK
libraries,MACOSX_BUNDLE
executables, andBUNDLE
CFBundles, the entire directory is installed.The
RUNTIME_DEPENDENCY_SET
option causes the runtime artifacts of the imported executable, shared library, and module librarytargets
to be added to the<set-name>
runtime dependency set. This set can then be installed with aninstall(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 permissionsOWNER_WRITE
,OWNER_READ
,GROUP_READ
, andWORLD_READ
if noPERMISSIONS
argument is given.The
PROGRAMS
form is identical to theFILES
form except that the default permissions for the installed file also includeOWNER_EXECUTE
,GROUP_EXECUTE
, andWORLD_EXECUTE
. This form is intended to install programs that are not targets, such as shell scripts. Use theTARGETS
form to install targets built within the project.The list of
files...
given toFILES
orPROGRAMS
may use "generator expressions" with the syntax$<...>
. See thecmake-generator-expressions(7)
manual for available expressions. However, if any item begins in a generator expression it must evaluate to a full path.The optional
RENAME <name>
argument is used to specify a name for the installed file that is different from the original file name. Renaming is allowed only when a single file is installed by the command.Either a
TYPE
or aDESTINATION
must be provided, but not both. ATYPE
argument specifies the generic file type of the files being installed. A destination will then be set automatically by taking the corresponding variable fromGNUInstallDirs
, 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 aDESTINATION
argument instead of a file type if they wish to explicitly define the install destination.TYPE
ArgumentGNUInstallDirs 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
LIBEXEC
${CMAKE_INSTALL_LIBEXECDIR}
libexec
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 (seetarget_sources(FILE_SET)
).Note that some of the types' built-in defaults use the
DATAROOT
directory as a prefix. TheDATAROOT
prefix is calculated similarly to the types, withCMAKE_INSTALL_DATAROOTDIR
as the variable andshare
as the built-in default. You cannot useDATAROOT
as aTYPE
parameter; please useDATA
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 relativeGNUInstallDirs
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 )
Added in version 3.4: An install destination given as a
DESTINATION
argument may use "generator expressions" with the syntax$<...>
. See thecmake-generator-expressions(7)
manual for available expressions.Added in version 3.20: An install rename given as a
RENAME
argument may use "generator expressions" with the syntax$<...>
. See thecmake-generator-expressions(7)
manual for available expressions.Added in version 3.31: The
TYPE
argument now supports typeLIBEXEC
.
- 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. TheFILE_PERMISSIONS
andDIRECTORY_PERMISSIONS
options specify permissions given to files and directories in the destination. IfUSE_SOURCE_PERMISSIONS
is specified andFILE_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 theFILES
form of the command, and the directories will be given the default permissions specified in thePROGRAMS
form of the command.Added 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
orREGEX
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. APATTERN
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. AREGEX
will match any portion of the full path but it may use/
and$
to simulate thePATTERN
behavior. By default all files and directories are installed whether or not they are matched. TheFILES_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 codeinstall(DIRECTORY src/ DESTINATION doc/myproj FILES_MATCHING PATTERN "*.png")
will extract and install images from a source tree.
Some options may follow a
PATTERN
orREGEX
expression as described under string(REGEX) and are applied only to files or directories matching them. TheEXCLUDE
option will skip the matched file or directory. ThePERMISSIONS
option overrides the permissions setting for the matched file or directory. For example the codeinstall(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 toshare/myproj/icons
and thescripts
directory toshare/myproj
. The icons will get default file permissions, the scripts will be given specific permissions, and anyCVS
directories will be excluded.Either a
TYPE
or aDESTINATION
must be provided, but not both. ATYPE
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 fromGNUInstallDirs
, 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 aDESTINATION
argument instead of a file type if they wish to explicitly define the install destination.TYPE
ArgumentGNUInstallDirs 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
LIBEXEC
${CMAKE_INSTALL_LIBEXECDIR}
libexec
Note that some of the types' built-in defaults use the
DATAROOT
directory as a prefix. TheDATAROOT
prefix is calculated similarly to the types, withCMAKE_INSTALL_DATAROOTDIR
as the variable andshare
as the built-in default. You cannot useDATAROOT
as aTYPE
parameter; please useDATA
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 relativeGNUInstallDirs
variable. This allows package maintainers to control the install destination by setting the appropriate cache variables.Added in version 3.4: An install destination given as a
DESTINATION
argument may use "generator expressions" with the syntax$<...>
. See thecmake-generator-expressions(7)
manual for available expressions.Added in version 3.5: The list of
dirs...
given toDIRECTORY
may use "generator expressions" too.Added in version 3.31: The
TYPE
argument now supports typeLIBEXEC
.
- 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. TheCODE
form will invoke the given CMake code during installation. Code is specified as a single argument inside a double-quoted string. For example, the codeinstall(CODE "MESSAGE(\"Sample install message.\")")
will print a message during installation.
Added 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 theCOMPONENT
option.Added 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 thecmake-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 theEXPORT
option of theinstall(TARGETS)
signature documented above. TheNAMESPACE
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 theFILE
option may be used to specify a different name. The value given to theFILE
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 theCMAKE_MAP_IMPORTED_CONFIG_<CONFIG>
variable to map configurations of dependent projects to the installed configurations. TheEXPORT_LINK_INTERFACE_LIBRARIES
keyword, if present, causes the contents of the properties matching(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?
to be exported, when policyCMP0022
isNEW
.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 componentsRuntime
andDevelopment
, with shared libraries going into theRuntime
component and static libraries and headers going into theDevelopment
component. The export set would also typically be part of theDevelopment
component, but it would export targets from both theRuntime
andDevelopment
components. Therefore, theRuntime
component would need to be installed if theDevelopment
component was installed, but not vice versa. If theDevelopment
component was installed without theRuntime
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 theRuntime
component as a dependency of theDevelopment
component in the package metadata, ensuring that the library is always installed if the headers and CMake export file are present.Added 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
Added 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
Note
Experimental. Gated by
CMAKE_EXPERIMENTAL_EXPORT_PACKAGE_DEPENDENCIES
.Specify that
find_dependency()
calls should be exported. If this argument is specified, CMake examines all targets in the export set and gathers theirINTERFACE
link targets. If any such targets either were found withfind_package()
or have theEXPORT_FIND_PACKAGE_NAME
property set, and such package dependency was not disabled by passingENABLED OFF
toexport(SETUP)
, then afind_dependency()
call is written with the target's corresponding package name, aREQUIRED
argument, and any additional arguments specified by theEXTRA_ARGS
argument ofexport(SETUP)
. Any package dependencies that were manually specified by passingENABLED ON
toexport(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 containINTERFACE
dependencies of the exported targets.Any package dependencies that contain
INTERFACE
link dependencies of the exported targets and that were never specified inexport(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 codeinstall(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 themyexe
executable from the installation tree using the imported target namemp_myexe
as if the target were built in its own tree.
- install(PACKAGE_INFO <package-name> [...])¶
Added in version 3.31.
Note
Experimental. Gated by
CMAKE_EXPERIMENTAL_EXPORT_PACKAGE_INFO
.Installs a Common Package Specification file exporting targets for dependent projects:
install(PACKAGE_INFO <package-name> EXPORT <export-name> [APPENDIX <appendix-name>] [DESTINATION <dir>] [LOWER_CASE_FILE] [VERSION <version> [COMPAT_VERSION <version>] [VERSION_SCHEMA <string>]] [DEFAULT_TARGETS <target>...] [DEFAULT_CONFIGURATIONS <config>...] [PERMISSIONS <permission>...] [CONFIGURATIONS <config>...] [COMPONENT <component>] [EXCLUDE_FROM_ALL])
The
PACKAGE_INFO
form generates and installs a Common Package Specification file which describes installed targets such that they can be consumed by another project. Target installations are associated with the export<export-name>
using theEXPORT
option of theinstall(TARGETS)
signature documented above. Unlikeinstall(EXPORT)
, this information is not expressed in CMake code, and can be consumed by tools other than CMake. When imported into another CMake project, the imported targets will be prefixed with<package-name>::
. By default, the generated file will be called<package-name>[-<appendix-name>].cps
. IfLOWER_CASE_FILE
is given, the package name as it appears on disk (in both the file name and install destination) will be first converted to lower case.If
DESTINATION
is not specified, a platform-specific default is used.If
APPENDIX
is specified, rather than generating a top level package specification, the specified targets will be exported as an appendix to the named package. Appendices may be used to separate less commonly used targets (along with their external dependencies) from the rest of a package. This enables consumers to ignore transitive dependencies for targets that they don't use, and also allows a single logical "package" to be composed of artifacts produced by multiple build trees.Appendices are not permitted to change basic package metadata; therefore, none of
VERSION
,COMPAT_VERSION
,VERSION_SCHEMA
,DEFAULT_TARGETS
orDEFAULT_CONFIGURATIONS
may be specified in combination withAPPENDIX
. Additionally, it is strongly recommended that use ofLOWER_CASE_FILE
should be consistent between the main package and any appendices.
- install(RUNTIME_DEPENDENCY_SET <set-name> [...])¶
Added 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)
orinstall(IMPORTED_RUNTIME_ARTIFACTS)
commands. The dependencies of targets belonging to a runtime dependency set are installed in theRUNTIME
destination and component on DLL platforms, and in theLIBRARY
destination and component on non-DLL platforms. macOS frameworks are installed in theFRAMEWORK
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 withinstall(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 theEXECUTABLES
argument, the build-tree shared libraries as theLIBRARIES
argument, and the build-tree modules as theMODULES
argument. On macOS, if one of the executables is aMACOSX_BUNDLE
, that executable is passed as theBUNDLE_EXECUTABLE
argument. At most one such bundle executable may be in the runtime dependency set on macOS. TheMACOSX_BUNDLE
property has no effect on other platforms. Note thatfile(GET_RUNTIME_DEPENDENCIES)
only supports collecting the runtime dependencies for Windows, Linux and macOS platforms, soinstall(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 supportgenerator 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>...
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.
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 theRuntime
component.On non-DLL platforms:
Install
libmySharedLib.so.1
to<prefix>/lib
, the default LIBRARY artifact destination, as part of theRuntime
component.Install the
libmySharedLib.so
"namelink" (symbolic link) to<prefix>/lib
, the default LIBRARY artifact destination, as part of theDevelopment
component.
On DLL platforms:
Install
mySharedLib.dll
to<prefix>/bin
, the default RUNTIME artifact destination, as part of theRuntime
component.Install
mySharedLib.lib
to<prefix>/lib/static
, the specified ARCHIVE artifact destination, as part of theDevelopment
component.
Install
myStaticLib
to<prefix>/lib/static
, the specified ARCHIVE artifact destination, as part of theDevelopment
component.Install
mySharedLib.h
andmyStaticLib.h
to<prefix>/include
, the default destination for a file set of type HEADERS, as part of theDevelopment
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, runcmake -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, runcmake -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.