diff options
Diffstat (limited to 'Help')
89 files changed, 1438 insertions, 946 deletions
diff --git a/Help/command/add_custom_command.rst b/Help/command/add_custom_command.rst index 9bc88d6..1fcf06c 100644 --- a/Help/command/add_custom_command.rst +++ b/Help/command/add_custom_command.rst @@ -24,6 +24,7 @@ The first signature is for adding a custom command to produce an output: [COMMENT comment] [DEPFILE depfile] [JOB_POOL job_pool] + [JOB_SERVER_AWARE <bool>] [VERBATIM] [APPEND] [USES_TERMINAL] [COMMAND_EXPAND_LISTS] [DEPENDS_EXPLICIT_ONLY]) @@ -221,6 +222,19 @@ The options are: Using a pool that is not defined by :prop_gbl:`JOB_POOLS` causes an error by ninja at build time. +``JOB_SERVER_AWARE`` + .. versionadded:: 3.28 + + Specify that the command is GNU Make job server aware. + + For the :generator:`Unix Makefiles`, :generator:`MSYS Makefiles`, and + :generator:`MinGW Makefiles` generators this will add the ``+`` prefix to the + recipe line. See the `GNU Make Documentation`_ for more information. + + This option is silently ignored by other generators. + +.. _`GNU Make Documentation`: https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html + ``MAIN_DEPENDENCY`` Specify the primary input source file to the command. This is treated just like any value given to the ``DEPENDS`` option @@ -516,7 +530,7 @@ one of the keywords to make clear the behavior they expect. Because generator expressions can be used in custom commands, it is possible to define ``COMMAND`` lines or whole custom commands which evaluate to empty strings for certain configurations. - For **Visual Studio 11 2012 (and newer)** generators these command + For **Visual Studio 12 2013 (and newer)** generators these command lines or custom commands will be omitted for the specific configuration and no "empty-string-command" will be added. diff --git a/Help/command/add_custom_target.rst b/Help/command/add_custom_target.rst index 545b9a5..ef0c8d9 100644 --- a/Help/command/add_custom_target.rst +++ b/Help/command/add_custom_target.rst @@ -12,6 +12,7 @@ Add a target with no output so it will always be built. [WORKING_DIRECTORY dir] [COMMENT comment] [JOB_POOL job_pool] + [JOB_SERVER_AWARE <bool>] [VERBATIM] [USES_TERMINAL] [COMMAND_EXPAND_LISTS] [SOURCES src1 [src2...]]) @@ -146,6 +147,19 @@ The options are: Using a pool that is not defined by :prop_gbl:`JOB_POOLS` causes an error by ninja at build time. +``JOB_SERVER_AWARE`` + .. versionadded:: 3.28 + + Specify that the command is GNU Make job server aware. + + For the :generator:`Unix Makefiles`, :generator:`MSYS Makefiles`, and + :generator:`MinGW Makefiles` generators this will add the ``+`` prefix to the + recipe line. See the `GNU Make Documentation`_ for more information. + + This option is silently ignored by other generators. + +.. _`GNU Make Documentation`: https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html + ``SOURCES`` Specify additional source files to be included in the custom target. Specified source files will be added to IDE project files for diff --git a/Help/command/block.rst b/Help/command/block.rst index a352e83..4c6e111 100644 --- a/Help/command/block.rst +++ b/Help/command/block.rst @@ -21,7 +21,8 @@ scopes created by the ``block()`` command are removed. ``POLICIES`` Create a new policy scope. This is equivalent to - :command:`cmake_policy(PUSH)`. + :command:`cmake_policy(PUSH)` with an automatic + :command:`cmake_policy(POP)` when leaving the block scope. ``VARIABLES`` Create a new variable scope. diff --git a/Help/command/cmake_policy.rst b/Help/command/cmake_policy.rst index d7880bc..4a08c01 100644 --- a/Help/command/cmake_policy.rst +++ b/Help/command/cmake_policy.rst @@ -24,9 +24,8 @@ The ``cmake_policy`` command is used to set policies to ``OLD`` or ``NEW`` behavior. While setting policies individually is supported, we encourage projects to set policies based on CMake versions: -.. code-block:: cmake - - cmake_policy(VERSION <min>[...<max>]) +.. signature:: cmake_policy(VERSION <min>[...<max>]) + :target: VERSION .. versionadded:: 3.12 The optional ``<max>`` version. @@ -57,10 +56,8 @@ command implicitly calls ``cmake_policy(VERSION)`` too. Setting Policies Explicitly ^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. code-block:: cmake - - cmake_policy(SET CMP<NNNN> NEW) - cmake_policy(SET CMP<NNNN> OLD) +.. signature:: cmake_policy(SET CMP<NNNN> NEW|OLD) + :target: SET Tell CMake to use the ``OLD`` or ``NEW`` behavior for a given policy. Projects depending on the old behavior of a given policy may silence a @@ -73,9 +70,8 @@ policy state to ``NEW``. Checking Policy Settings ^^^^^^^^^^^^^^^^^^^^^^^^ -.. code-block:: cmake - - cmake_policy(GET CMP<NNNN> <variable>) +.. signature:: cmake_policy(GET CMP<NNNN> <variable>) + :target: GET Check whether a given policy is set to ``OLD`` or ``NEW`` behavior. The output ``<variable>`` value will be ``OLD`` or ``NEW`` if the @@ -94,23 +90,27 @@ except when invoked with the ``NO_POLICY_SCOPE`` option The ``cmake_policy`` command provides an interface to manage custom entries on the policy stack: -.. code-block:: cmake +.. signature:: cmake_policy(PUSH) + :target: PUSH + + Create a new entry on the policy stack. + +.. signature:: cmake_policy(POP) + :target: POP - cmake_policy(PUSH) - cmake_policy(POP) + Remove the last policy stack entry created with ``cmake_policy(PUSH)``. Each ``PUSH`` must have a matching ``POP`` to erase any changes. This is useful to make temporary changes to policy settings. Calls to the :command:`cmake_minimum_required(VERSION)`, -``cmake_policy(VERSION)``, or ``cmake_policy(SET)`` commands +:command:`cmake_policy(VERSION)`, or :command:`cmake_policy(SET)` commands influence only the current top of the policy stack. .. versionadded:: 3.25 - The :command:`block` and :command:`endblock` commands offer a more flexible + The :command:`block(SCOPE_FOR POLICIES)` command offers a more flexible and more secure way to manage the policy stack. The pop action is done - automatically when the :command:`endblock` command is executed, so it avoid - to call the :command:`cmake_policy(POP)` command before each - :command:`return` command. + automatically when leaving the block scope, so there is no need to + precede each :command:`return` with a call to :command:`cmake_policy(POP)`. .. code-block:: cmake diff --git a/Help/command/exec_program.rst b/Help/command/exec_program.rst index 983a6df..6010176 100644 --- a/Help/command/exec_program.rst +++ b/Help/command/exec_program.rst @@ -1,6 +1,10 @@ exec_program ------------ +.. versionchanged:: 3.28 + This command is available only if policy :policy:`CMP0153` is not set to ``NEW``. + Port projects to the :command:`execute_process` command. + .. deprecated:: 3.0 Use the :command:`execute_process` command instead. diff --git a/Help/command/file.rst b/Help/command/file.rst index 30a7f4d..f9d1a79 100644 --- a/Help/command/file.rst +++ b/Help/command/file.rst @@ -981,6 +981,11 @@ Path Conversion if ``USERPROFILE`` is not defined. On all other platforms, only ``HOME`` is used. + .. versionchanged:: 3.28 + + All symlinks are resolved before collapsing ``../`` components. + See policy :policy:`CMP0152`. + .. signature:: file(RELATIVE_PATH <variable> <directory> <file>) diff --git a/Help/command/find_library.rst b/Help/command/find_library.rst index 99e36a4..fb2c2f1 100644 --- a/Help/command/find_library.rst +++ b/Help/command/find_library.rst @@ -60,6 +60,10 @@ path to the framework ``<fullPath>/A.framework``. When a full path to a framework is used as a library, CMake will use a ``-framework A``, and a ``-F<fullPath>`` to link the framework to the target. +.. versionadded:: 3.28 + + The library found can now be a ``.xcframework`` folder. + If the :variable:`CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable is set all search paths will be tested as normal, with the suffix appended, and with all matches of ``lib/`` replaced with diff --git a/Help/command/get_property.rst b/Help/command/get_property.rst index 6b9931e..a0a12bb 100644 --- a/Help/command/get_property.rst +++ b/Help/command/get_property.rst @@ -12,7 +12,8 @@ Get a property. SOURCE <source> [DIRECTORY <dir> | TARGET_DIRECTORY <target>] | INSTALL <file> | - TEST <test> | + TEST <test> + [DIRECTORY <dir>] | CACHE <entry> | VARIABLE > PROPERTY <name> @@ -73,6 +74,16 @@ It must be one of the following: Scope must name one existing test. See also the :command:`get_test_property` command. + .. versionadded:: 3.28 + Directory scope can be overridden with the following sub-option: + + ``DIRECTORY <dir>`` + The test property will be read from the ``<dir>`` directory's + scope. CMake must already know about the directory, either by having added + it through a call to :command:`add_subdirectory` or ``<dir>`` being the top + level directory. Relative paths are treated as relative to the current + source directory. ``<dir>`` may reference a binary directory. + ``CACHE`` Scope must name one cache entry. diff --git a/Help/command/get_test_property.rst b/Help/command/get_test_property.rst index 2b6f354..1fcf24e 100644 --- a/Help/command/get_test_property.rst +++ b/Help/command/get_test_property.rst @@ -5,7 +5,7 @@ Get a property of the test. .. code-block:: cmake - get_test_property(test property VAR) + get_test_property(test property [DIRECTORY <dir>] VAR) Get a property from the test. The value of the property is stored in the variable ``VAR``. If the test property is not found, the behavior @@ -19,6 +19,17 @@ an empty string. For a list of standard properties you can type :option:`cmake --help-property-list`. +.. versionadded:: 3.28 + Directory scope can be overridden with the following sub-option: + + ``DIRECTORY <dir>`` + The test property will be read from the ``<dir>`` directory's + scope. CMake must already know about that source directory, either by + having added it through a call to :command:`add_subdirectory` or ``<dir>`` + being the top level source directory. Relative paths are treated as + relative to the current source directory. ``<dir>`` may reference a binary + directory. + See Also ^^^^^^^^ diff --git a/Help/command/install.rst b/Help/command/install.rst index b56f20c..4de3ce1 100644 --- a/Help/command/install.rst +++ b/Help/command/install.rst @@ -1,6 +1,10 @@ install ------- +.. only:: html + + .. contents:: + Specify rules to run at install time. Synopsis @@ -34,12 +38,14 @@ are executed in order during installation. The environment variable :envvar:`CMAKE_INSTALL_MODE` can override the default copying behavior of ``install()``. +.. _`common options`: + 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`` +``DESTINATION <dir>`` Specify the directory on disk to which a file will be installed. Arguments can be relative or absolute paths. @@ -58,32 +64,28 @@ signatures that specify them. The common options are: :variable:`CMAKE_INSTALL_PREFIX`; this prefix is used by default if the DESTINATION is a relative path. -``PERMISSIONS`` +``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. -``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 + If this option is used multiple times in a single call, its list + of permissions accumulates. If an :command:`install(TARGETS)` call + uses `\<artifact-kind\>`_ arguments, a separate list of permissions + is accumulated for each kind of artifact. - install(TARGETS target - CONFIGURATIONS Debug - RUNTIME DESTINATION Debug/bin) - install(TARGETS target - CONFIGURATIONS Release - RUNTIME DESTINATION Release/bin) +``CONFIGURATIONS <config>...`` + Specify a list of build configurations for which the install rule + applies (Debug, Release, etc.). - Note that ``CONFIGURATIONS`` appears BEFORE ``RUNTIME DESTINATION``. + If this option is used multiple times in a single call, its list + of configurations accumulates. If an :command:`install(TARGETS)` + call uses `\<artifact-kind\>`_ arguments, a separate list of + configurations is accumulated for each kind of artifact. -``COMPONENT`` +``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 @@ -99,7 +101,7 @@ signatures that specify them. The common options are: Specify that the file is excluded from a full installation and only installed as part of a component-specific installation -``RENAME`` +``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. @@ -121,861 +123,917 @@ signatures that specify them. The common options are: 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 - ) +Signatures +^^^^^^^^^^ -In addition to the common options listed above, each target can accept -the following additional arguments: +.. signature:: + install(TARGETS <target>... [...]) -``NAMELINK_COMPONENT`` - .. versionadded:: 3.12 + Install target :ref:`Output Artifacts` and associated files: - On some platforms a versioned shared library has a symbolic link such - as:: + .. code-block:: cmake - lib<name>.so -> lib<name>.so.1 + install(TARGETS <target>... [EXPORT <export-name>] + [RUNTIME_DEPENDENCIES <arg>...|RUNTIME_DEPENDENCY_SET <set-name>] + [<artifact-option>...] + [<artifact-kind> <artifact-option>...]... + [INCLUDES DESTINATION [<dir> ...]] + ) - 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. + where ``<artifact-option>...`` group may contain: - .. 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. + .. code-block:: cmake - Consider the following example: + [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 + :ref:`Output Artifacts` that do not have a dedicated group specified + later in the same call. + + .. _`<artifact-kind>`: + + Each ``<artifact-kind> <artifact-option>...`` group applies to + :ref:`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 + :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-name>`` + .. versionadded:: 3.23 + + File sets are defined by the :command:`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`` + + .. 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 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 - 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 + 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. + + 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 :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 :command:`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 + :command:`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 :command:`install(EXPORT)` command. + If a relative path is specified, it is treated as relative to the + :genex:`$<INSTALL_PREFIX>`. + + ``RUNTIME_DEPENDENCY_SET <set-name>`` + .. 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 + :command:`install(RUNTIME_DEPENDENCY_SET)` command. + + This keyword and the ``RUNTIME_DEPENDENCIES`` keyword are mutually + exclusive. + + ``RUNTIME_DEPENDENCIES <arg>...`` + .. 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> <arg>...) + + where ``<set-name>`` will be a randomly generated set name. + ``<arg>...`` may include any of the following keywords supported by + the :command:`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. + + :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 + :command:`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. + +.. signature:: + install(IMPORTED_RUNTIME_ARTIFACTS <target>... [...]) - 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: + Install runtime artifacts of imported targets: .. 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: + 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 :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 :command:`install(RUNTIME_DEPENDENCY_SET)` command. + +.. signature:: + install(FILES <file>... [...]) + install(PROGRAMS <program>... [...]) + + .. 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. + + Install files or programs: - * ``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. + .. code-block:: cmake -One or more groups of properties may be specified in a single call to -the ``TARGETS`` form of this command. A target may be installed more than -once to different locations. Consider hypothetical targets ``myExe``, -``mySharedLib``, and ``myStaticLib``. The code: + install(<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 + :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 + .. 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. + include(GNUInstallDirs) + install(FILES logo.png + DESTINATION ${CMAKE_INSTALL_DOCDIR}/myproj + ) -.. 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. + .. 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. -Installing Imported Runtime Artifacts -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + .. 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. -.. _`install(IMPORTED_RUNTIME_ARTIFACTS)`: -.. _IMPORTED_RUNTIME_ARTIFACTS: +.. signature:: + install(DIRECTORY <dir>... [...]) -.. versionadded:: 3.21 + .. note:: -.. code-block:: cmake + 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. - 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] - ] [...] - ) + Install the contents of one or more directories: -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: + .. code-block:: cmake -.. note:: + 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. + + .. 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 - 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 -.. code-block:: cmake + install(DIRECTORY src/ DESTINATION doc/myproj + FILES_MATCHING PATTERN "*.png") - 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: + will extract and install images from a source tree. -.. code-block:: cmake + 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 - include(GNUInstallDirs) - install(FILES logo.png - DESTINATION ${CMAKE_INSTALL_DOCDIR}/myproj - ) + .. code-block:: cmake -.. 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. + 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. + +.. signature:: + install(SCRIPT <file> [...]) + install(CODE <code> [...]) + + Invoke CMake scripts or code during installation: -.. 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. + .. code-block:: cmake -Installing Directories -^^^^^^^^^^^^^^^^^^^^^^ + install([[SCRIPT <file>] [CODE <code>]] + [ALL_COMPONENTS | COMPONENT <component>] + [EXCLUDE_FROM_ALL] [...]) -.. _`install(DIRECTORY)`: -.. _DIRECTORY: + 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 -.. note:: + .. code-block:: cmake - 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. + install(CODE "MESSAGE(\"Sample install message.\")") -.. code-block:: cmake + will print a message during installation. - 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.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.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 + .. 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. -.. code-block:: cmake +.. signature:: + install(EXPORT <export-name> [...]) - install(DIRECTORY src/ DESTINATION doc/myproj - FILES_MATCHING PATTERN "*.png") + Install a CMake file exporting targets for dependent projects: -will extract and install images from a source tree. + .. code-block:: cmake -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 + 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]) + 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 :command:`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 :variable:`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 :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 + .. 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. + 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. + +.. signature:: + install(RUNTIME_DEPENDENCY_SET <set-name> [...]) -.. versionadded:: 3.5 - The list of ``dirs...`` given to ``DIRECTORY`` may use - "generator expressions" too. + .. versionadded:: 3.21 -Custom Installation Logic -^^^^^^^^^^^^^^^^^^^^^^^^^ + Installs a runtime dependency set: -.. _`install(CODE)`: -.. _`install(SCRIPT)`: -.. _CODE: -.. _SCRIPT: + .. code-block:: cmake -.. code-block:: cmake + 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 + :command:`install(TARGETS)` or :command:`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 :command:`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 <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 +^^^^^^^^ - install([[SCRIPT <file>] [CODE <code>]] - [ALL_COMPONENTS | COMPONENT <component>] - [EXCLUDE_FROM_ALL] [...]) +Example: Install Targets with Per-Artifact Components +""""""""""""""""""""""""""""""""""""""""""""""""""""" -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 +Consider a project that defines targets with different artifact kinds: .. code-block:: cmake - install(CODE "MESSAGE(\"Sample install message.\")") + 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) -will print a message during installation. +We may call :command:`install(TARGETS)` with `\<artifact-kind\>`_ arguments +to specify different options for each kind of artifact: -.. 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. +.. code-block:: cmake -.. 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. + 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 + ) -Installing Exports -^^^^^^^^^^^^^^^^^^ +This will: -.. _`install(EXPORT)`: -.. _EXPORT: +* Install ``myExe`` to ``<prefix>/bin``, the default RUNTIME artifact + destination, as part of the ``Runtime`` component. -.. code-block:: cmake +* On non-DLL platforms: - 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. See the :variable:`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 :policy:`CMP0022` is ``NEW``. + * Install ``libmySharedLib.so.1`` to ``<prefix>/lib``, the default + LIBRARY artifact destination, as part of the ``Runtime`` component. -.. 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 + * Install the ``libmySharedLib.so`` "namelink" (symbolic link) to + ``<prefix>/lib``, the default LIBRARY artifact destination, as part + of the ``Development`` component. -.. code-block:: cmake +* On DLL platforms: - install(TARGETS myexe EXPORT myproj DESTINATION bin) - install(EXPORT myproj NAMESPACE mp_ DESTINATION lib/myproj) - install(EXPORT_ANDROID_MK myproj DESTINATION share/ndk-modules) + * Install ``mySharedLib.dll`` to ``<prefix>/bin``, the default RUNTIME + artifact destination, as part of the ``Runtime`` component. -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. + * Install ``mySharedLib.lib`` to ``<prefix>/lib/static``, the specified + ARCHIVE artifact destination, as part of the ``Development`` component. -.. 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. +* Install ``myStaticLib`` to ``<prefix>/lib/static``, the specified + ARCHIVE artifact destination, as part of the ``Development`` component. -Installing Runtime Dependencies -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +* 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. -.. _`install(RUNTIME_DEPENDENCY_SET)`: -.. _RUNTIME_DEPENDENCY_SET: +Example: Install Targets to Per-Config Destinations +""""""""""""""""""""""""""""""""""""""""""""""""""" -.. versionadded:: 3.21 +Each :command:`install(TARGETS)` call installs a given target +:ref:`output artifact <Output Artifacts>` 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: .. 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...] + install(TARGETS myExe + CONFIGURATIONS Debug + RUNTIME + DESTINATION Debug/bin + ) + install(TARGETS myExe + CONFIGURATIONS Release + RUNTIME + DESTINATION Release/bin ) -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>`` +will install ``myExe`` to ``<prefix>/Debug/bin`` in the Debug configuration, +and to ``<prefix>/Release/bin`` in the Release configuration. Generated Installation Script ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Help/command/set.rst b/Help/command/set.rst index aeb88b3..fa635c6 100644 --- a/Help/command/set.rst +++ b/Help/command/set.rst @@ -27,11 +27,12 @@ Set Normal Variable If the ``PARENT_SCOPE`` option is given the variable will be set in the scope above the current scope. Each new directory or :command:`function` command creates a new scope. A scope can also be created with the - :command:`block` command. This command will set the value of a variable into - the parent directory, calling function or encompassing scope (whichever is - applicable to the case at hand). The previous state of the variable's value - stays the same in the current scope (e.g., if it was undefined before, it is - still undefined and if it had a value, it is still that value). + :command:`block` command. ``set(PARENT_SCOPE)`` will set the value + of a variable into the parent directory, calling function, or + encompassing scope (whichever is applicable to the case at hand). + The previous state of the variable's value stays the same in the + current scope (e.g., if it was undefined before, it is still undefined + and if it had a value, it is still that value). The :command:`block(PROPAGATE)` and :command:`return(PROPAGATE)` commands can be used as an alternate method to the :command:`set(PARENT_SCOPE)` diff --git a/Help/command/set_property.rst b/Help/command/set_property.rst index fc43974..f14b63d 100644 --- a/Help/command/set_property.rst +++ b/Help/command/set_property.rst @@ -12,7 +12,8 @@ Set a named property in a given scope. [DIRECTORY <dirs> ...] [TARGET_DIRECTORY <targets> ...] | INSTALL [<file1> ...] | - TEST [<test1> ...] | + TEST [<test1> ...] + [DIRECTORY <dir>] | CACHE [<entry1> ...] > [APPEND] [APPEND_STRING] PROPERTY <name> [<value1> ...]) @@ -91,6 +92,17 @@ It must be one of the following: :manual:`generator expressions <cmake-generator-expressions(7)>` for tests created by the :command:`add_test(NAME)` signature. + .. versionadded:: 3.28 + + Visibility can be set in other directory scopes using the following sub-option: + + ``DIRECTORY <dir>`` + The test property will be set in the ``<dir>`` directory's scope. CMake must + already know about this directory, either by having added it through a call + to :command:`add_subdirectory` or it being the top level source directory. + Relative paths are treated as relative to the current source directory. + ``<dir>`` may reference a binary directory. + ``CACHE`` Scope must name zero or more existing cache entries. diff --git a/Help/command/set_tests_properties.rst b/Help/command/set_tests_properties.rst index 125e460..da750e3 100644 --- a/Help/command/set_tests_properties.rst +++ b/Help/command/set_tests_properties.rst @@ -14,10 +14,20 @@ Test property values may be specified using :manual:`generator expressions <cmake-generator-expressions(7)>` for tests created by the :command:`add_test(NAME)` signature. +.. versionadded:: 3.28 + Visibility can be set in other directory scopes using the following option: + + ``DIRECTORY <dir>`` + The test properties will be set in the ``<dir>`` directory's scope. + CMake must already know about this directory, either by having added it + through a call to :command:`add_subdirectory` or it being the top level + source directory. Relative paths are treated as relative to the current + source directory. ``<dir>`` may reference a binary directory. + See Also ^^^^^^^^ * :command:`add_test` * :command:`define_property` * the more general :command:`set_property` command -* :ref:`Target Properties` for the list of properties known to CMake +* :ref:`Test Properties` for the list of properties known to CMake diff --git a/Help/command/target_link_libraries.rst b/Help/command/target_link_libraries.rst index 1d27660..cc6bc0f 100644 --- a/Help/command/target_link_libraries.rst +++ b/Help/command/target_link_libraries.rst @@ -66,6 +66,12 @@ Each ``<item>`` may be: :ref:`usage requirement <Target Usage Requirements>`. This has the same effect as passing the framework directory as an include directory. + .. versionadded:: 3.28 + + The library file may point to a ``.xcframework`` folder on macOS. If it + does, the target will get the selected library's ``Headers`` directory as + a usage requirement. + .. versionadded:: 3.8 On :ref:`Visual Studio Generators` for VS 2010 and above, library files ending in ``.targets`` will be treated as MSBuild targets files and diff --git a/Help/command/target_precompile_headers.rst b/Help/command/target_precompile_headers.rst index c795713..db55bc2 100644 --- a/Help/command/target_precompile_headers.rst +++ b/Help/command/target_precompile_headers.rst @@ -33,7 +33,7 @@ property of ``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the Repeated calls for the same ``<target>`` will append items in the order called. Projects should generally avoid using ``PUBLIC`` or ``INTERFACE`` for targets -that will be :ref:`exported <install(EXPORT)>`, or they should at least use +that will be :command:`exported <install(EXPORT)>`, or they should at least use the :genex:`$<BUILD_INTERFACE:...>` generator expression to prevent precompile headers from appearing in an installed exported target. Consumers of a target should typically be in control of what precompile headers they use, not have diff --git a/Help/command/try_compile.rst b/Help/command/try_compile.rst index 8abb6e0..bc2b0af 100644 --- a/Help/command/try_compile.rst +++ b/Help/command/try_compile.rst @@ -65,6 +65,7 @@ Try Compiling Source Files .. code-block:: cmake try_compile(<compileResultVar> + [SOURCES_TYPE <type>] <SOURCES <srcfile...> | SOURCE_FROM_CONTENT <name> <content> | SOURCE_FROM_VAR <name> <var> | @@ -143,7 +144,12 @@ single output directory, such that you can only debug one such ``try_compile`` call at a time. Use of the newer signature is recommended to simplify debugging of multiple ``try_compile`` operations. -The options are: +.. _`try_compile Options`: + +Options +^^^^^^^ + +The options for the above signatures are: ``CMAKE_FLAGS <flags>...`` Specify flags of the form :option:`-DVAR:TYPE=VALUE <cmake -D>` to be passed @@ -244,6 +250,27 @@ The options are: ``SOURCE_FROM_VAR`` may be specified multiple times. +``SOURCES_TYPE <type>`` + .. versionadded:: 3.28 + + Sources may be classified using the ``SOURCES_TYPE`` argument. Once + specified, all subsequent sources specified will be treated as that type + until another ``SOURCES_TYPE`` is given. Available types are: + + ``NORMAL`` + Sources are not added to any ``FILE_SET`` in the generated project. + + ``CXX_MODULE`` + Sources are added to a ``FILE_SET`` of type ``CXX_MODULES`` in the + generated project. + + .. note :: + + Experimental. Sources of type ``CXX_MODULE`` are gated by + ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API`` + + The default type of sources is ``NORMAL``. + ``<LANG>_STANDARD <std>`` .. versionadded:: 3.8 diff --git a/Help/command/try_run.rst b/Help/command/try_run.rst index 3a4e203..1b5087d 100644 --- a/Help/command/try_run.rst +++ b/Help/command/try_run.rst @@ -13,6 +13,7 @@ Try Compiling and Running Source Files .. code-block:: cmake try_run(<runResultVar> <compileResultVar> + [SOURCES_TYPE <type>] <SOURCES <srcfile...> | SOURCE_FROM_CONTENT <name> <content> | SOURCE_FROM_VAR <name> <var> | @@ -77,6 +78,11 @@ The signature above is recommended for clarity. [ARGS <args>...] ) +.. _`try_run Options`: + +Options +^^^^^^^ + The options specific to ``try_run`` are: ``COMPILE_OUTPUT_VARIABLE <var>`` diff --git a/Help/dev/documentation.rst b/Help/dev/documentation.rst index c6fb7a6..65c0ccf 100644 --- a/Help/dev/documentation.rst +++ b/Help/dev/documentation.rst @@ -431,6 +431,7 @@ The section header underline character hierarchy is * ``-``: Subsection or `CMake Domain`_ object document title * ``^``: Subsubsection or `CMake Domain`_ object document section * ``"``: Paragraph or `CMake Domain`_ object document subsection +* ``~``: `CMake Domain`_ object document subsubsection Style: Whitespace ^^^^^^^^^^^^^^^^^ diff --git a/Help/dev/experimental.rst b/Help/dev/experimental.rst index eac86ab..046d214 100644 --- a/Help/dev/experimental.rst +++ b/Help/dev/experimental.rst @@ -18,7 +18,7 @@ C++20 Module APIs ================= Variable: ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API`` -Value: ``aa1f7df0-828a-4fcd-9afc-2dc80491aca7`` +Value: ``ac01f462-0f5f-432a-86aa-acef252918a6`` In order to support C++20 modules, there are a number of behaviors that have CMake APIs to provide the required features to build and export them from a @@ -99,6 +99,10 @@ dependencies to the file specified by the ``<DYNDEP_FILE>`` placeholder. The ``CMAKE_EXPERIMENTAL_CXX_SCANDEP_DEPFILE_FORMAT`` file may be set to ``msvc`` for scandep rules which use ``msvc``-style dependency reporting. +In order to support ``IMPORTED`` targets with associated C++20 module sources, +the ``CMAKE_EXPERIMENTAL_CXX_MODULE_BMI_ONLY_FLAG`` variable must be provided +to have the compiler only output a BMI instead of a BMI and an object file. + The module dependencies should be written in the format described by the `P1689r5`_ paper. @@ -113,6 +117,8 @@ For compilers that generate module maps, tell CMake as follows: set(CMAKE_EXPERIMENTAL_CXX_MODULE_MAP_FORMAT "gcc") set(CMAKE_EXPERIMENTAL_CXX_MODULE_MAP_FLAG "${compiler_flags_for_module_map} -fmodule-mapper=<MODULE_MAP_FILE>") + set(CMAKE_EXPERIMENTAL_CXX_MODULE_BMI_ONLY_FLAG + "-fmodule-only") Currently, the only supported formats are, ``clang``, ``gcc``, and ``msvc``. The ``gcc`` format is described in the GCC documentation, but the relevant diff --git a/Help/envvar/CMAKE_CROSSCOMPILING_EMULATOR.rst b/Help/envvar/CMAKE_CROSSCOMPILING_EMULATOR.rst new file mode 100644 index 0000000..3e397d8 --- /dev/null +++ b/Help/envvar/CMAKE_CROSSCOMPILING_EMULATOR.rst @@ -0,0 +1,11 @@ +CMAKE_CROSSCOMPILING_EMULATOR +----------------------------- + +.. versionadded:: 3.28 + +.. include:: ENV_VAR.txt + +The default value for :variable:`CMAKE_CROSSCOMPILING_EMULATOR` when there +is no explicit configuration given on the first run while creating a new +build tree. On later runs in an existing build tree the value persists in +the cache as :variable:`CMAKE_CROSSCOMPILING_EMULATOR`. diff --git a/Help/generator/Visual Studio 10 2010.rst b/Help/generator/Visual Studio 10 2010.rst index 888164f..a36046a 100644 --- a/Help/generator/Visual Studio 10 2010.rst +++ b/Help/generator/Visual Studio 10 2010.rst @@ -3,6 +3,6 @@ Visual Studio 10 2010 Removed. This once generated Visual Studio 10 2010 project files, but the generator has been removed since CMake 3.25. It is still possible -to build with VS 10 2010 tools using the :generator:`Visual Studio 12 2013` +to build with VS 10 2010 tools using the :generator:`Visual Studio 14 2015` (or above) generator with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v100``, or by using the :generator:`NMake Makefiles` generator. diff --git a/Help/generator/Visual Studio 11 2012.rst b/Help/generator/Visual Studio 11 2012.rst index 4e7195c..5ded24c 100644 --- a/Help/generator/Visual Studio 11 2012.rst +++ b/Help/generator/Visual Studio 11 2012.rst @@ -1,57 +1,8 @@ Visual Studio 11 2012 --------------------- -Deprecated. Generates Visual Studio 11 (VS 2012) project files. - -.. note:: - This generator is deprecated and will be removed in a future version - of CMake. It will still be possible to build with VS 11 2012 tools - using the :generator:`Visual Studio 12 2013` (or above) generator - with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v110``, or by - using the :generator:`NMake Makefiles` generator. - -For compatibility with CMake versions prior to 3.0, one may specify this -generator using the name "Visual Studio 11" without the year component. - -Project Types -^^^^^^^^^^^^^ - -Only Visual C++ and C# projects may be generated (and Fortran with -Intel compiler integration). Other types of projects (JavaScript, -Database, Website, etc.) are not supported. - -Platform Selection -^^^^^^^^^^^^^^^^^^ - -The default target platform name (architecture) is ``Win32``. - -.. versionadded:: 3.1 - The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps - via the :option:`cmake -A` option, to specify a target platform - name (architecture). For example: - - * ``cmake -G "Visual Studio 11 2012" -A Win32`` - * ``cmake -G "Visual Studio 11 2012" -A x64`` - * ``cmake -G "Visual Studio 11 2012" -A ARM`` - * ``cmake -G "Visual Studio 11 2012" -A <WinCE-SDK>`` - (Specify a target platform matching a Windows CE SDK name.) - -For compatibility with CMake versions prior to 3.1, one may specify -a target platform name optionally at the end of the generator name. -This is supported only for: - -``Visual Studio 11 2012 Win64`` - Specify target platform ``x64``. - -``Visual Studio 11 2012 ARM`` - Specify target platform ``ARM``. - -``Visual Studio 11 2012 <WinCE-SDK>`` - Specify target platform matching a Windows CE SDK name. - -Toolset Selection -^^^^^^^^^^^^^^^^^ - -The ``v110`` toolset that comes with Visual Studio 11 2012 is selected by -default. The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps -via the :option:`cmake -T` option, to specify another toolset. +Removed. This once generated Visual Studio 11 2012 project files, but +the generator has been removed since CMake 3.28. It is still possible +to build with VS 11 2012 tools using the :generator:`Visual Studio 14 2015` +(or above) generator with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v110``, +or by using the :generator:`NMake Makefiles` generator. diff --git a/Help/generator/Visual Studio 12 2013.rst b/Help/generator/Visual Studio 12 2013.rst index 3dbcfe6..522522c 100644 --- a/Help/generator/Visual Studio 12 2013.rst +++ b/Help/generator/Visual Studio 12 2013.rst @@ -1,7 +1,14 @@ Visual Studio 12 2013 --------------------- -Generates Visual Studio 12 (VS 2013) project files. +Deprecated. Generates Visual Studio 12 (VS 2013) project files. + +.. note:: + This generator is deprecated and will be removed in a future version + of CMake. It will still be possible to build with VS 12 2013 tools + using the :generator:`Visual Studio 14 2015` (or above) generator + with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v120``, or by + using the :generator:`NMake Makefiles` generator. For compatibility with CMake versions prior to 3.0, one may specify this generator using the name "Visual Studio 12" without the year component. diff --git a/Help/generator/Visual Studio 9 2008.rst b/Help/generator/Visual Studio 9 2008.rst index 816969d..1439270 100644 --- a/Help/generator/Visual Studio 9 2008.rst +++ b/Help/generator/Visual Studio 9 2008.rst @@ -6,7 +6,7 @@ Deprecated. Generates Visual Studio 9 2008 project files. .. note:: This generator is deprecated and will be removed in a future version of CMake. It will still be possible to build with VS 9 2008 tools - using the :generator:`Visual Studio 12 2013` generator (or above, + using the :generator:`Visual Studio 14 2015` generator (or above, and with VS 10 2010 also installed) with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v90``, or by using the :generator:`NMake Makefiles` generator. diff --git a/Help/guide/tutorial/A Basic Starting Point.rst b/Help/guide/tutorial/A Basic Starting Point.rst index 37b0668..2325e9e 100644 --- a/Help/guide/tutorial/A Basic Starting Point.rst +++ b/Help/guide/tutorial/A Basic Starting Point.rst @@ -102,7 +102,14 @@ Then call that build system to actually compile/link the project: cmake --build . -Finally, try to use the newly built ``Tutorial`` with these commands: +For multi-config generators (e.g. Visual Studio), first navigate to the +appropriate subdirectory, for example: + +.. code-block:: console + + cd Debug + +Finally, try to use the newly built ``Tutorial``: .. code-block:: console @@ -110,6 +117,11 @@ Finally, try to use the newly built ``Tutorial`` with these commands: Tutorial 10 Tutorial + +**Note:** Depending on the shell, the correct syntax may be ``Tutorial``, +``./Tutorial`` or ``.\Tutorial``. For simplicity, the exercises will use +``Tutorial`` throughout. + Solution -------- diff --git a/Help/guide/tutorial/Adding Generator Expressions.rst b/Help/guide/tutorial/Adding Generator Expressions.rst index 3dab97f..910eacb 100644 --- a/Help/guide/tutorial/Adding Generator Expressions.rst +++ b/Help/guide/tutorial/Adding Generator Expressions.rst @@ -149,8 +149,8 @@ interface library. Lastly, we only want these warning flags to be used during builds. Consumers of our installed project should not inherit our warning flags. To specify -this, we wrap our flags in a generator expression using the ``BUILD_INTERFACE`` -condition. The resulting full code looks like the following: +this, we wrap our flags from TODO 3 in a generator expression using the +``BUILD_INTERFACE`` condition. The resulting full code looks like the following: .. raw:: html diff --git a/Help/guide/tutorial/Adding Usage Requirements for a Library.rst b/Help/guide/tutorial/Adding Usage Requirements for a Library.rst index 2273063..5e803f5 100644 --- a/Help/guide/tutorial/Adding Usage Requirements for a Library.rst +++ b/Help/guide/tutorial/Adding Usage Requirements for a Library.rst @@ -127,7 +127,7 @@ Remove this line: </details> -And the lines: +And remove ``EXTRA_INCLUDES`` from ``target_include_directories``: .. raw:: html @@ -143,23 +143,6 @@ And the lines: </details> -The remaining code looks like: - -.. raw:: html - - <details><summary>Click to show/hide the resulting code</summary> - -.. literalinclude:: Step4/CMakeLists.txt - :caption: Remaining code after removing EXTRA_INCLUDES - :name: CMakeLists.txt-after-removing-EXTRA_INCLUDES - :language: cmake - :start-after: add_subdirectory(MathFunctions) - -.. raw:: html - - </details> - - Notice that with this technique, the only thing our executable target does to use our library is call :command:`target_link_libraries` with the name of the library target. In larger projects, the classic method of specifying @@ -309,8 +292,8 @@ and this: :caption: TODO 7: MathFunctions/CMakeLists.txt :name: MathFunctions-SqrtLibrary-target_link_libraries-step4 :language: cmake - :start-after: target_link_libraries(SqrtLibrary - :end-before: endif() + :start-after: # link our compiler flags interface library + :end-before: target_link_libraries(MathFunctions PUBLIC SqrtLibrary) .. raw:: html diff --git a/Help/guide/tutorial/Adding a Library.rst b/Help/guide/tutorial/Adding a Library.rst index 694dfaf..178334a 100644 --- a/Help/guide/tutorial/Adding a Library.rst +++ b/Help/guide/tutorial/Adding a Library.rst @@ -96,7 +96,7 @@ a library target called ``MathFunctions`` with :command:`add_library`. The source files for the library are passed as an argument to :command:`add_library`. This looks like the following line: -.. raw:: html/ +.. raw:: html <details><summary>TODO 1: Click to show/hide answer</summary> diff --git a/Help/guide/tutorial/Selecting Static or Shared Libraries.rst b/Help/guide/tutorial/Selecting Static or Shared Libraries.rst index 504e42f..a2f5e2a 100644 --- a/Help/guide/tutorial/Selecting Static or Shared Libraries.rst +++ b/Help/guide/tutorial/Selecting Static or Shared Libraries.rst @@ -44,7 +44,18 @@ SqrtLibrary to be ``True`` when building shared libraries. :caption: MathFunctions/CMakeLists.txt :name: MathFunctions/CMakeLists.txt-POSITION_INDEPENDENT_CODE :language: cmake - :lines: 37-42 + :start-at: # state that SqrtLibrary need PIC when the default is shared libraries + :end-at: ) + +Define ``EXPORTING_MYMATH`` stating we are using ``declspec(dllexport)`` when +building on Windows. + +.. literalinclude:: Step11/MathFunctions/CMakeLists.txt + :caption: MathFunctions/CMakeLists.txt + :name: MathFunctions/CMakeLists.txt-dll-export + :language: cmake + :start-at: # define the symbol stating we are using the declspec(dllexport) when + :end-at: target_compile_definitions(MathFunctions PRIVATE "EXPORTING_MYMATH") **Exercise**: We modified ``MathFunctions.h`` to use dll export defines. Using CMake documentation can you find a helper module to simplify this? diff --git a/Help/manual/cmake-env-variables.7.rst b/Help/manual/cmake-env-variables.7.rst index 197e56e..356e73d 100644 --- a/Help/manual/cmake-env-variables.7.rst +++ b/Help/manual/cmake-env-variables.7.rst @@ -43,6 +43,7 @@ Environment Variables that Control the Build /envvar/CMAKE_COLOR_DIAGNOSTICS /envvar/CMAKE_CONFIGURATION_TYPES /envvar/CMAKE_CONFIG_TYPE + /envvar/CMAKE_CROSSCOMPILING_EMULATOR /envvar/CMAKE_EXPORT_COMPILE_COMMANDS /envvar/CMAKE_GENERATOR /envvar/CMAKE_GENERATOR_INSTANCE diff --git a/Help/manual/cmake-policies.7.rst b/Help/manual/cmake-policies.7.rst index 7c48806..a018aff 100644 --- a/Help/manual/cmake-policies.7.rst +++ b/Help/manual/cmake-policies.7.rst @@ -51,6 +51,15 @@ The :variable:`CMAKE_MINIMUM_REQUIRED_VERSION` variable may also be used to determine whether to report an error on use of deprecated macros or functions. +Policies Introduced by CMake 3.28 +================================= + +.. toctree:: + :maxdepth: 1 + + CMP0153: The exec_program command should not be called. </policy/CMP0153> + CMP0152: file(REAL_PATH) resolves symlinks before collapsing ../ components. </policy/CMP0152> + Policies Introduced by CMake 3.27 ================================= diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index 4df0547..fa1d297 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -240,6 +240,11 @@ Properties on Targets /prop_tgt/IMPORTED /prop_tgt/IMPORTED_COMMON_LANGUAGE_RUNTIME /prop_tgt/IMPORTED_CONFIGURATIONS + /prop_tgt/IMPORTED_CXX_MODULES_COMPILE_DEFINITIONS + /prop_tgt/IMPORTED_CXX_MODULES_COMPILE_FEATURES + /prop_tgt/IMPORTED_CXX_MODULES_COMPILE_OPTIONS + /prop_tgt/IMPORTED_CXX_MODULES_INCLUDE_DIRECTORIES + /prop_tgt/IMPORTED_CXX_MODULES_LINK_LIBRARIES /prop_tgt/IMPORTED_GLOBAL /prop_tgt/IMPORTED_IMPLIB /prop_tgt/IMPORTED_IMPLIB_CONFIG @@ -503,6 +508,7 @@ Properties on Tests /prop_test/FIXTURES_CLEANUP /prop_test/FIXTURES_REQUIRED /prop_test/FIXTURES_SETUP + /prop_test/GENERATED_RESOURCE_SPEC_FILE /prop_test/LABELS /prop_test/MEASUREMENT /prop_test/PASS_REGULAR_EXPRESSION diff --git a/Help/manual/cmake-qt.7.rst b/Help/manual/cmake-qt.7.rst index d0d6ea0..e5a39f5 100644 --- a/Help/manual/cmake-qt.7.rst +++ b/Help/manual/cmake-qt.7.rst @@ -14,7 +14,7 @@ CMake can find and use Qt 4 and Qt 5 libraries. The Qt 4 libraries are found by the :module:`FindQt4` find-module shipped with CMake, whereas the Qt 5 libraries are found using "Config-file Packages" shipped with Qt 5. See :manual:`cmake-packages(7)` for more information about CMake packages, and -see `the Qt cmake manual <https://contribute.qt-project.org/doc/qt-5/cmake-manual.html>`_ +see `the Qt cmake manual <https://doc.qt.io/qt-5/cmake-manual.html>`_ for your Qt version. Qt 4 and Qt 5 may be used together in the same diff --git a/Help/manual/cmake-toolchains.7.rst b/Help/manual/cmake-toolchains.7.rst index a831fa6..e32bd29 100644 --- a/Help/manual/cmake-toolchains.7.rst +++ b/Help/manual/cmake-toolchains.7.rst @@ -573,12 +573,12 @@ See also target properties: * :prop_tgt:`ANDROID_SKIP_ANT_STEP` * :prop_tgt:`ANDROID_STL_TYPE` -.. _`Cross Compiling for iOS, tvOS, or watchOS`: +.. _`Cross Compiling for iOS, tvOS, visionOS, or watchOS`: -Cross Compiling for iOS, tvOS, or watchOS ------------------------------------------ +Cross Compiling for iOS, tvOS, visionOS, or watchOS +--------------------------------------------------- -For cross-compiling to iOS, tvOS, or watchOS, the :generator:`Xcode` +For cross-compiling to iOS, tvOS, visionOS, or watchOS, the :generator:`Xcode` generator is recommended. The :generator:`Unix Makefiles` or :generator:`Ninja` generators can also be used, but they require the project to handle more areas like target CPU selection and code signing. @@ -591,13 +591,14 @@ a different SDK (e.g. a simulator) can be selected by setting the necessary (see :ref:`Switching Between Device and Simulator` below). A list of available SDKs can be obtained by running ``xcodebuild -showsdks``. -======= ================= ==================== ================ -OS CMAKE_SYSTEM_NAME Device SDK (default) Simulator SDK -======= ================= ==================== ================ -iOS iOS iphoneos iphonesimulator -tvOS tvOS appletvos appletvsimulator -watchOS watchOS watchos watchsimulator -======= ================= ==================== ================ +======== ================= ==================== ================ +OS CMAKE_SYSTEM_NAME Device SDK (default) Simulator SDK +======== ================= ==================== ================ +iOS iOS iphoneos iphonesimulator +tvOS tvOS appletvos appletvsimulator +visionOS visionOS xros xrsimulator +watchOS watchOS watchos watchsimulator +======== ================= ==================== ================ For example, to create a CMake configuration for iOS, the following command is sufficient: @@ -608,7 +609,7 @@ command is sufficient: Variable :variable:`CMAKE_OSX_ARCHITECTURES` can be used to set architectures for both device and simulator. Variable :variable:`CMAKE_OSX_DEPLOYMENT_TARGET` -can be used to set an iOS/tvOS/watchOS deployment target. +can be used to set an iOS/tvOS/visionOS/watchOS deployment target. Next configuration will install fat 5 architectures iOS library and add the ``-miphoneos-version-min=9.3``/``-mios-simulator-version-min=9.3`` diff --git a/Help/manual/ctest.1.rst b/Help/manual/ctest.1.rst index 994ae47..effe4b1 100644 --- a/Help/manual/ctest.1.rst +++ b/Help/manual/ctest.1.rst @@ -1817,6 +1817,25 @@ The following variables are passed to the test process: uppercase in the ``CTEST_RESOURCE_GROUP_<num>_<resource-type>`` environment variable. +.. _`ctest-resource-dynamically-generated-spec-file`: + +Dynamically-Generated Resource Specification File +------------------------------------------------- + +.. versionadded:: 3.28 + +A project may optionally specify a single test which will be used to +dynamically generate the resource specification file that CTest will use for +scheduling tests that use resources. The test that generates the file must +have the :prop_test:`GENERATED_RESOURCE_SPEC_FILE` property set, and must have +exactly one fixture in its :prop_test:`FIXTURES_SETUP` property. This fixture +is considered by CTest to have special meaning: it's the fixture that generates +the resource spec file. The fixture may have any name. If such a fixture +exists, all tests that have :prop_test:`RESOURCE_GROUPS` set must have the +fixture in their :prop_test:`FIXTURES_REQUIRED`, and a resource spec file may +not be specified with the ``--resource-spec-file`` argument or the +:variable:`CTEST_RESOURCE_SPEC_FILE` variable. + See Also ======== diff --git a/Help/policy/CMP0152.rst b/Help/policy/CMP0152.rst new file mode 100644 index 0000000..d7e8692 --- /dev/null +++ b/Help/policy/CMP0152.rst @@ -0,0 +1,20 @@ +CMP0152 +------- + +.. versionadded:: 3.28 + +:command:`file(REAL_PATH)` resolves symlinks before collapsing ../ components. + +In CMake 3.27 and below, :command:`file(REAL_PATH)` collapsed any ``../`` +components in a path before resolving symlinks. This produced incorrect +results when the ``../`` collapsed away a symlink. + +The ``OLD`` behavior for this policy is to collapse ``../`` components before +resolving symlinks. +The ``NEW`` behavior for this policy is to resolve all symlinks before +collapsing ``../`` components. + +This policy was introduced in CMake version 3.28. Use the +:command:`cmake_policy` command to set it to ``OLD`` or ``NEW`` explicitly. + +.. include:: DEPRECATED.txt diff --git a/Help/policy/CMP0153.rst b/Help/policy/CMP0153.rst new file mode 100644 index 0000000..4c9f3dc --- /dev/null +++ b/Help/policy/CMP0153.rst @@ -0,0 +1,12 @@ +CMP0153 +------- + +The :command:`exec_program` command should not be called. + +This command has long been superseded by the :command:`execute_process` +command and has been deprecated since CMake 3.0. + +.. |disallowed_version| replace:: 3.28 +.. include:: DISALLOWED_COMMAND.txt + +.. include:: DEPRECATED.txt diff --git a/Help/prop_gbl/XCODE_EMIT_EFFECTIVE_PLATFORM_NAME.rst b/Help/prop_gbl/XCODE_EMIT_EFFECTIVE_PLATFORM_NAME.rst index 392b704..6794a26 100644 --- a/Help/prop_gbl/XCODE_EMIT_EFFECTIVE_PLATFORM_NAME.rst +++ b/Help/prop_gbl/XCODE_EMIT_EFFECTIVE_PLATFORM_NAME.rst @@ -16,8 +16,8 @@ generator emits the ``EFFECTIVE_PLATFORM_NAME`` variable: - If set to ``ON`` it will always be emitted - If set to ``OFF`` it will never be emitted - If unset (the default) it will only be emitted when the project was - configured for an embedded Xcode SDK like iOS, tvOS, watchOS or any - of the simulators. + configured for an embedded Xcode SDK like iOS, tvOS, visionOS, watchOS + or any of the simulators. .. note:: diff --git a/Help/prop_test/GENERATED_RESOURCE_SPEC_FILE.rst b/Help/prop_test/GENERATED_RESOURCE_SPEC_FILE.rst new file mode 100644 index 0000000..89596ac --- /dev/null +++ b/Help/prop_test/GENERATED_RESOURCE_SPEC_FILE.rst @@ -0,0 +1,7 @@ +GENERATED_RESOURCE_SPEC_FILE +---------------------------- + +.. versionadded:: 3.28 + +Path to the :ref:`dynamically-generated resource spec file +<ctest-resource-dynamically-generated-spec-file>` generated by this test. diff --git a/Help/prop_tgt/DLL_NAME_WITH_SOVERSION.rst b/Help/prop_tgt/DLL_NAME_WITH_SOVERSION.rst index 59ef00f..c86b218 100644 --- a/Help/prop_tgt/DLL_NAME_WITH_SOVERSION.rst +++ b/Help/prop_tgt/DLL_NAME_WITH_SOVERSION.rst @@ -3,8 +3,8 @@ DLL_NAME_WITH_SOVERSION .. versionadded:: 3.27 -This property control whether the :prop_tgt:`SOVERSION` target -property are added to the filename of generated DLL filenames +This property controls whether the :prop_tgt:`SOVERSION` target +property is added to the filename of generated DLL filenames for the Windows platform, which is selected when the :variable:`WIN32` variable is set. diff --git a/Help/prop_tgt/IMPORTED_CXX_MODULES_COMPILE_DEFINITIONS.rst b/Help/prop_tgt/IMPORTED_CXX_MODULES_COMPILE_DEFINITIONS.rst new file mode 100644 index 0000000..88687b2 --- /dev/null +++ b/Help/prop_tgt/IMPORTED_CXX_MODULES_COMPILE_DEFINITIONS.rst @@ -0,0 +1,14 @@ +IMPORTED_CXX_MODULES_COMPILE_DEFINITIONS +---------------------------------------- + +.. versionadded:: 3.28 + +.. note :: + + Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API`` + +Preprocessor definitions for compiling an ``IMPORTED`` target's C++ module +sources. + +CMake will automatically drop some definitions that are not supported +by the native build tool. diff --git a/Help/prop_tgt/IMPORTED_CXX_MODULES_COMPILE_FEATURES.rst b/Help/prop_tgt/IMPORTED_CXX_MODULES_COMPILE_FEATURES.rst new file mode 100644 index 0000000..c3eb7fb --- /dev/null +++ b/Help/prop_tgt/IMPORTED_CXX_MODULES_COMPILE_FEATURES.rst @@ -0,0 +1,13 @@ +IMPORTED_CXX_MODULES_COMPILE_FEATURES +------------------------------------- + +.. versionadded:: 3.28 + +.. note :: + + Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API`` + +Compiler features enabled for this ``IMPORTED`` target's C++ modules. + +The value of this property is used by the generators to set the include +paths for the compiler. diff --git a/Help/prop_tgt/IMPORTED_CXX_MODULES_COMPILE_OPTIONS.rst b/Help/prop_tgt/IMPORTED_CXX_MODULES_COMPILE_OPTIONS.rst new file mode 100644 index 0000000..5c62c77 --- /dev/null +++ b/Help/prop_tgt/IMPORTED_CXX_MODULES_COMPILE_OPTIONS.rst @@ -0,0 +1,13 @@ +IMPORTED_CXX_MODULES_COMPILE_OPTIONS +------------------------------------ + +.. versionadded:: 3.28 + +.. note :: + + Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API`` + +List of options to pass to the compiler for this ``IMPORTED`` target's C++ +modules. + +.. include:: ../command/OPTIONS_SHELL.txt diff --git a/Help/prop_tgt/IMPORTED_CXX_MODULES_INCLUDE_DIRECTORIES.rst b/Help/prop_tgt/IMPORTED_CXX_MODULES_INCLUDE_DIRECTORIES.rst new file mode 100644 index 0000000..08a993d --- /dev/null +++ b/Help/prop_tgt/IMPORTED_CXX_MODULES_INCLUDE_DIRECTORIES.rst @@ -0,0 +1,14 @@ +IMPORTED_CXX_MODULES_INCLUDE_DIRECTORIES +---------------------------------------- + +.. versionadded:: 3.28 + +.. note :: + + Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API`` + +List of preprocessor include file search directories when compiling C++ +modules for ``IMPORTED`` targets. + +The value of this property is used by the generators to set the include +paths for the compiler. diff --git a/Help/prop_tgt/IMPORTED_CXX_MODULES_LINK_LIBRARIES.rst b/Help/prop_tgt/IMPORTED_CXX_MODULES_LINK_LIBRARIES.rst new file mode 100644 index 0000000..5111dc5 --- /dev/null +++ b/Help/prop_tgt/IMPORTED_CXX_MODULES_LINK_LIBRARIES.rst @@ -0,0 +1,11 @@ +IMPORTED_CXX_MODULES_LINK_LIBRARIES +----------------------------------- + +.. versionadded:: 3.28 + +.. note :: + + Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API`` + +List of direct dependencies to use for usage requirements for C++ modules in +the target's C++ modules. diff --git a/Help/prop_tgt/IMPORTED_IMPLIB.rst b/Help/prop_tgt/IMPORTED_IMPLIB.rst index e67acba..27601d2 100644 --- a/Help/prop_tgt/IMPORTED_IMPLIB.rst +++ b/Help/prop_tgt/IMPORTED_IMPLIB.rst @@ -11,6 +11,12 @@ This property may be set: * On macOS, to an import file (e.g. ``.tbd``) created for shared libraries (see the :prop_tgt:`ENABLE_EXPORTS` target property). For frameworks this is the location of the ``.tbd`` file symlink just inside the framework folder. +* .. versionadded:: 3.28 + On non-DLL platforms, to the location of a shared library. + When set without also specifying an :prop_tgt:`IMPORTED_LOCATION`, + the library is considered to be a stub, and its location will not + be added as a runtime search path to dependents that link it. + The ``IMPORTED_IMPLIB`` target property may be overridden for a given configuration ``<CONFIG>`` by the configuration-specific diff --git a/Help/prop_tgt/IMPORTED_LOCATION.rst b/Help/prop_tgt/IMPORTED_LOCATION.rst index a7207d8..915085b 100644 --- a/Help/prop_tgt/IMPORTED_LOCATION.rst +++ b/Help/prop_tgt/IMPORTED_LOCATION.rst @@ -15,6 +15,17 @@ is the location of the ``.dll`` part of the library. For ``UNKNOWN`` libraries this is the location of the file to be linked. Ignored for non-imported targets. +.. versionadded:: 3.28 + + For frameworks on macOS, this may be the location of the framework folder + itself. + +.. versionadded:: 3.28 + + This may be the location of a ``.xcframework`` folder on macOS. If it is, + any target that links against it will get the selected library's ``Headers`` + directory as a usage requirement. + The ``IMPORTED_LOCATION`` target property may be overridden for a given configuration ``<CONFIG>`` by the configuration-specific :prop_tgt:`IMPORTED_LOCATION_<CONFIG>` target property. Furthermore, diff --git a/Help/prop_tgt/IMPORTED_OBJECTS.rst b/Help/prop_tgt/IMPORTED_OBJECTS.rst index d71c219..9aacea7 100644 --- a/Help/prop_tgt/IMPORTED_OBJECTS.rst +++ b/Help/prop_tgt/IMPORTED_OBJECTS.rst @@ -31,7 +31,7 @@ once per architecture for each source file. Unlike the other generators, it does not generate universal object file binaries. A further complication with the :generator:`Xcode` generator is that when -targeting device platforms (iOS, tvOS or watchOS), the :generator:`Xcode` +targeting device platforms (iOS, tvOS, visionOS or watchOS), the :generator:`Xcode` generator has the ability to use either the device or simulator SDK without needing CMake to be re-run. The SDK can be selected at build time. But since some architectures can be supported by both the device and the diff --git a/Help/prop_tgt/IOS_INSTALL_COMBINED.rst b/Help/prop_tgt/IOS_INSTALL_COMBINED.rst index 92d60dc..c296691 100644 --- a/Help/prop_tgt/IOS_INSTALL_COMBINED.rst +++ b/Help/prop_tgt/IOS_INSTALL_COMBINED.rst @@ -2,18 +2,27 @@ IOS_INSTALL_COMBINED -------------------- .. versionadded:: 3.5 +.. deprecated:: 3.28 + + :prop_tgt:`IOS_INSTALL_COMBINED` was designed to make universal binaries + containing iOS/arm* device code paired with iOS Simulator/x86_64 code + (or similar for other Apple embedded platforms). Universal binaries can only + differentiate code based on CPU type, so this only made sense before the + days of arm64 macOS machines (i.e. iOS Simulator/arm64). Apple now + recommends xcframeworks, which contain multiple binaries for different + platforms, for this use case. Build a combined (device and simulator) target when installing. -When this property is set to set to false (which is the default) then it will +When this property is set to false, which is the default, then it will either be built with the device SDK or the simulator SDK depending on the SDK set. But if this property is set to true then the target will at install time -also be built for the corresponding SDK and combined into one library. +also be built for the other SDK and combined into one library. .. note:: - If a selected architecture is available for both: device SDK and simulator + If a selected architecture is available for both device SDK and simulator SDK it will be built for the SDK selected by :variable:`CMAKE_OSX_SYSROOT` - and removed from the corresponding SDK. + and removed from the other SDK. This feature requires at least Xcode version 6. diff --git a/Help/prop_tgt/Swift_LANGUAGE_VERSION.rst b/Help/prop_tgt/Swift_LANGUAGE_VERSION.rst index afc6b31..d1d80a8 100644 --- a/Help/prop_tgt/Swift_LANGUAGE_VERSION.rst +++ b/Help/prop_tgt/Swift_LANGUAGE_VERSION.rst @@ -4,5 +4,6 @@ Swift_LANGUAGE_VERSION .. versionadded:: 3.16 This property sets the language version for the Swift sources in the target. If -one is not specified, it will default to ``<CMAKE_Swift_LANGUAGE_VERSION>`` if -specified, otherwise it is the latest version supported by the compiler. +one is not specified, it will default to +:variable:`CMAKE_Swift_LANGUAGE_VERSION` if specified, otherwise it is the +latest version supported by the compiler. diff --git a/Help/prop_tgt/VS_DEBUGGER_COMMAND.rst b/Help/prop_tgt/VS_DEBUGGER_COMMAND.rst index 5bf47a3..8c136f2 100644 --- a/Help/prop_tgt/VS_DEBUGGER_COMMAND.rst +++ b/Help/prop_tgt/VS_DEBUGGER_COMMAND.rst @@ -11,5 +11,5 @@ project file. This property is initialized by the value of the variable :variable:`CMAKE_VS_DEBUGGER_COMMAND` if it is set when a target is created. -This property only works for Visual Studio 11 2012 and above; +This property only works for Visual Studio 12 2013 and above; it is ignored on other generators. diff --git a/Help/prop_tgt/VS_DEBUGGER_COMMAND_ARGUMENTS.rst b/Help/prop_tgt/VS_DEBUGGER_COMMAND_ARGUMENTS.rst index 4b9dff7..2656826 100644 --- a/Help/prop_tgt/VS_DEBUGGER_COMMAND_ARGUMENTS.rst +++ b/Help/prop_tgt/VS_DEBUGGER_COMMAND_ARGUMENTS.rst @@ -11,5 +11,5 @@ project file. This property is initialized by the value of the variable :variable:`CMAKE_VS_DEBUGGER_COMMAND_ARGUMENTS` if it is set when a target is created. -This property only works for Visual Studio 11 2012 and above; +This property only works for Visual Studio 12 2013 and above; it is ignored on other generators. diff --git a/Help/prop_tgt/VS_DEBUGGER_ENVIRONMENT.rst b/Help/prop_tgt/VS_DEBUGGER_ENVIRONMENT.rst index 8373dbb..d78d594 100644 --- a/Help/prop_tgt/VS_DEBUGGER_ENVIRONMENT.rst +++ b/Help/prop_tgt/VS_DEBUGGER_ENVIRONMENT.rst @@ -11,5 +11,5 @@ project file. This property is initialized by the value of the variable :variable:`CMAKE_VS_DEBUGGER_ENVIRONMENT` if it is set when a target is created. -This property only works for Visual Studio 11 2012 and above; +This property only works for Visual Studio 12 2013 and above; it is ignored on other generators. diff --git a/Help/prop_tgt/VS_DEBUGGER_WORKING_DIRECTORY.rst b/Help/prop_tgt/VS_DEBUGGER_WORKING_DIRECTORY.rst index 3942047..1026dfa 100644 --- a/Help/prop_tgt/VS_DEBUGGER_WORKING_DIRECTORY.rst +++ b/Help/prop_tgt/VS_DEBUGGER_WORKING_DIRECTORY.rst @@ -11,5 +11,5 @@ project file. This property is initialized by the value of the variable :variable:`CMAKE_VS_DEBUGGER_WORKING_DIRECTORY` if it is set when a target is created. -This property only works for Visual Studio 11 2012 and above; +This property only works for Visual Studio 12 2013 and above; it is ignored on other generators. diff --git a/Help/prop_tgt/VS_DOTNET_STARTUP_OBJECT.rst b/Help/prop_tgt/VS_DOTNET_STARTUP_OBJECT.rst index 8a85ba4..eeb7dda 100644 --- a/Help/prop_tgt/VS_DOTNET_STARTUP_OBJECT.rst +++ b/Help/prop_tgt/VS_DOTNET_STARTUP_OBJECT.rst @@ -12,7 +12,7 @@ If the property is unset, Visual Studio uses the first matching than one ``Main()`` method is available in the current project, the property becomes mandatory for building the project. -This property only works for Visual Studio 11 2012 and above; +This property only works for Visual Studio 12 2013 and above; it is ignored on other generators. .. code-block:: cmake diff --git a/Help/prop_tgt/VS_KEYWORD.rst b/Help/prop_tgt/VS_KEYWORD.rst index 221b986..f04d109 100644 --- a/Help/prop_tgt/VS_KEYWORD.rst +++ b/Help/prop_tgt/VS_KEYWORD.rst @@ -7,4 +7,4 @@ Can be set to change the visual studio keyword, for example Qt integration works better if this is set to Qt4VSv1.0. Use the :prop_tgt:`VS_GLOBAL_KEYWORD` target property to set the -keyword for Visual Studio 11 (2012) and newer. +keyword for Visual Studio 12 (2013) and newer. diff --git a/Help/prop_tgt/XCODE_EMBED_type.rst b/Help/prop_tgt/XCODE_EMBED_type.rst index da744c2..76b0e3d 100644 --- a/Help/prop_tgt/XCODE_EMBED_type.rst +++ b/Help/prop_tgt/XCODE_EMBED_type.rst @@ -37,6 +37,12 @@ The supported values for ``<type>`` are: The specified items will be added to the ``Embed PlugIns`` build phase. They must be CMake target names. +``RESOURCES`` + .. versionadded:: 3.28 + + The specified items will be added to the ``Embed Resources`` build phase. + They must be CMake target names. + See also :prop_tgt:`XCODE_EMBED_<type>_PATH`, :prop_tgt:`XCODE_EMBED_<type>_REMOVE_HEADERS_ON_COPY` and :prop_tgt:`XCODE_EMBED_<type>_CODE_SIGN_ON_COPY`. diff --git a/Help/prop_tgt/XCODE_EMBED_type_PATH.rst b/Help/prop_tgt/XCODE_EMBED_type_PATH.rst index 5a5c65f..ef04d14 100644 --- a/Help/prop_tgt/XCODE_EMBED_type_PATH.rst +++ b/Help/prop_tgt/XCODE_EMBED_type_PATH.rst @@ -22,3 +22,6 @@ The supported values for ``<type>`` are: ``PLUGINS`` .. versionadded:: 3.23 + +``RESOURCES`` + .. versionadded:: 3.28 diff --git a/Help/release/3.14.rst b/Help/release/3.14.rst index 8a9738c..5fedf7d 100644 --- a/Help/release/3.14.rst +++ b/Help/release/3.14.rst @@ -63,7 +63,8 @@ File-Based API Platforms --------- -* CMake now supports :ref:`Cross Compiling for iOS, tvOS, or watchOS` +* CMake now supports + :ref:`Cross Compiling for iOS, tvOS, or watchOS <Cross Compiling for iOS, tvOS, visionOS, or watchOS>` using simple toolchain files. Command-Line diff --git a/Help/release/dev/0-sample-topic.rst b/Help/release/dev/0-sample-topic.rst new file mode 100644 index 0000000..e4cc01e --- /dev/null +++ b/Help/release/dev/0-sample-topic.rst @@ -0,0 +1,7 @@ +0-sample-topic +-------------- + +* This is a sample release note for the change in a topic. + Developers should add similar notes for each topic branch + making a noteworthy change. Each document should be named + and titled to match the topic name to avoid merge conflicts. diff --git a/Help/release/dev/CMAKE_CROSSCOMPILING_EMULATOR-env-variable.rst b/Help/release/dev/CMAKE_CROSSCOMPILING_EMULATOR-env-variable.rst new file mode 100644 index 0000000..269e739 --- /dev/null +++ b/Help/release/dev/CMAKE_CROSSCOMPILING_EMULATOR-env-variable.rst @@ -0,0 +1,6 @@ +CMAKE_CROSSCOMPILING_EMULATOR-env-variable +------------------------------------------ + +* The :envvar:`CMAKE_CROSSCOMPILING_EMULATOR` environment variable + was added to initialize the :variable:`CMAKE_CROSSCOMPILING_EMULATOR` + cache variable. diff --git a/Help/release/dev/ExternalProject-build-jobserver.rst b/Help/release/dev/ExternalProject-build-jobserver.rst new file mode 100644 index 0000000..357da42 --- /dev/null +++ b/Help/release/dev/ExternalProject-build-jobserver.rst @@ -0,0 +1,10 @@ +ExternalProject-build-jobserver +------------------------------- + +* The :module:`ExternalProject` module now includes the + ``BUILD_JOB_SERVER_AWARE`` option for the + :command:`ExternalProject_Add` command. This option enables + the integration of the GNU Make job server when using an + explicit ``BUILD_COMMAND`` with certain :ref:`Makefile Generators`. + Additionally, the :command:`ExternalProject_Add_Step` command + has been updated to support the new ``JOB_SERVER_AWARE`` option. diff --git a/Help/release/dev/FindCURL-static.rst b/Help/release/dev/FindCURL-static.rst new file mode 100644 index 0000000..3c369d2 --- /dev/null +++ b/Help/release/dev/FindCURL-static.rst @@ -0,0 +1,5 @@ +FindCURL-static +--------------- + +* The :module:`FindCURL` module gained a ``CURL_USE_STATIC_LIBS`` hint + to select static libraries. diff --git a/Help/release/dev/FindEXPAT-static.rst b/Help/release/dev/FindEXPAT-static.rst new file mode 100644 index 0000000..8808ebd --- /dev/null +++ b/Help/release/dev/FindEXPAT-static.rst @@ -0,0 +1,5 @@ +FindEXPAT-static +---------------- + +* The :module:`FindEXPAT` module gained a ``EXPAT_USE_STATIC_LIBS`` hint + to select static libraries. diff --git a/Help/release/dev/apple-visionos.rst b/Help/release/dev/apple-visionos.rst new file mode 100644 index 0000000..db76248 --- /dev/null +++ b/Help/release/dev/apple-visionos.rst @@ -0,0 +1,7 @@ +apple-visionos +-------------- + +* CMake learned about Apple visionOS and its `xros` and `xrsimulator` SDKs. + Compiling for Apple visionOS can be requested by setting + :variable:`CMAKE_SYSTEM_NAME` to ``visionOS``. For more + information see :manual:`cmake-toolchains(7)`. diff --git a/Help/release/dev/command-job-server-aware.rst b/Help/release/dev/command-job-server-aware.rst new file mode 100644 index 0000000..224c739 --- /dev/null +++ b/Help/release/dev/command-job-server-aware.rst @@ -0,0 +1,5 @@ +command-job-server-aware +------------------------ + +* The :command:`add_custom_command` and :command:`add_custom_target` + commands gained a ``JOB_SERVER_AWARE`` option. diff --git a/Help/release/dev/deprecate-install-combined.rst b/Help/release/dev/deprecate-install-combined.rst new file mode 100644 index 0000000..12a0a43 --- /dev/null +++ b/Help/release/dev/deprecate-install-combined.rst @@ -0,0 +1,6 @@ +deprecate-install-combined +-------------------------- + +* The :prop_tgt:`IOS_INSTALL_COMBINED` target property and corresponding + :variable:`CMAKE_IOS_INSTALL_COMBINED` variable have been deprecated. + Their functionality does not make sense on Apple Silicon hosts. diff --git a/Help/release/dev/dynamically-generated-resource-spec-file.rst b/Help/release/dev/dynamically-generated-resource-spec-file.rst new file mode 100644 index 0000000..c4b3899 --- /dev/null +++ b/Help/release/dev/dynamically-generated-resource-spec-file.rst @@ -0,0 +1,6 @@ +dynamically-generated-resource-spec-file +---------------------------------------- + +* CTest may now take a :ref:`dynamically-generated resource spec file + <ctest-resource-dynamically-generated-spec-file>`, which can be specified by the + :prop_test:`GENERATED_RESOURCE_SPEC_FILE` test property. diff --git a/Help/release/dev/exec_program-policy.rst b/Help/release/dev/exec_program-policy.rst new file mode 100644 index 0000000..8ddae5b --- /dev/null +++ b/Help/release/dev/exec_program-policy.rst @@ -0,0 +1,6 @@ +exec_program-policy +------------------- + +* The :command:`exec_program` command, which has been deprecated since CMake + 3.0, has been removed by policy :policy:`CMP0153`. Use the + :command:`execute_process` command instead. diff --git a/Help/release/dev/imported-implib-only.rst b/Help/release/dev/imported-implib-only.rst new file mode 100644 index 0000000..aa817b7 --- /dev/null +++ b/Help/release/dev/imported-implib-only.rst @@ -0,0 +1,7 @@ +imported-implib-only +-------------------- + +* On imported shared libraries, the :prop_tgt:`IMPORTED_IMPLIB` target + property may now be used without :prop_tgt:`IMPORTED_LOCATION`. + This can be used to represent a stub library whose location should not + be added as a runtime search path to dependents that link it. diff --git a/Help/release/dev/imported-target-framework-path.rst b/Help/release/dev/imported-target-framework-path.rst new file mode 100644 index 0000000..68c3431 --- /dev/null +++ b/Help/release/dev/imported-target-framework-path.rst @@ -0,0 +1,5 @@ +imported-target-framework-path +------------------------------ + +* The :prop_tgt:`IMPORTED_LOCATION` property of a macOS framework may now be + the location of the framework folder itself. diff --git a/Help/release/dev/rel-linux-x86_64.rst b/Help/release/dev/rel-linux-x86_64.rst new file mode 100644 index 0000000..8302a1c --- /dev/null +++ b/Help/release/dev/rel-linux-x86_64.rst @@ -0,0 +1,5 @@ +rel-linux-x86_64 +---------------- + +* The precompiled Linux ``x86_64`` binaries provided on + `cmake.org <https://cmake.org/download/>`_ now require GLIBC 2.17 or higher. diff --git a/Help/release/dev/remove-vs11-generator.rst b/Help/release/dev/remove-vs11-generator.rst new file mode 100644 index 0000000..971d679 --- /dev/null +++ b/Help/release/dev/remove-vs11-generator.rst @@ -0,0 +1,4 @@ +remove-vs11-generator +--------------------- + +* The :generator:`Visual Studio 11 2012` generator has been removed. diff --git a/Help/release/dev/test-properties-directory.rst b/Help/release/dev/test-properties-directory.rst new file mode 100644 index 0000000..9df7051 --- /dev/null +++ b/Help/release/dev/test-properties-directory.rst @@ -0,0 +1,15 @@ +test-properties-directory +------------------------- + +* The ``TEST`` mode of the :command:`set_property` command gained a + ``DIRECTORY`` sub-option, which allows you to set properties on tests in + other directories. +* The :command:`set_tests_properties` command gained a ``DIRECTORY`` + sub-option, which allows you to set properties on tests in other + directories. +* The ``TEST`` mode of the :command:`get_property` command gained a + ``DIRECTORY`` sub-option, which allows you to get properties on tests in + other directories. +* The :command:`get_test_property` command gained a ``DIRECTORY`` + sub-option, which allows you to get properties on tests in other + directories. diff --git a/Help/release/dev/vs12-deprecate.rst b/Help/release/dev/vs12-deprecate.rst new file mode 100644 index 0000000..23d7e2a --- /dev/null +++ b/Help/release/dev/vs12-deprecate.rst @@ -0,0 +1,5 @@ +vs12-deprecate +-------------- + +* The :generator:`Visual Studio 12 2013` generator is now deprecated + and will be removed in a future version of CMake. diff --git a/Help/release/dev/xcframework-find-library.rst b/Help/release/dev/xcframework-find-library.rst new file mode 100644 index 0000000..527270e --- /dev/null +++ b/Help/release/dev/xcframework-find-library.rst @@ -0,0 +1,5 @@ +xcframework-find-library +------------------------ + +* The :command:`find_library` command can now find ``.xcframework`` folders on + Apple platforms. diff --git a/Help/release/dev/xcframework-target-link-libraries.rst b/Help/release/dev/xcframework-target-link-libraries.rst new file mode 100644 index 0000000..7edded5 --- /dev/null +++ b/Help/release/dev/xcframework-target-link-libraries.rst @@ -0,0 +1,7 @@ +xcframework-target-link-libraries +--------------------------------- + +* Targets may now link against an ``.xcframework`` folder in + :command:`target_link_libraries`. +* The :prop_tgt:`IMPORTED_LOCATION` property of a target may now be an + ``.xcframework`` folder. diff --git a/Help/release/dev/xcode-embed-resources.rst b/Help/release/dev/xcode-embed-resources.rst new file mode 100644 index 0000000..2678cfd --- /dev/null +++ b/Help/release/dev/xcode-embed-resources.rst @@ -0,0 +1,6 @@ +xcode-embed-resources +--------------------- + +* The :prop_tgt:`XCODE_EMBED_RESOURCES <XCODE_EMBED_<type>>` target property + was added to tell the :generator:`Xcode` generator what targets to put in + the ``Embed Resources`` build phase. diff --git a/Help/release/index.rst b/Help/release/index.rst index fc1f744..3851b7e 100644 --- a/Help/release/index.rst +++ b/Help/release/index.rst @@ -7,6 +7,8 @@ CMake Release Notes This file should include the adjacent "dev.txt" file in development versions but not in release versions. +.. include:: dev.txt + Releases ======== diff --git a/Help/variable/APPLE.rst b/Help/variable/APPLE.rst index 810d5fc..e799397 100644 --- a/Help/variable/APPLE.rst +++ b/Help/variable/APPLE.rst @@ -2,4 +2,4 @@ APPLE ----- Set to ``True`` when the target system is an Apple platform -(macOS, iOS, tvOS or watchOS). +(macOS, iOS, tvOS, visionOS or watchOS). diff --git a/Help/variable/CMAKE_CFG_INTDIR.rst b/Help/variable/CMAKE_CFG_INTDIR.rst index 3a57659..3045d91 100644 --- a/Help/variable/CMAKE_CFG_INTDIR.rst +++ b/Help/variable/CMAKE_CFG_INTDIR.rst @@ -19,7 +19,7 @@ Example values: :: $(ConfigurationName) = Visual Studio 9 - $(Configuration) = Visual Studio 11 and above + $(Configuration) = Visual Studio 12 and above $(CONFIGURATION) = Xcode . = Make-based tools . = Ninja diff --git a/Help/variable/CMAKE_CROSSCOMPILING_EMULATOR.rst b/Help/variable/CMAKE_CROSSCOMPILING_EMULATOR.rst index e21b35d..1c3a26c 100644 --- a/Help/variable/CMAKE_CROSSCOMPILING_EMULATOR.rst +++ b/Help/variable/CMAKE_CROSSCOMPILING_EMULATOR.rst @@ -12,6 +12,10 @@ for the target system. Lists>`, then the first value is the command and remaining values are its arguments. +.. versionadded:: 3.28 + This variable can be initialized via an + :envvar:`CMAKE_CROSSCOMPILING_EMULATOR` environment variable. + The command will be used to run :command:`try_run` generated executables, which avoids manual population of the ``TryRunResults.cmake`` file. diff --git a/Help/variable/CMAKE_CUDA_HOST_COMPILER.rst b/Help/variable/CMAKE_CUDA_HOST_COMPILER.rst index 9817b1a..6e2d756 100644 --- a/Help/variable/CMAKE_CUDA_HOST_COMPILER.rst +++ b/Help/variable/CMAKE_CUDA_HOST_COMPILER.rst @@ -26,4 +26,11 @@ is read-only and changes to it are undefined behavior. .. note:: + Projects should not try to set ``CMAKE_CUDA_HOST_COMPILER`` to match + :variable:`CMAKE_CXX_COMPILER <CMAKE_<LANG>_COMPILER>` themselves. + It is the end-user's responsibility, not the project's, to ensure that + the C++ and CUDA compilers target the same ABI. + +.. note:: + Ignored when using :ref:`Visual Studio Generators`. diff --git a/Help/variable/CMAKE_IOS_INSTALL_COMBINED.rst b/Help/variable/CMAKE_IOS_INSTALL_COMBINED.rst index cd7fd8d..0024ba9 100644 --- a/Help/variable/CMAKE_IOS_INSTALL_COMBINED.rst +++ b/Help/variable/CMAKE_IOS_INSTALL_COMBINED.rst @@ -2,6 +2,9 @@ CMAKE_IOS_INSTALL_COMBINED -------------------------- .. versionadded:: 3.5 +.. deprecated:: 3.28 + + This is deprecated because :prop_tgt:`IOS_INSTALL_COMBINED` is deprecated. Default value for :prop_tgt:`IOS_INSTALL_COMBINED` of targets. diff --git a/Help/variable/CMAKE_MACOSX_BUNDLE.rst b/Help/variable/CMAKE_MACOSX_BUNDLE.rst index 43ddff5..483c5b3 100644 --- a/Help/variable/CMAKE_MACOSX_BUNDLE.rst +++ b/Help/variable/CMAKE_MACOSX_BUNDLE.rst @@ -7,4 +7,4 @@ This variable is used to initialize the :prop_tgt:`MACOSX_BUNDLE` property on all the targets. See that target property for additional information. This variable is set to ``ON`` by default if :variable:`CMAKE_SYSTEM_NAME` -equals to :ref:`iOS, tvOS or watchOS <Cross Compiling for iOS, tvOS, or watchOS>`. +equals to :ref:`iOS, tvOS, visionOS or watchOS <Cross Compiling for iOS, tvOS, visionOS, or watchOS>`. diff --git a/Help/variable/CMAKE_OSX_VARIABLE.txt b/Help/variable/CMAKE_OSX_VARIABLE.txt index 5670980..962fcd3 100644 --- a/Help/variable/CMAKE_OSX_VARIABLE.txt +++ b/Help/variable/CMAKE_OSX_VARIABLE.txt @@ -7,6 +7,6 @@ remove it while initializing a cache entry of the same name) unless policy :policy:`CMP0126` is set to ``NEW``. Despite the ``OSX`` part in the variable name(s) they apply also to -other SDKs than macOS like iOS, tvOS, or watchOS. +other SDKs than macOS like iOS, tvOS, visionOS, or watchOS. This variable is ignored on platforms other than Apple. diff --git a/Help/variable/CMAKE_VS_DEVENV_COMMAND.rst b/Help/variable/CMAKE_VS_DEVENV_COMMAND.rst index 2bb97c4..155931f 100644 --- a/Help/variable/CMAKE_VS_DEVENV_COMMAND.rst +++ b/Help/variable/CMAKE_VS_DEVENV_COMMAND.rst @@ -10,5 +10,5 @@ This variable is not defined by other generators even if ``devenv.com`` is installed on the computer. The :variable:`CMAKE_VS_MSBUILD_COMMAND` is also provided for -:generator:`Visual Studio 11 2012` and above. +:generator:`Visual Studio 12 2013` and above. See also the :variable:`CMAKE_MAKE_PROGRAM` variable. diff --git a/Help/variable/CMAKE_VS_MSBUILD_COMMAND.rst b/Help/variable/CMAKE_VS_MSBUILD_COMMAND.rst index 8a521a3..96924d5 100644 --- a/Help/variable/CMAKE_VS_MSBUILD_COMMAND.rst +++ b/Help/variable/CMAKE_VS_MSBUILD_COMMAND.rst @@ -1,7 +1,7 @@ CMAKE_VS_MSBUILD_COMMAND ------------------------ -The generators for :generator:`Visual Studio 11 2012` and above set this +The generators for :generator:`Visual Studio 12 2013` and above set this variable to the ``MSBuild.exe`` command installed with the corresponding Visual Studio version. diff --git a/Help/variable/ENV.rst b/Help/variable/ENV.rst index 6791853..71df3dd 100644 --- a/Help/variable/ENV.rst +++ b/Help/variable/ENV.rst @@ -8,6 +8,17 @@ Use the syntax ``$ENV{VAR}`` to read environment variable ``VAR``. To test whether an environment variable is defined, use the signature ``if(DEFINED ENV{<name>})`` of the :command:`if` command. +.. note:: + + Environment variable names containing special characters like parentheses + may need to be escaped. (Policy :policy:`CMP0053` must also be enabled.) + For example, to get the value of the Windows environment variable + ``ProgramFiles(x86)``, use: + + .. code-block:: cmake + + set(ProgramFiles_x86 "$ENV{ProgramFiles\(x86\)}") + For general information on environment variables, see the :ref:`Environment Variables <CMake Language Environment Variables>` section in the :manual:`cmake-language(7)` manual. |