CMake/Help/command/install.rst

install
-------

Specify rules to run at install time.

Synopsis
^^^^^^^^

.. parsed-literal::

  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.

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

.. versionchanged:: 3.22
  The environment variable :envvar:`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``
  Specify the directory on disk to which a file will be installed.
  Arguments can be relative or absolute paths.

  If a relative path is given it is interpreted relative to the value
  of the :variable:`CMAKE_INSTALL_PREFIX` variable.
  The prefix can be relocated at install time using the ``DESTDIR``
  mechanism explained in the :variable:`CMAKE_INSTALL_PREFIX` variable
  documentation.

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

  As absolute paths are not supported by :manual:`cpack <cpack(1)>` installer
  generators, it is preferable to use relative paths throughout.
  In particular, there is no need to make paths absolute by prepending
  :variable:`CMAKE_INSTALL_PREFIX`; this prefix is used by default if
  the DESTINATION is a relative path.

``PERMISSIONS``
  Specify permissions for installed files.  Valid permissions are
  ``OWNER_READ``, ``OWNER_WRITE``, ``OWNER_EXECUTE``, ``GROUP_READ``,
  ``GROUP_WRITE``, ``GROUP_EXECUTE``, ``WORLD_READ``, ``WORLD_WRITE``,
  ``WORLD_EXECUTE``, ``SETUID``, and ``SETGID``.  Permissions that do
  not make sense on certain platforms are ignored on those platforms.

``CONFIGURATIONS``
  Specify a list of build configurations for which the install rule
  applies (Debug, Release, etc.). Note that the values specified for
  this option only apply to options listed AFTER the ``CONFIGURATIONS``
  option. For example, to set separate install paths for the Debug and
  Release configurations, do the following:

  .. code-block:: cmake

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

  Note that ``CONFIGURATIONS`` appears BEFORE ``RUNTIME DESTINATION``.

``COMPONENT``
  Specify an installation component name with which the install rule
  is associated, such as ``Runtime`` or ``Development``.  During
  component-specific installation only install rules associated with
  the given component name will be executed.  During a full installation
  all components are installed unless marked with ``EXCLUDE_FROM_ALL``.
  If ``COMPONENT`` is not provided a default component "Unspecified" is
  created.  The default component name may be controlled with the
  :variable:`CMAKE_INSTALL_DEFAULT_COMPONENT_NAME` variable.

``EXCLUDE_FROM_ALL``
  .. versionadded:: 3.6

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

``RENAME``
  Specify a name for an installed file that may be different from the
  original file.  Renaming is allowed only when a single file is
  installed by the command.

``OPTIONAL``
  Specify that it is not an error if the file to be installed does
  not exist.

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

.. versionadded:: 3.11
  Many of the ``install()`` variants implicitly create the directories
  containing the installed files. If
  :variable:`CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS` is set, these
  directories will be created with the permissions specified. Otherwise,
  they will be created according to the uname rules on Unix-like platforms.
  Windows platforms are unaffected.

Installing Targets
^^^^^^^^^^^^^^^^^^

.. _`install(TARGETS)`:
.. _TARGETS:

.. code-block:: cmake

  install(TARGETS targets... [EXPORT <export-name>]
          [RUNTIME_DEPENDENCIES args...|RUNTIME_DEPENDENCY_SET <set-name>]
          [[ARCHIVE|LIBRARY|RUNTIME|OBJECTS|FRAMEWORK|BUNDLE|
            PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE|FILE_SET <set-name>|CXX_MODULES_BMI]
           [DESTINATION <dir>]
           [PERMISSIONS permissions...]
           [CONFIGURATIONS [Debug|Release|...]]
           [COMPONENT <component>]
           [NAMELINK_COMPONENT <component>]
           [OPTIONAL] [EXCLUDE_FROM_ALL]
           [NAMELINK_ONLY|NAMELINK_SKIP]
          ] [...]
          [INCLUDES DESTINATION [<dir> ...]]
          )

The ``TARGETS`` form specifies rules for installing targets from a
project.  There are several kinds of target :ref:`Output Artifacts`
that may be installed:

``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
    :prop_tgt:`ENABLE_EXPORTS` enabled.
  * On macOS, the *linker import file* created for shared libraries with
    :prop_tgt:`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``
  .. versionadded:: 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 :prop_tgt:`MACOSX_BUNDLE` property are treated as
  ``BUNDLE`` targets on macOS.

``PUBLIC_HEADER``
  Any :prop_tgt:`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 :prop_tgt:`FRAMEWORK`
  libraries on Apple platforms because the associated files are installed
  into the appropriate locations inside the framework folder. See
  :prop_tgt:`PUBLIC_HEADER` for details.

``PRIVATE_HEADER``
  Similar to ``PUBLIC_HEADER``, but for ``PRIVATE_HEADER`` files. See
  :prop_tgt:`PRIVATE_HEADER` for details.

``RESOURCE``
  Similar to ``PUBLIC_HEADER`` and ``PRIVATE_HEADER``, but for
  ``RESOURCE`` files. See :prop_tgt:`RESOURCE` for details.

``FILE_SET <set>``
  .. versionadded:: 3.23

  File sets are defined by the :command:`target_sources(FILE_SET)` command.
  If the file set ``<set>`` 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``

  .. note ::

    Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API``

  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 each of these arguments given, the arguments following them only apply
to the target or file type specified in the argument. If none is given, the
installation properties apply to all target types.

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 :module:`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 :prop_tgt:`PUBLIC_HEADER` and :prop_tgt:`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 recommended that they use a
path that begins with the appropriate :module:`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
:module:`GNUInstallDirs`, but with its headers installed to a project-specific
subdirectory without using file sets:

.. code-block:: cmake

  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``
  .. versionadded:: 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.

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

  Consider the following example:

  .. code-block:: cmake

    install(TARGETS mylib
            LIBRARY
              COMPONENT Libraries
              NAMELINK_COMPONENT Development
            PUBLIC_HEADER
              COMPONENT Development
           )

  In this scenario, if you choose to install only the ``Development``
  component, both the headers and namelink will be installed without the
  library. (If you don't also install the ``Libraries`` component, the
  namelink will be a dangling symlink, and projects that link to the library
  will have build errors.) If you install only the ``Libraries`` component,
  only the library will be installed, without the headers and namelink.

  This option is typically used for package managers that have separate
  runtime and development packages. For example, on Debian systems, the
  library is expected to be in the runtime package, and the headers and
  namelink are expected to be in the development package.

  See the :prop_tgt:`VERSION` and :prop_tgt:`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.

  .. versionchanged:: 3.27
    This parameter is also usable for an ``ARCHIVE`` block to manage
    the linker import file created, on macOS, for shared libraries with
    :prop_tgt:`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.

  .. versionchanged:: 3.27
    This parameter is also usable for an ``ARCHIVE`` block to manage
    the linker import file created, on macOS, for shared libraries with
    :prop_tgt:`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 :prop_tgt:`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
  :prop_tgt:`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
  :genex:`$<INSTALL_PREFIX>`.

``RUNTIME_DEPENDENCY_SET``
  .. versionadded:: 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``
  .. versionadded:: 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:

  .. code-block:: cmake

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

  where ``<set-name>`` will be a randomly generated set name.
  The ``args...`` 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.

One or more groups of properties may be specified in a single call to
the ``TARGETS`` form of this command.  A target may be installed more than
once to different locations.  Consider hypothetical targets ``myExe``,
``mySharedLib``, and ``myStaticLib``.  The code:

.. code-block:: cmake

  install(TARGETS myExe mySharedLib myStaticLib
          RUNTIME DESTINATION bin
          LIBRARY DESTINATION lib
          ARCHIVE DESTINATION lib/static)
  install(TARGETS mySharedLib DESTINATION /some/full/path)

will install ``myExe`` to ``<prefix>/bin`` and ``myStaticLib`` to
``<prefix>/lib/static``.  On non-DLL platforms ``mySharedLib`` will be
installed to ``<prefix>/lib`` and ``/some/full/path``.  On DLL platforms
the ``mySharedLib`` DLL will be installed to ``<prefix>/bin`` and
``/some/full/path`` and its import library will be installed to
``<prefix>/lib/static`` and ``/some/full/path``.

:ref:`Interface Libraries` may be listed among the targets to install.
They install no artifacts but will be included in an associated ``EXPORT``.
If :ref:`Object Libraries` are listed but given no destination for their
object files, they will be exported as :ref:`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 :prop_tgt:`EXCLUDE_FROM_ALL` target property
set to ``TRUE`` has undefined behavior.

.. versionadded:: 3.3
  An install destination given as a ``DESTINATION`` argument may
  use "generator expressions" with the syntax ``$<...>``.  See the
  :manual:`cmake-generator-expressions(7)` manual for available expressions.

.. versionadded:: 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
  :command:`target_link_libraries` or :command:`add_dependencies`
  to ensure that such out-of-directory targets are built before the
  subdirectory-specific install rules are run.

Installing Imported Runtime Artifacts
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. _`install(IMPORTED_RUNTIME_ARTIFACTS)`:
.. _IMPORTED_RUNTIME_ARTIFACTS:

.. versionadded:: 3.21

.. code-block:: cmake

  install(IMPORTED_RUNTIME_ARTIFACTS targets...
          [RUNTIME_DEPENDENCY_SET <set-name>]
          [[LIBRARY|RUNTIME|FRAMEWORK|BUNDLE]
           [DESTINATION <dir>]
           [PERMISSIONS permissions...]
           [CONFIGURATIONS [Debug|Release|...]]
           [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 :prop_tgt:`FRAMEWORK`
libraries, :prop_tgt:`MACOSX_BUNDLE` executables, and :prop_tgt:`BUNDLE`
CFBundles.) For example, headers and import libraries associated with DLLs are
not installed. In the case of :prop_tgt:`FRAMEWORK` libraries,
:prop_tgt:`MACOSX_BUNDLE` executables, and :prop_tgt:`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.

Installing Files
^^^^^^^^^^^^^^^^

.. _`install(FILES)`:
.. _`install(PROGRAMS)`:
.. _FILES:
.. _PROGRAMS:

.. note::

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

.. code-block:: cmake

  install(<FILES|PROGRAMS> files...
          TYPE <type> | DESTINATION <dir>
          [PERMISSIONS permissions...]
          [CONFIGURATIONS [Debug|Release|...]]
          [COMPONENT <component>]
          [RENAME <name>] [OPTIONAL] [EXCLUDE_FROM_ALL])

The ``FILES`` form specifies rules for installing files for a project.
File names given as relative paths are interpreted with respect to the
current source directory.  Files installed by this form are by default
given permissions ``OWNER_WRITE``, ``OWNER_READ``, ``GROUP_READ``, and
``WORLD_READ`` if no ``PERMISSIONS`` argument is given.

The ``PROGRAMS`` form is identical to the ``FILES`` form except that the
default permissions for the installed file also include ``OWNER_EXECUTE``,
``GROUP_EXECUTE``, and ``WORLD_EXECUTE``.  This form is intended to install
programs that are not targets, such as shell scripts.  Use the ``TARGETS``
form to install targets built within the project.

The list of ``files...`` given to ``FILES`` or ``PROGRAMS`` may use
"generator expressions" with the syntax ``$<...>``.  See the
:manual:`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 :module:`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 :command:`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 recommended that they use a
path that begins with the appropriate :module:`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:

.. code-block:: cmake

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

.. versionadded:: 3.4
  An install destination given as a ``DESTINATION`` argument may
  use "generator expressions" with the syntax ``$<...>``.  See the
  :manual:`cmake-generator-expressions(7)` manual for available expressions.

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

Installing Directories
^^^^^^^^^^^^^^^^^^^^^^

.. _`install(DIRECTORY)`:
.. _DIRECTORY:

.. note::

  To install a directory sub-tree of headers, consider using file sets
  defined by :command:`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.

.. code-block:: cmake

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

The ``DIRECTORY`` form installs contents of one or more directories to a
given destination.  The directory structure is copied verbatim to the
destination.  The last component of each directory name is appended to
the destination directory but a trailing slash may be used to avoid
this because it leaves the last component empty.  Directory names
given as relative paths are interpreted with respect to the current
source directory.  If no input directory names are given the
destination directory will be created but nothing will be installed
into it.  The ``FILE_PERMISSIONS`` and ``DIRECTORY_PERMISSIONS`` options
specify permissions given to files and directories in the destination.
If ``USE_SOURCE_PERMISSIONS`` is specified and ``FILE_PERMISSIONS`` is not,
file permissions will be copied from the source directory structure.
If no permissions are specified files will be given the default
permissions specified in the ``FILES`` form of the command, and the
directories will be given the default permissions specified in the
``PROGRAMS`` form of the command.

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

.. code-block:: cmake

  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 :ref:`string(REGEX) <Regex Specification>` 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

.. code-block:: cmake

  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
:module:`GNUInstallDirs`, or by using a built-in default if that variable
is not defined.  See the table below for the supported file types and their
corresponding variables and built-in defaults.  Projects can provide a
``DESTINATION`` argument instead of a file type if they wish to explicitly
define the install destination.

======================= ================================== =========================
   ``TYPE`` Argument         GNUInstallDirs Variable           Built-In Default
======================= ================================== =========================
``BIN``                 ``${CMAKE_INSTALL_BINDIR}``        ``bin``
``SBIN``                ``${CMAKE_INSTALL_SBINDIR}``       ``sbin``
``LIB``                 ``${CMAKE_INSTALL_LIBDIR}``        ``lib``
``INCLUDE``             ``${CMAKE_INSTALL_INCLUDEDIR}``    ``include``
``SYSCONF``             ``${CMAKE_INSTALL_SYSCONFDIR}``    ``etc``
``SHAREDSTATE``         ``${CMAKE_INSTALL_SHARESTATEDIR}`` ``com``
``LOCALSTATE``          ``${CMAKE_INSTALL_LOCALSTATEDIR}`` ``var``
``RUNSTATE``            ``${CMAKE_INSTALL_RUNSTATEDIR}``   ``<LOCALSTATE dir>/run``
``DATA``                ``${CMAKE_INSTALL_DATADIR}``       ``<DATAROOT dir>``
``INFO``                ``${CMAKE_INSTALL_INFODIR}``       ``<DATAROOT dir>/info``
``LOCALE``              ``${CMAKE_INSTALL_LOCALEDIR}``     ``<DATAROOT dir>/locale``
``MAN``                 ``${CMAKE_INSTALL_MANDIR}``        ``<DATAROOT dir>/man``
``DOC``                 ``${CMAKE_INSTALL_DOCDIR}``        ``<DATAROOT dir>/doc``
======================= ================================== =========================

Note that some of the types' built-in defaults use the ``DATAROOT`` directory as
a prefix. The ``DATAROOT`` prefix is calculated similarly to the types, with
``CMAKE_INSTALL_DATAROOTDIR`` as the variable and ``share`` as the built-in
default. You cannot use ``DATAROOT`` as a ``TYPE`` parameter; please use
``DATA`` instead.

To make packages compliant with distribution filesystem layout policies, if
projects must specify a ``DESTINATION``, it is recommended that they use a
path that begins with the appropriate :module:`GNUInstallDirs` variable.
This allows package maintainers to control the install destination by setting
the appropriate cache variables.

.. versionadded:: 3.4
  An install destination given as a ``DESTINATION`` argument may
  use "generator expressions" with the syntax ``$<...>``.  See the
  :manual:`cmake-generator-expressions(7)` manual for available expressions.

.. versionadded:: 3.5
  The list of ``dirs...`` given to ``DIRECTORY`` may use
  "generator expressions" too.

Custom Installation Logic
^^^^^^^^^^^^^^^^^^^^^^^^^

.. _`install(CODE)`:
.. _`install(SCRIPT)`:
.. _CODE:
.. _SCRIPT:

.. code-block:: cmake

  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

.. code-block:: cmake

  install(CODE "MESSAGE(\"Sample install message.\")")

will print a message during installation.

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

.. versionadded:: 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
  :manual:`cmake-generator-expressions(7)` manual for available expressions.

Installing Exports
^^^^^^^^^^^^^^^^^^

.. _`install(EXPORT)`:
.. _EXPORT:

.. code-block:: cmake

  install(EXPORT <export-name> DESTINATION <dir>
          [NAMESPACE <namespace>] [FILE <name>.cmake]
          [PERMISSIONS permissions...]
          [CONFIGURATIONS [Debug|Release|...]
          [CXX_MODULES_DIRECTORY <directory>]
          [EXPORT_LINK_INTERFACE_LIBRARIES]
          [COMPONENT <component>]
          [EXCLUDE_FROM_ALL])
  install(EXPORT_ANDROID_MK <export-name> DESTINATION <dir> [...])

The ``EXPORT`` form generates and installs a CMake file containing code to
import targets from the installation tree into another project.
Target installations are associated with the export ``<export-name>``
using the ``EXPORT`` option of the `install(TARGETS)`_ signature
documented above.  The ``NAMESPACE`` option will prepend ``<namespace>`` to
the target names as they are written to the import file.  By default
the generated file will be called ``<export-name>.cmake`` but the ``FILE``
option may be used to specify a different name.  The value given to
the ``FILE`` option must be a file name with the ``.cmake`` extension.
If a ``CONFIGURATIONS`` option is given then the file will only be installed
when one of the named configurations is installed.  Additionally, the
generated import file will reference only the matching target
configurations.  The ``EXPORT_LINK_INTERFACE_LIBRARIES`` keyword, if
present, causes the contents of the properties matching
``(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?`` to be exported, when
policy :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.

.. versionadded:: 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``

  .. note ::

    Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API``

  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.

The ``EXPORT`` form is useful to help outside projects use targets built
and installed by the current project.  For example, the code

.. code-block:: cmake

  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 :command:`install_targets` command and
  the :prop_tgt:`PRE_INSTALL_SCRIPT` and :prop_tgt:`POST_INSTALL_SCRIPT`
  target properties.  It also replaces the ``FILES`` forms of the
  :command:`install_files` and :command:`install_programs` commands.
  The processing order of these install rules relative to
  those generated by :command:`install_targets`,
  :command:`install_files`, and :command:`install_programs` commands
  is not defined.

Installing Runtime Dependencies
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. _`install(RUNTIME_DEPENDENCY_SET)`:
.. _RUNTIME_DEPENDENCY_SET:

.. versionadded:: 3.21

.. code-block:: cmake

  install(RUNTIME_DEPENDENCY_SET <set-name>
          [[LIBRARY|RUNTIME|FRAMEWORK]
           [DESTINATION <dir>]
           [PERMISSIONS permissions...]
           [CONFIGURATIONS [Debug|Release|...]]
           [COMPONENT <component>]
           [NAMELINK_COMPONENT <component>]
           [OPTIONAL] [EXCLUDE_FROM_ALL]
          ] [...]
          [PRE_INCLUDE_REGEXES regexes...]
          [PRE_EXCLUDE_REGEXES regexes...]
          [POST_INCLUDE_REGEXES regexes...]
          [POST_EXCLUDE_REGEXES regexes...]
          [POST_INCLUDE_FILES files...]
          [POST_EXCLUDE_FILES files...]
          [DIRECTORIES directories...]
          )

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 :command:`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
:prop_tgt:`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 :prop_tgt:`MACOSX_BUNDLE` property
has no effect on other platforms. Note that
:command:`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 :command:`file(GET_RUNTIME_DEPENDENCIES)` (for those that provide
a non-empty list of directories, regular expressions or files).  They all
support :manual:`generator expressions <cmake-generator-expressions(7)>`.

* ``DIRECTORIES <directories>``
* ``PRE_INCLUDE_REGEXES <regexes>``
* ``PRE_EXCLUDE_REGEXES <regexes>``
* ``POST_INCLUDE_REGEXES <regexes>``
* ``POST_EXCLUDE_REGEXES <regexes>``
* ``POST_INCLUDE_FILES <files>``
* ``POST_EXCLUDE_FILES <files>``

Generated Installation Script
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. note::

  Use of this feature is not recommended. Please consider using the
  :option:`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
:option:`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 :envvar:`DESTDIR` for
  details.