code:
ISPC_INSTRUCTION_SETS
---------------------

.. versionadded:: 3.19

List of instruction set architectures to generate code for.

This property is initialized by the value of the :variable:`CMAKE_ISPC_INSTRUCTION_SETS`
variable if it is set when a target is created.

The ``ISPC_INSTRUCTION_SETS`` target property must be used when generating for multiple
instruction sets so that CMake can track what object files will be generated.

Examples
^^^^^^^^

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY ISPC_INSTRUCTION_SETS avx2-i32x4 avx512skx-i32x835)

Generates code for avx2 and avx512skx target architectures.


code:
JOB_POOL_COMPILE
----------------

Ninja only: Pool used for compiling.

The number of parallel compile processes could be limited by defining
pools with the global :prop_gbl:`JOB_POOLS`
property and then specifying here the pool name.

For instance:

.. code-block:: cmake

  set_property(TARGET myexe PROPERTY JOB_POOL_COMPILE ten_jobs)

This property is initialized by the value of
:variable:`CMAKE_JOB_POOL_COMPILE`.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
JOB_POOL_LINK
-------------

Ninja only: Pool used for linking.

The number of parallel link processes could be limited by defining
pools with the global :prop_gbl:`JOB_POOLS`
property and then specifying here the pool name.

For instance:

.. code-block:: cmake

  set_property(TARGET myexe PROPERTY JOB_POOL_LINK two_jobs)

This property is initialized by the value of :variable:`CMAKE_JOB_POOL_LINK`.


code:
JOB_POOL_PRECOMPILE_HEADER
--------------------------

.. versionadded:: 3.17

Ninja only: Pool used for generating pre-compiled headers.

The number of parallel compile processes could be limited by defining
pools with the global :prop_gbl:`JOB_POOLS`
property and then specifying here the pool name.

For instance:

.. code-block:: cmake

  set_property(TARGET myexe PROPERTY JOB_POOL_PRECOMPILE_HEADER two_jobs)

This property is initialized by the value of
:variable:`CMAKE_JOB_POOL_PRECOMPILE_HEADER`.

If neither ``JOB_POOL_PRECOMPILE_HEADER`` nor
:variable:`CMAKE_JOB_POOL_PRECOMPILE_HEADER` are set then
:prop_tgt:`JOB_POOL_COMPILE` will be used for this task.


code:
LABELS
------

Specify a list of text labels associated with a target.

Target label semantics are currently unspecified.


code:
<LANG>_CLANG_TIDY
-----------------

.. versionadded:: 3.6

This property is implemented only when ``<LANG>`` is ``C``, ``CXX``, ``OBJC``
or ``OBJCXX``.

Specify a :ref:`semicolon-separated list <CMake Language Lists>` containing
a command line for the ``clang-tidy`` tool.  The :ref:`Makefile Generators`
and the :generator:`Ninja` generator will run this tool along with the
compiler and report a warning if the tool reports any problems.

The specified ``clang-tidy`` command line will be invoked with additional
arguments specifying the source file and, after ``--``, the full compiler
command line.

.. versionchanged:: 3.25

  If the specified ``clang-tidy`` command line includes the ``-p`` option,
  it will be invoked without ``--`` and the full compiler command line.
  ``clang-tidy`` will look up the source file in the specified compiler
  commands database.

This property is initialized by the value of
the :variable:`CMAKE_<LANG>_CLANG_TIDY` variable if it is set
when a target is created.

.. versionadded:: 3.27

  This property supports
  :manual:`generator expressions <cmake-generator-expressions(7)>`.

.. versionadded:: 3.27

  :prop_sf:`SKIP_LINTING` can be set on individual source files to exclude
  them from the linting tools defined by :prop_tgt:`<LANG>_CPPLINT`,
  ``<LANG>_CLANG_TIDY``, :prop_tgt:`<LANG>_CPPCHECK`, and
  :prop_tgt:`<LANG>_INCLUDE_WHAT_YOU_USE`.  When :prop_sf:`SKIP_LINTING` is
  set to true on a source file, those tools will not be run on that specific
  file.


code:
<LANG>_CLANG_TIDY_EXPORT_FIXES_DIR
----------------------------------

.. versionadded:: 3.26

This property is implemented only when ``<LANG>`` is ``C``, ``CXX``, ``OBJC``
or ``OBJCXX``, and only has an effect when :prop_tgt:`<LANG>_CLANG_TIDY` is
set.

Specify a directory for the ``clang-tidy`` tool to put ``.yaml`` files
containing its suggested changes in. This can be used for automated mass
refactoring by ``clang-tidy``. Each object file that gets compiled will have a
corresponding ``.yaml`` file in this directory. After the build is completed,
you can run ``clang-apply-replacements`` on this directory to simultaneously
apply all suggested changes to the code base. If this property is not an
absolute directory, it is assumed to be relative to the target's binary
directory. This property should be preferred over adding an ``--export-fixes``
or ``--fix`` argument directly to the :prop_tgt:`<LANG>_CLANG_TIDY` property.

When this property is set, CMake takes ownership of the specified directory,
and may create, modify, or delete files and directories within the directory
at any time during configure or build time. Users should use a dedicated
directory for exporting clang-tidy fixes to avoid having files deleted or
overwritten by CMake. Users should not create, modify, or delete files in this
directory.

This property is initialized by the value of
the :variable:`CMAKE_<LANG>_CLANG_TIDY_EXPORT_FIXES_DIR` variable if it is set
when a target is created.


code:
<LANG>_COMPILER_LAUNCHER
------------------------

.. versionadded:: 3.4

This property is implemented only when ``<LANG>`` is ``C``, ``CXX``,
``Fortran``, ``HIP``, ``ISPC``, ``OBJC``, ``OBJCXX``, or ``CUDA``.

Specify a :ref:`semicolon-separated list <CMake Language Lists>` containing a command line
for a compiler launching tool. The :ref:`Makefile Generators` and the
:generator:`Ninja` generator will run this tool and pass the compiler and
its arguments to the tool. Some example tools are distcc and ccache.

This property is initialized by the value of
the :variable:`CMAKE_<LANG>_COMPILER_LAUNCHER` variable if it is set
when a target is created.

.. versionadded:: 3.25

  The property value may use
  :manual:`generator expressions <cmake-generator-expressions(7)>`.


code:
<LANG>_CPPCHECK
---------------

.. versionadded:: 3.10

This property is supported only when ``<LANG>`` is ``C`` or ``CXX``.

Specify a :ref:`semicolon-separated list <CMake Language Lists>` containing a command line
for the ``cppcheck`` static analysis tool.  The :ref:`Makefile Generators`
and the :generator:`Ninja` generator will run ``cppcheck`` along with the
compiler and report any problems.  If the command-line specifies the
exit code options to ``cppcheck`` then the build  will fail if the
tool returns non-zero.

This property is initialized by the value of the
:variable:`CMAKE_<LANG>_CPPCHECK` variable if it is set when a target is
created.

.. versionadded:: 3.27

  This property supports
  :manual:`generator expressions <cmake-generator-expressions(7)>`.

.. versionadded:: 3.27

  :prop_sf:`SKIP_LINTING` can be set on individual source files to exclude
  them from the linting tools defined by :prop_tgt:`<LANG>_CPPLINT`,
  :prop_tgt:`<LANG>_CLANG_TIDY`, ``<LANG>_CPPCHECK``, and
  :prop_tgt:`<LANG>_INCLUDE_WHAT_YOU_USE`.  When :prop_sf:`SKIP_LINTING` is
  set to true on a source file, those tools will not be run on that specific
  file.


code:
<LANG>_CPPLINT
--------------

.. versionadded:: 3.8

This property is supported only when ``<LANG>`` is ``C`` or ``CXX``.

Specify a :ref:`semicolon-separated list <CMake Language Lists>` containing a command line
for the ``cpplint`` style checker.  The :ref:`Makefile Generators` and the
:generator:`Ninja` generator will run ``cpplint`` along with the compiler
and report any problems.

This property is initialized by the value of the
:variable:`CMAKE_<LANG>_CPPLINT` variable if it is set when a target is
created.

.. versionadded:: 3.27

  This property supports
  :manual:`generator expressions <cmake-generator-expressions(7)>`.

.. versionadded:: 3.27

  :prop_sf:`SKIP_LINTING` can be set on individual source files to exclude
  them from the linting tools defined by ``<LANG>_CPPLINT``,
  :prop_tgt:`<LANG>_CLANG_TIDY`, :prop_tgt:`<LANG>_CPPCHECK`, and
  :prop_tgt:`<LANG>_INCLUDE_WHAT_YOU_USE`.  When :prop_sf:`SKIP_LINTING` is
  set to true on a source file, those tools will not be run on that specific
  file.


code:
<LANG>_EXTENSIONS
-----------------

The variations are:

* :prop_tgt:`C_EXTENSIONS`
* :prop_tgt:`CXX_EXTENSIONS`
* :prop_tgt:`CUDA_EXTENSIONS`
* :prop_tgt:`HIP_EXTENSIONS`
* :prop_tgt:`OBJC_EXTENSIONS`
* :prop_tgt:`OBJCXX_EXTENSIONS`

These properties specify whether compiler-specific extensions are requested.

These properties are initialized by the value of the
:variable:`CMAKE_<LANG>_EXTENSIONS` variable if it is set when a target is
created and otherwise by the value of
:variable:`CMAKE_<LANG>_EXTENSIONS_DEFAULT` (see :policy:`CMP0128`).

For supported CMake versions see the respective pages.
To control language standard versions see :prop_tgt:`<LANG>_STANDARD`.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
<LANG>_INCLUDE_WHAT_YOU_USE
---------------------------

.. versionadded:: 3.3

This property is implemented only when ``<LANG>`` is ``C`` or ``CXX``.

Specify a :ref:`semicolon-separated list <CMake Language Lists>` containing a command
line for the ``include-what-you-use`` tool.  The :ref:`Makefile Generators`
and the :generator:`Ninja` generator will run this tool along with the
compiler and report a warning if the tool reports any problems.

This property is initialized by the value of
the :variable:`CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE` variable if it is set
when a target is created.

.. versionadded:: 3.27

  This property supports
  :manual:`generator expressions <cmake-generator-expressions(7)>`.

.. versionadded:: 3.27

  :prop_sf:`SKIP_LINTING` can be set on individual source files to exclude
  them from the linting tools defined by :prop_tgt:`<LANG>_CPPLINT`,
  :prop_tgt:`<LANG>_CLANG_TIDY`, :prop_tgt:`<LANG>_CPPCHECK`, and
  ``<LANG>_INCLUDE_WHAT_YOU_USE``.  When :prop_sf:`SKIP_LINTING` is
  set to true on a source file, those tools will not be run on that specific
  file.


code:
<LANG>_LINKER_LAUNCHER
----------------------

.. versionadded:: 3.21

This property is implemented only when ``<LANG>`` is ``C``, ``CXX``,
``OBJC``, or ``OBJCXX``

Specify a :ref:`semicolon-separated list <CMake Language Lists>` containing a
command line for a linker launching tool. The :ref:`Makefile Generators` and the
:generator:`Ninja` generator will run this tool and pass the linker and its
arguments to the tool. This is useful for tools such as static analyzers.

This property is initialized by the value of the
:variable:`CMAKE_<LANG>_LINKER_LAUNCHER` variable if it is set when a target is
created.

.. versionadded:: 3.27

  The property value may use
  :manual:`generator expressions <cmake-generator-expressions(7)>`.


code:
<LANG>_STANDARD
---------------

The variations are:

* :prop_tgt:`C_STANDARD`
* :prop_tgt:`CXX_STANDARD`
* :prop_tgt:`CUDA_STANDARD`
* :prop_tgt:`HIP_STANDARD`
* :prop_tgt:`OBJC_STANDARD`
* :prop_tgt:`OBJCXX_STANDARD`

These properties specify language standard versions which are requested. When a
newer standard is specified than is supported by the compiler, then it will
fallback to the latest supported standard. This "decay" behavior may be
controlled with the :prop_tgt:`<LANG>_STANDARD_REQUIRED` target property.

Note that the actual language standard used may be higher than that specified
by ``<LANG>_STANDARD``, regardless of the value of
:prop_tgt:`<LANG>_STANDARD_REQUIRED`.  In particular,
:ref:`transitive usage requirements <Target Usage Requirements>` or the use of
:manual:`compile features <cmake-compile-features(7)>` can raise the required
language standard above what ``<LANG>_STANDARD`` specifies.

These properties are initialized by the value of the
:variable:`CMAKE_<LANG>_STANDARD` variable if it is set when a target is
created.

For supported values and CMake versions see the respective pages.
To control compiler-specific extensions see :prop_tgt:`<LANG>_EXTENSIONS`.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
<LANG>_STANDARD_REQUIRED
------------------------

The variations are:

* :prop_tgt:`C_STANDARD_REQUIRED`
* :prop_tgt:`CXX_STANDARD_REQUIRED`
* :prop_tgt:`CUDA_STANDARD_REQUIRED`
* :prop_tgt:`HIP_STANDARD_REQUIRED`
* :prop_tgt:`OBJC_STANDARD_REQUIRED`
* :prop_tgt:`OBJCXX_STANDARD_REQUIRED`

These properties specify whether the value of :prop_tgt:`<LANG>_STANDARD` is a
requirement.  When false or unset, the :prop_tgt:`<LANG>_STANDARD` target
property is treated as optional and may "decay" to a previous standard if the
requested standard is not available.  When ``<LANG>_STANDARD_REQUIRED`` is set
to true, :prop_tgt:`<LANG>_STANDARD` becomes a hard requirement and a fatal
error will be issued if that requirement cannot be met.

Note that the actual language standard used may be higher than that specified
by :prop_tgt:`<LANG>_STANDARD`, regardless of the value of
``<LANG>_STANDARD_REQUIRED``.  In particular,
:ref:`transitive usage requirements <Target Usage Requirements>` or the use of
:manual:`compile features <cmake-compile-features(7)>` can raise the required
language standard above what :prop_tgt:`<LANG>_STANDARD` specifies.

These properties are initialized by the value of the
:variable:`CMAKE_<LANG>_STANDARD_REQUIRED` variable if it is set when a target
is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
<LANG>_VISIBILITY_PRESET
------------------------

Value for symbol visibility compile flags

The ``<LANG>_VISIBILITY_PRESET`` property determines the value passed in a
visibility related compile option, such as ``-fvisibility=`` for ``<LANG>``.
This property affects compilation in sources of all types of targets
(subject to policy :policy:`CMP0063`).

This property is initialized by the value of the
:variable:`CMAKE_<LANG>_VISIBILITY_PRESET` variable if it is set when a
target is created.


code:
LIBRARY_OUTPUT_DIRECTORY
------------------------

.. |XXX| replace:: :ref:`LIBRARY <Library Output Artifacts>`
.. |xxx| replace:: library
.. |CMAKE_XXX_OUTPUT_DIRECTORY| replace:: :variable:`CMAKE_LIBRARY_OUTPUT_DIRECTORY`
.. include:: XXX_OUTPUT_DIRECTORY.txt

See also the :prop_tgt:`LIBRARY_OUTPUT_DIRECTORY_<CONFIG>` target property.


code:
LIBRARY_OUTPUT_DIRECTORY_<CONFIG>
---------------------------------

Per-configuration output directory for
:ref:`LIBRARY <Library Output Artifacts>` target files.

This is a per-configuration version of the
:prop_tgt:`LIBRARY_OUTPUT_DIRECTORY` target property, but
multi-configuration generators (:ref:`Visual Studio Generators`,
:generator:`Xcode`) do NOT append a
per-configuration subdirectory to the specified directory.  This
property is initialized by the value of the
:variable:`CMAKE_LIBRARY_OUTPUT_DIRECTORY_<CONFIG>` variable if
it is set when a target is created.

Contents of ``LIBRARY_OUTPUT_DIRECTORY_<CONFIG>`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.


code:
LIBRARY_OUTPUT_NAME
-------------------

.. |XXX| replace:: :ref:`LIBRARY <Library Output Artifacts>`
.. |xxx| replace:: library
.. include:: XXX_OUTPUT_NAME.txt

See also the :prop_tgt:`LIBRARY_OUTPUT_NAME_<CONFIG>` target property.


code:
LIBRARY_OUTPUT_NAME_<CONFIG>
----------------------------

Per-configuration output name for
:ref:`LIBRARY <Library Output Artifacts>` target files.

This is the configuration-specific version of the
:prop_tgt:`LIBRARY_OUTPUT_NAME` target property.


code:
LINKER_LANGUAGE
---------------

Specifies language whose compiler will invoke the linker.

For executables, shared libraries, and modules, this sets the language
whose compiler is used to link the target (such as "C" or "CXX").  A
typical value for an executable is the language of the source file
providing the program entry point (main).  If not set, the language
with the highest linker preference value is the default.  Details of
the linker preferences are considered internal, but some limited
discussion can be found under the internal
:variable:`CMAKE_<LANG>_LINKER_PREFERENCE` variables.

If this property is not set by the user, it will be calculated at
generate-time by CMake.


code:
LINKER_TYPE
-----------

.. versionadded:: 3.29

Specify which linker will be used for the link step. The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.

.. code-block:: cmake

  add_library(lib1 SHARED ...)
  set_property(TARGET lib1 PROPERTY LINKER_TYPE LLD)

This specifies that ``lib1`` should use linker type ``LLD`` for the link step.
The implementation details will be provided by the variable
:variable:`CMAKE_<LANG>_USING_LINKER_<TYPE>` with ``<TYPE>`` having the value
``LLD``.

This property is not supported on :generator:`Green Hills MULTI` and
:generator:`Visual Studio 9 2008` generators.

.. note::
  It is assumed that the linker specified is fully compatible with the standard
  one. CMake will not do any options translation.

.. include:: ../variable/LINKER_PREDEFINED_TYPES.txt


code:
LINK_DEPENDS
------------

Additional files on which a target binary depends for linking.

Specifies a semicolon-separated list of full-paths to files on which
the link rule for this target depends.  The target binary will be
linked if any of the named files is newer than it.

This property is supported only by :generator:`Ninja` and
:ref:`Makefile Generators`.  It is
intended to specify dependencies on "linker scripts" for custom Makefile link
rules.

Contents of ``LINK_DEPENDS`` may use "generator expressions" with
the syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)`
manual for available expressions.  See the :manual:`cmake-buildsystem(7)`
manual for more on defining buildsystem properties.


code:
LINK_DEPENDS_NO_SHARED
----------------------

Do not depend on linked shared library files.

Set this property to true to tell CMake generators not to add
file-level dependencies on the shared library files linked by this
target.  Modification to the shared libraries will not be sufficient
to re-link this target.  Logical target-level dependencies will not be
affected so the linked shared libraries will still be brought up to
date before this target is built.

This property is initialized by the value of the
:variable:`CMAKE_LINK_DEPENDS_NO_SHARED` variable if it is set when a
target is created.


code:
LINK_DIRECTORIES
----------------

.. versionadded:: 3.13

List of directories to use for the link step of shared library, module
and executable targets.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>` of directories
specified so far for its target.  Use the :command:`target_link_directories`
command to append more search directories.

This property is initialized by the :prop_dir:`LINK_DIRECTORIES` directory
property when a target is created, and is used by the generators to set
the search directories for the linker.

Contents of ``LINK_DIRECTORIES`` may use "generator expressions" with the
syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)` manual
for available expressions.  See the :manual:`cmake-buildsystem(7)` manual
for more on defining buildsystem properties.


code:
LINK_FLAGS
----------

Additional flags to use when linking this target if it is a shared library,
module library, or an executable. Static libraries need to use
:prop_tgt:`STATIC_LIBRARY_OPTIONS` or :prop_tgt:`STATIC_LIBRARY_FLAGS`
properties.

The ``LINK_FLAGS`` property, managed as a string, can be used to add extra
flags to the link step of a target.  :prop_tgt:`LINK_FLAGS_<CONFIG>` will add
to the configuration ``<CONFIG>``, for example, ``DEBUG``, ``RELEASE``,
``MINSIZEREL``, ``RELWITHDEBINFO``, ...

.. note::

  This property has been superseded by :prop_tgt:`LINK_OPTIONS` property.


code:
LINK_FLAGS_<CONFIG>
-------------------

Per-configuration linker flags for a ``SHARED`` library, ``MODULE`` or
``EXECUTABLE`` target.

This is the configuration-specific version of :prop_tgt:`LINK_FLAGS`.

.. note::

  This property has been superseded by :prop_tgt:`LINK_OPTIONS` property.


code:
LINK_INTERFACE_LIBRARIES
------------------------

List public interface libraries for a shared library or executable.

By default linking to a shared library target transitively links to
targets with which the library itself was linked.  For an executable
with exports (see the :prop_tgt:`ENABLE_EXPORTS` target property) no
default transitive link dependencies are used.  This property replaces the default
transitive link dependencies with an explicit list.  When the target
is linked into another target using the :command:`target_link_libraries`
command, the libraries listed (and recursively
their link interface libraries) will be provided to the other target
also.  If the list is empty then no transitive link dependencies will
be incorporated when this target is linked into another target even if
the default set is non-empty.  This property is initialized by the
value of the :variable:`CMAKE_LINK_INTERFACE_LIBRARIES` variable if it is
set when a target is created.  This property is ignored for ``STATIC``
libraries.

This property is overridden by the :prop_tgt:`INTERFACE_LINK_LIBRARIES`
property if policy :policy:`CMP0022` is ``NEW``.

This property is deprecated.  Use :prop_tgt:`INTERFACE_LINK_LIBRARIES`
instead.

Creating Relocatable Packages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. |INTERFACE_PROPERTY_LINK| replace:: ``LINK_INTERFACE_LIBRARIES``
.. include:: /include/INTERFACE_LINK_LIBRARIES_WARNING.txt


code:
LINK_INTERFACE_LIBRARIES_<CONFIG>
---------------------------------

Per-configuration list of public interface libraries for a target.

This is the configuration-specific version of
:prop_tgt:`LINK_INTERFACE_LIBRARIES`.  If set, this property completely
overrides the generic property for the named configuration.

This property is overridden by the :prop_tgt:`INTERFACE_LINK_LIBRARIES`
property if policy :policy:`CMP0022` is ``NEW``.

This property is deprecated.  Use :prop_tgt:`INTERFACE_LINK_LIBRARIES`
instead.

Creating Relocatable Packages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. |INTERFACE_PROPERTY_LINK| replace:: ``LINK_INTERFACE_LIBRARIES_<CONFIG>``
.. include:: /include/INTERFACE_LINK_LIBRARIES_WARNING.txt


code:
LINK_INTERFACE_MULTIPLICITY
---------------------------

Repetition count for ``STATIC`` libraries with cyclic dependencies.

When linking to a ``STATIC`` library target with cyclic dependencies the
linker may need to scan more than once through the archives in the
strongly connected component of the dependency graph.  CMake by
default constructs the link line so that the linker will scan through
the component at least twice.  This property specifies the minimum
number of scans if it is larger than the default.  CMake uses the
largest value specified by any target in a component.


code:
LINK_INTERFACE_MULTIPLICITY_<CONFIG>
------------------------------------

Per-configuration repetition count for cycles of ``STATIC`` libraries.

This is the configuration-specific version of
:prop_tgt:`LINK_INTERFACE_MULTIPLICITY`.  If set, this property completely
overrides the generic property for the named configuration.


code:
LINK_LIBRARIES
--------------

List of direct link dependencies.

This property specifies the list of libraries or targets which will be
used for linking.  In addition to accepting values from the
:command:`target_link_libraries` command, values may be set directly on
any target using the :command:`set_property` command.

The value of this property is used by the generators to construct the
link rule for the target.  The direct link dependencies are linked first,
followed by indirect dependencies from the transitive closure of the
direct dependencies' :prop_tgt:`INTERFACE_LINK_LIBRARIES` properties.
See policy :policy:`CMP0022`.

Contents of ``LINK_LIBRARIES`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>` with the
syntax ``$<...>``.  Policy :policy:`CMP0131` affects the behavior of the
:genex:`LINK_ONLY` generator expression for this property.

See the :manual:`cmake-buildsystem(7)` manual for more on defining
buildsystem properties.

.. include:: LINK_LIBRARIES_INDIRECTION.txt

In advanced use cases, the list of direct link dependencies specified
by this property may be updated by usage requirements from dependencies.
See the :prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT` and
:prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE` target properties.


code:
.. note::
  A call to :command:`target_link_libraries(<target> ...)` may update this
  property on ``<target>``.  If ``<target>`` was not created in the same
  directory as the call then :command:`target_link_libraries` will wrap each
  entry with the form ``::@(directory-id);...;::@``, where the ``::@`` is
  literal and the ``(directory-id)`` is unspecified.
  This tells the generators that the named libraries must be looked up in
  the scope of the caller rather than in the scope in which the
  ``<target>`` was created.  Valid directory ids are stripped on export
  by the :command:`install(EXPORT)` and :command:`export` commands.


code:
LINK_LIBRARIES_ONLY_TARGETS
---------------------------

.. versionadded:: 3.23

Enforce that link items that can be target names are actually existing targets.

Set this property to a true value to enable additional checks on the contents
of the :prop_tgt:`LINK_LIBRARIES` and :prop_tgt:`INTERFACE_LINK_LIBRARIES`
target properties, typically populated by :command:`target_link_libraries`.
Checks are also applied to libraries added to a target through the
:prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT` properties of its dependencies.
CMake will verify that link items that might be target names actually name
existing targets.  An item is considered a possible target name if:

* it does not contain a ``/`` or ``\``, and
* it does not start in ``-``, and
* (for historical reasons) it does not start in ``$`` or `````.

This property is initialized by the value of the
:variable:`CMAKE_LINK_LIBRARIES_ONLY_TARGETS` variable when a non-imported
target is created.  The property may be explicitly enabled on an imported
target to check its link interface.

In the following example, CMake will halt with an error at configure time
because ``miLib`` is not a target:

.. code-block:: cmake

  set(CMAKE_LINK_LIBRARIES_ONLY_TARGETS ON)
  add_library(myLib STATIC myLib.c)
  add_executable(myExe myExe.c)
  target_link_libraries(myExe PRIVATE miLib) # typo for myLib

In order to link toolchain-provided libraries by name while still
enforcing ``LINK_LIBRARIES_ONLY_TARGETS``, use an
:ref:`imported <Imported Targets>`
:ref:`Interface Library <Interface Libraries>` with the
:prop_tgt:`IMPORTED_LIBNAME` target property:

.. code-block:: cmake

  add_library(toolchain::m INTERFACE IMPORTED)
  set_property(TARGET toolchain::m PROPERTY IMPORTED_LIBNAME "m")
  target_link_libraries(myExe PRIVATE toolchain::m)

See also policy :policy:`CMP0028`.

.. note::

  If :prop_tgt:`INTERFACE_LINK_LIBRARIES` contains generator expressions,
  its actual list of link items may depend on the type and properties of
  the consuming target.  In such cases CMake may not always detect names
  of missing targets that only appear for specific consumers.
  A future version of CMake with improved heuristics may start triggering
  errors on projects accepted by previous versions of CMake.


code:
LINK_LIBRARY_OVERRIDE
---------------------

.. versionadded:: 3.24

Override the library features associated with libraries from
:genex:`LINK_LIBRARY` generator expressions.  This can be used to resolve
incompatible library features that result from specifying different features
for the same library in different :genex:`LINK_LIBRARY` generator expressions.

This property supports overriding multiple libraries and features. It expects
a :ref:`semicolon-separated list <CMake Language Lists>`, where each list item
has the following form::

  feature[,link-item]*

For each comma-separated ``link-item``, any existing library feature associated
with it will be ignored for the target this property is set on.  The item
will instead be associated with the specified ``feature``.  Each ``link-item``
can be anything that would be accepted as part of a ``library-list`` in a
:genex:`LINK_LIBRARY` generator expression.

.. code-block:: cmake

  add_library(lib1 ...)
  add_library(lib2 ...)
  add_library(lib3 ...)

  target_link_libraries(lib1 PUBLIC "$<LINK_LIBRARY:feature1,external>")
  target_link_libraries(lib2 PUBLIC "$<LINK_LIBRARY:feature2,lib1>")
  target_link_libraries(lib3 PRIVATE lib1 lib2)

  # lib1 is associated with both feature2 and no feature. Without any override,
  # this would result in a fatal error at generation time for lib3.
  # Define an override to resolve the incompatible feature associations.
  set_property(TARGET lib3 PROPERTY LINK_LIBRARY_OVERRIDE "feature2,lib1,external")

  # lib1 and external will now be associated with feature2 instead when linking lib3

It is also possible to override any feature with the pre-defined ``DEFAULT``
library feature.  This effectively discards any feature for that link item,
for that target only (``lib3`` in this example):

.. code-block:: cmake

  # When linking lib3, discard any library feature for lib1, and use feature2 for external
  set_property(TARGET lib3 PROPERTY LINK_LIBRARY_OVERRIDE
    "DEFAULT,lib1"
    "feature2,external"
  )

The above example also demonstrates how to specify different feature overrides
for different link items.  See the :prop_tgt:`LINK_LIBRARY_OVERRIDE_<LIBRARY>`
target property for an alternative way of overriding library features for
individual libraries, which may be simpler in some cases.  If both properties
are defined and specify an override for the same link item,
:prop_tgt:`LINK_LIBRARY_OVERRIDE_<LIBRARY>` takes precedence over
``LINK_LIBRARY_OVERRIDE``.

Contents of ``LINK_LIBRARY_OVERRIDE`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.

For more information about library features, see the
:variable:`CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>` and
:variable:`CMAKE_LINK_LIBRARY_USING_<FEATURE>` variables.


code:
LINK_LIBRARY_OVERRIDE_<LIBRARY>
-------------------------------

.. versionadded:: 3.24

Override the library feature associated with ``<LIBRARY>`` from
:genex:`LINK_LIBRARY` generator expressions.  This can be used to resolve
incompatible library features that result from specifying different features
for ``<LIBRARY>`` in different :genex:`LINK_LIBRARY` generator expressions.

When set on a target, this property holds a single library feature name, which
will be applied to ``<LIBRARY>`` when linking that target.

.. code-block:: cmake

  add_library(lib1 ...)
  add_library(lib2 ...)
  add_library(lib3 ...)

  target_link_libraries(lib1 PUBLIC "$<LINK_LIBRARY:feature1,external>")
  target_link_libraries(lib2 PUBLIC "$<LINK_LIBRARY:feature2,lib1>")
  target_link_libraries(lib3 PRIVATE lib1 lib2)

  # lib1 is associated with both feature2 and no feature. Without any override,
  # this would result in a fatal error at generation time for lib3.
  # Define an override to resolve the incompatible feature associations.
  set_property(TARGET lib3 PROPERTY LINK_LIBRARY_OVERRIDE_lib1 feature2)

  # lib1 will now be associated with feature2 instead when linking lib3

It is also possible to override any feature with the pre-defined ``DEFAULT``
library feature.  This effectively discards any feature for that link item,
for that target only (``lib3`` in this example):

.. code-block:: cmake

  # When linking lib3, discard any library feature for lib1
  set_property(TARGET lib3 PROPERTY LINK_LIBRARY_OVERRIDE_lib1 DEFAULT)

See the :prop_tgt:`LINK_LIBRARY_OVERRIDE` target property for an alternative
way of overriding library features for multiple libraries at once.  If both
properties are defined and specify an override for the same link item,
``LINK_LIBRARY_OVERRIDE_<LIBRARY>`` takes precedence over
:prop_tgt:`LINK_LIBRARY_OVERRIDE`.

Contents of ``LINK_LIBRARY_OVERRIDE_<LIBRARY>`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.

For more information about library features, see the
:variable:`CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>` and
:variable:`CMAKE_LINK_LIBRARY_USING_<FEATURE>` variables.


code:
LINK_OPTIONS
------------

.. versionadded:: 3.13

List of options to use for the link step of shared library, module
and executable targets as well as the device link step. Targets that are static
libraries need to use the :prop_tgt:`STATIC_LIBRARY_OPTIONS` target property.

These options are used for both normal linking and device linking
(see policy :policy:`CMP0105`). To control link options for normal and device
link steps, :genex:`$<HOST_LINK>` and :genex:`$<DEVICE_LINK>` generator
expressions can be used.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>` of
options specified so far for its target.  Use the :command:`target_link_options`
command to append more options.

This property is initialized by the :prop_dir:`LINK_OPTIONS` directory
property when a target is created, and is used by the generators to set
the options for the compiler.

Contents of ``LINK_OPTIONS`` may use "generator expressions" with the
syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)` manual
for available expressions.  See the :manual:`cmake-buildsystem(7)` manual
for more on defining buildsystem properties.

.. note::

  This property must be used in preference to :prop_tgt:`LINK_FLAGS` property.

.. include:: ../command/DEVICE_LINK_OPTIONS.txt

.. include:: ../command/OPTIONS_SHELL.txt

.. include:: ../command/LINK_OPTIONS_LINKER.txt


code:
LINK_SEARCH_END_STATIC
----------------------

End a link line such that static system libraries are used.

Some linkers support switches such as ``-Bstatic`` and ``-Bdynamic`` to
determine whether to use static or shared libraries for ``-lXXX`` options.
CMake uses these options to set the link type for libraries whose full
paths are not known or (in some cases) are in implicit link
directories for the platform.  By default CMake adds an option at the
end of the library list (if necessary) to set the linker search type
back to its starting type.  This property switches the final linker
search type to ``-Bstatic`` regardless of how it started.

This property is initialized by the value of the variable
:variable:`CMAKE_LINK_SEARCH_END_STATIC` if it is set
when a target is created.

See also :prop_tgt:`LINK_SEARCH_START_STATIC`.


code:
LINK_SEARCH_START_STATIC
------------------------

Assume the linker looks for static libraries by default.

Some linkers support switches such as ``-Bstatic`` and ``-Bdynamic`` to
determine whether to use static or shared libraries for ``-lXXX`` options.
CMake uses these options to set the link type for libraries whose full
paths are not known or (in some cases) are in implicit link
directories for the platform.  By default the linker search type is
assumed to be ``-Bdynamic`` at the beginning of the library list.  This
property switches the assumption to ``-Bstatic``.  It is intended for use
when linking an executable statically (e.g. with the GNU ``-static``
option).

This property is initialized by the value of the variable
 :variable:`CMAKE_LINK_SEARCH_START_STATIC` if it is set
 when a target is created.

See also :prop_tgt:`LINK_SEARCH_END_STATIC`.


code:
LINK_WHAT_YOU_USE
-----------------

.. versionadded:: 3.7

This is a boolean option that, when set to ``TRUE``, will automatically run
contents of variable :variable:`CMAKE_LINK_WHAT_YOU_USE_CHECK` on the target
after it is linked. In addition, the linker flag specified by variable
:variable:`CMAKE_<LANG>_LINK_WHAT_YOU_USE_FLAG`  will be passed to the target
with the link command so that all libraries specified on the command line will
be linked into the target. This will result in the link producing a list of
libraries that provide no symbols used by this target but are being linked to
it.

.. note::

  For now, it is only supported for ``ELF`` platforms and is only applicable to
  executable and shared or module library targets. This property will be
  ignored for any other targets and configurations.

This property is initialized by the value of
the :variable:`CMAKE_LINK_WHAT_YOU_USE` variable if it is set
when a target is created.


code:
LOCATION
--------

Read-only location of a target on disk.

For an imported target, this read-only property returns the value of
the ``LOCATION_<CONFIG>`` property for an unspecified configuration
``<CONFIG>`` provided by the target.

For a non-imported target, this property is provided for compatibility
with CMake 2.4 and below.  It was meant to get the location of an
executable target's output file for use in :command:`add_custom_command`.  The
path may contain a build-system-specific portion that is replaced at
build time with the configuration getting built (such as
``$(ConfigurationName)`` in VS).  In CMake 2.6 and above
:command:`add_custom_command` automatically recognizes a target name in its
``COMMAND`` and ``DEPENDS`` options and computes the target location.  In
CMake 2.8.4 and above :command:`add_custom_command` recognizes
:manual:`generator expressions <cmake-generator-expressions(7)>`
to refer to target locations anywhere in the command.
Therefore this property is not needed for creating custom commands.

Do not set properties that affect the location of a target after
reading this property.  These include properties whose names match
``(RUNTIME|LIBRARY|ARCHIVE)_OUTPUT_(NAME|DIRECTORY)(_<CONFIG>)?``,
``(IMPLIB_)?(PREFIX|SUFFIX)``, or "LINKER_LANGUAGE".  Failure to follow
this rule is not diagnosed and leaves the location of the target
undefined.


code:
LOCATION_<CONFIG>
-----------------

Read-only property providing a target location on disk.

A read-only property that indicates where a target's main file is
located on disk for the configuration ``<CONFIG>``.  The property is
defined only for library and executable targets.  An imported target
may provide a set of configurations different from that of the
importing project.  By default CMake looks for an exact-match but
otherwise uses an arbitrary available configuration.  Use the
:prop_tgt:`MAP_IMPORTED_CONFIG_<CONFIG>` property to map imported
configurations explicitly.

Do not set properties that affect the location of a target after
reading this property.  These include properties whose names match
``(RUNTIME|LIBRARY|ARCHIVE)_OUTPUT_(NAME|DIRECTORY)(_<CONFIG>)?``,
``(IMPLIB_)?(PREFIX|SUFFIX)``, or  :prop_tgt:`LINKER_LANGUAGE`.
Failure to follow this rule is not diagnosed and leaves
the location of the target undefined.


code:
MACHO_COMPATIBILITY_VERSION
---------------------------

.. versionadded:: 3.17

What compatibility version number is this target for Mach-O binaries.

For shared libraries on Mach-O systems (e.g. macOS, iOS)
the ``MACHO_COMPATIBILITY_VERSION`` property corresponds to the
*compatibility version* and :prop_tgt:`MACHO_CURRENT_VERSION` corresponds to
the *current version*.  These are both embedded in the shared library binary
and can be checked with the ``otool -L <binary>`` command.

It should be noted that the :prop_tgt:`MACHO_CURRENT_VERSION` and
``MACHO_COMPATIBILITY_VERSION`` properties do not affect the file
names or version-related symlinks that CMake generates for the library.
The :prop_tgt:`VERSION` and :prop_tgt:`SOVERSION` target properties still
control the file and symlink names.  The ``install_name`` is also still
controlled by :prop_tgt:`SOVERSION`.

When :prop_tgt:`MACHO_CURRENT_VERSION` and ``MACHO_COMPATIBILITY_VERSION``
are not given, :prop_tgt:`VERSION` and :prop_tgt:`SOVERSION` are used for
the version details to be embedded in the binaries respectively.
The :prop_tgt:`MACHO_CURRENT_VERSION` and ``MACHO_COMPATIBILITY_VERSION``
properties only need to be given if the project needs to decouple the file
and symlink naming from the version details embedded in the binaries
(e.g. to match libtool conventions).


code:
MACHO_CURRENT_VERSION
---------------------

.. versionadded:: 3.17

What current version number is this target for Mach-O binaries.

For shared libraries on Mach-O systems (e.g. macOS, iOS)
the :prop_tgt:`MACHO_COMPATIBILITY_VERSION` property corresponds to the
*compatibility version* and ``MACHO_CURRENT_VERSION`` corresponds to the
*current version*.  These are both embedded in the shared library binary
and can be checked with the ``otool -L <binary>`` command.

It should be noted that the ``MACHO_CURRENT_VERSION`` and
:prop_tgt:`MACHO_COMPATIBILITY_VERSION` properties do not affect the file
names or version-related symlinks that CMake generates for the library.
The :prop_tgt:`VERSION` and :prop_tgt:`SOVERSION` target properties still
control the file and symlink names.  The ``install_name`` is also still
controlled by :prop_tgt:`SOVERSION`.

When ``MACHO_CURRENT_VERSION`` and :prop_tgt:`MACHO_COMPATIBILITY_VERSION`
are not given, :prop_tgt:`VERSION` and :prop_tgt:`SOVERSION` are used for
the version details to be embedded in the binaries respectively.
The ``MACHO_CURRENT_VERSION`` and :prop_tgt:`MACHO_COMPATIBILITY_VERSION`
properties only need to be given if the project needs to decouple the file
and symlink naming from the version details embedded in the binaries
(e.g. to match libtool conventions).


code:
MACOSX_BUNDLE
-------------

Build an executable as an Application Bundle on macOS or iOS.

When this property is set to ``TRUE`` the executable when built on macOS
or iOS will be created as an application bundle.  This makes it
a GUI executable that can be launched from the Finder.  See the
:prop_tgt:`MACOSX_BUNDLE_INFO_PLIST` target property for information about
creation of the ``Info.plist`` file for the application bundle.
This property is initialized by the value of the variable
:variable:`CMAKE_MACOSX_BUNDLE` if it is set when a target is created.


code:
MACOSX_BUNDLE_INFO_PLIST
------------------------

Specify a custom ``Info.plist`` template for a macOS and iOS Application Bundle.

An executable target with :prop_tgt:`MACOSX_BUNDLE` enabled will be built as an
application bundle on macOS.  By default its ``Info.plist`` file is created
by configuring a template called ``MacOSXBundleInfo.plist.in`` located in the
:variable:`CMAKE_MODULE_PATH`.  This property specifies an alternative template
file name which may be a full path.

The following target properties may be set to specify content to be
configured into the file:

``MACOSX_BUNDLE_BUNDLE_NAME``
  Sets ``CFBundleName``.
``MACOSX_BUNDLE_BUNDLE_VERSION``
  Sets ``CFBundleVersion``.
``MACOSX_BUNDLE_COPYRIGHT``
  Sets ``NSHumanReadableCopyright``.
``MACOSX_BUNDLE_GUI_IDENTIFIER``
  Sets ``CFBundleIdentifier``.
``MACOSX_BUNDLE_ICON_FILE``
  Sets ``CFBundleIconFile``.
``MACOSX_BUNDLE_INFO_STRING``
  Sets ``CFBundleGetInfoString``.
``MACOSX_BUNDLE_LONG_VERSION_STRING``
  Sets ``CFBundleLongVersionString``.
``MACOSX_BUNDLE_SHORT_VERSION_STRING``
  Sets ``CFBundleShortVersionString``.

CMake variables of the same name may be set to affect all targets in a
directory that do not have each specific property set.  If a custom
``Info.plist`` is specified by this property it may of course hard-code
all the settings instead of using the target properties.


code:
MACOSX_FRAMEWORK_INFO_PLIST
---------------------------

Specify a custom ``Info.plist`` template for a macOS and iOS Framework.

A library target with :prop_tgt:`FRAMEWORK` enabled will be built as a
framework on macOS.  By default its ``Info.plist`` file is created by
configuring a template called ``MacOSXFrameworkInfo.plist.in`` located in the
:variable:`CMAKE_MODULE_PATH`.  This property specifies an alternative template
file name which may be a full path.

The following target properties may be set to specify content to be
configured into the file:

``MACOSX_FRAMEWORK_BUNDLE_VERSION``
  Sets ``CFBundleVersion``.
``MACOSX_FRAMEWORK_ICON_FILE``
  Sets ``CFBundleIconFile``.
``MACOSX_FRAMEWORK_IDENTIFIER``
  Sets ``CFBundleIdentifier``.
``MACOSX_FRAMEWORK_SHORT_VERSION_STRING``
  Sets ``CFBundleShortVersionString``.

CMake variables of the same name may be set to affect all targets in a
directory that do not have each specific property set.  If a custom
``Info.plist`` is specified by this property it may of course hard-code
all the settings instead of using the target properties.


code:
MACOSX_RPATH
------------

Whether this target on macOS or iOS is located at runtime using rpaths.

When this property is set to ``TRUE``, the directory portion of
the ``install_name`` field of this shared library will be ``@rpath``
unless overridden by :prop_tgt:`INSTALL_NAME_DIR`.  This indicates
the shared library is to be found at runtime using runtime
paths (rpaths).

This property is initialized by the value of the variable
:variable:`CMAKE_MACOSX_RPATH` if it is set when a target is
created.

Runtime paths will also be embedded in binaries using this target and
can be controlled by the :prop_tgt:`INSTALL_RPATH` target property on
the target linking to this target.

Policy :policy:`CMP0042` was introduced to change the default value of
``MACOSX_RPATH`` to ``TRUE``.  This is because use of ``@rpath`` is a
more flexible and powerful alternative to ``@executable_path`` and
``@loader_path``.


code:
.. note::

  On macOS, this property will be ignored for the linker import files (e.g.
  ``.tbd`` files, see :prop_tgt:`ENABLE_EXPORTS` property for details) when:

  * The :prop_tgt:`FRAMEWORK` is set, because the framework layout cannot be
    changed.
  * The :generator:`Xcode` generator is used, due to the limitations and
    constraints of the ``Xcode`` tool.

  In both cases, the linker import files will be generated |IDEM| as the shared
  library.


code:
MANUALLY_ADDED_DEPENDENCIES
---------------------------

.. versionadded:: 3.8

Get manually added dependencies to other top-level targets.

This read-only property can be used to query all dependencies that
were added for this target with the :command:`add_dependencies`
command.


code:
MAP_IMPORTED_CONFIG_<CONFIG>
----------------------------

Map from project configuration to
:ref:`imported target <IMPORTED targets>`'s configuration.

Set this to the list of configurations of an imported target that may
be used for the current project's ``<CONFIG>`` configuration.  Targets
imported from another project may not provide the same set of
configuration names available in the current project.  Setting this
property tells CMake what imported configurations are suitable for use
when building the ``<CONFIG>`` configuration.  The first configuration in
the list found to be provided by the imported target (i.e. via
:prop_tgt:`IMPORTED_LOCATION_<CONFIG>` for the mapped-to ``<CONFIG>``)
is selected.  As a special case, an empty list element refers to the
configuration-less imported target location
(i.e. :prop_tgt:`IMPORTED_LOCATION`).

If this property is set and no matching configurations are available,
then the imported target is considered to be not found.  This property
is ignored for non-imported targets.

This property is initialized by the value of the
:variable:`CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>` variable if it is set when a
target is created.

Example
^^^^^^^

For example creating imported C++ library ``foo``:

.. code-block:: cmake

  add_library(foo STATIC IMPORTED)

Use ``foo_debug`` path for ``Debug`` build type:

.. code-block:: cmake

  set_property(
    TARGET foo APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG
    )

  set_target_properties(foo PROPERTIES
    IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
    IMPORTED_LOCATION_DEBUG "${foo_debug}"
    )

Use ``foo_release`` path for ``Release`` build type:

.. code-block:: cmake

  set_property(
    TARGET foo APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE
    )

  set_target_properties(foo PROPERTIES
    IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
    IMPORTED_LOCATION_RELEASE "${foo_release}"
    )

Use ``Release`` version of library for ``MinSizeRel`` and ``RelWithDebInfo``
build types:

.. code-block:: cmake

  set_target_properties(foo PROPERTIES
    MAP_IMPORTED_CONFIG_MINSIZEREL Release
    MAP_IMPORTED_CONFIG_RELWITHDEBINFO Release
    )


code:
``Embedded``
  Compile with ``-Z7`` or equivalent flag(s) to produce object files
  with full symbolic debugging information.
``ProgramDatabase``
  Compile with ``-Zi`` or equivalent flag(s) to produce a program
  database that contains all the symbolic debugging information.
``EditAndContinue``
  Compile with ``-ZI`` or equivalent flag(s) to produce a program
  database that supports the Edit and Continue feature.

The value is ignored on compilers not targeting the MSVC ABI, but an
unsupported value will be rejected as an error when using a compiler
targeting the MSVC ABI.

The value may also be the empty string (``""``), in which case no debug
information format flag will be added explicitly by CMake.


code:
MSVC_DEBUG_INFORMATION_FORMAT
-----------------------------

.. versionadded:: 3.25

Select debug information format when targeting the MSVC ABI.

The allowed values are:

.. include:: MSVC_DEBUG_INFORMATION_FORMAT-VALUES.txt

Use :manual:`generator expressions <cmake-generator-expressions(7)>` to
support per-configuration specification.  For example, the code:

.. code-block:: cmake

  add_executable(foo foo.c)
  set_property(TARGET foo PROPERTY
    MSVC_DEBUG_INFORMATION_FORMAT "$<$<CONFIG:Debug,RelWithDebInfo>:ProgramDatabase>")

selects for the target ``foo`` the program database debug information format
for the Debug configuration.

This property is initialized from the value of the
:variable:`CMAKE_MSVC_DEBUG_INFORMATION_FORMAT` variable, if it is set.
If this property is not set, CMake selects a debug information format using
the default value ``$<$<CONFIG:Debug,RelWithDebInfo>:ProgramDatabase>``, if
supported by the compiler, and otherwise
``$<$<CONFIG:Debug,RelWithDebInfo>:Embedded>``.

.. note::

  This property has effect only when policy :policy:`CMP0141` is set to ``NEW``
  prior to the first :command:`project` or :command:`enable_language` command
  that enables a language using a compiler targeting the MSVC ABI.


code:
``MultiThreaded``
  Compile with ``-MT`` or equivalent flag(s) to use a multi-threaded
  statically-linked runtime library.
``MultiThreadedDLL``
  Compile with ``-MD`` or equivalent flag(s) to use a multi-threaded
  dynamically-linked runtime library.
``MultiThreadedDebug``
  Compile with ``-MTd`` or equivalent flag(s) to use a multi-threaded
  statically-linked runtime library.
``MultiThreadedDebugDLL``
  Compile with ``-MDd`` or equivalent flag(s) to use a multi-threaded
  dynamically-linked runtime library.

The value is ignored on compilers not targeting the MSVC ABI, but an
unsupported value will be rejected as an error when using a compiler
targeting the MSVC ABI.

The value may also be the empty string (``""``) in which case no runtime
library selection flag will be added explicitly by CMake.  Note that with
:ref:`Visual Studio Generators` the native build system may choose to
add its own default runtime library selection flag.


code:
MSVC_RUNTIME_LIBRARY
--------------------

.. versionadded:: 3.15

Select the MSVC runtime library for use by compilers targeting the MSVC ABI.

The allowed values are:

.. include:: MSVC_RUNTIME_LIBRARY-VALUES.txt

Use :manual:`generator expressions <cmake-generator-expressions(7)>` to
support per-configuration specification.  For example, the code:

.. code-block:: cmake

  add_executable(foo foo.c)
  set_property(TARGET foo PROPERTY
    MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

selects for the target ``foo`` a multi-threaded statically-linked runtime
library with or without debug information depending on the configuration.

The property is initialized from the value of the
:variable:`CMAKE_MSVC_RUNTIME_LIBRARY` variable, if it is set.
If the property is not set, then CMake uses the default value
``MultiThreaded$<$<CONFIG:Debug>:Debug>DLL`` to select a MSVC runtime library.

.. note::

  This property has effect only when policy :policy:`CMP0091` is set to ``NEW``
  prior to the first :command:`project` or :command:`enable_language` command
  that enables a language using a compiler targeting the MSVC ABI.


code:
NAME
----

Logical name for the target.

Read-only logical name for the target as used by CMake.


code:
NO_SONAME
---------

Whether to set ``soname`` when linking a shared library.

Enable this boolean property if a generated ``SHARED`` library
should not have ``soname`` set.  Default is to set ``soname`` on all
shared libraries as long as the platform supports it.
Generally, use this property only for leaf private libraries or
plugins.  If you use it on normal shared libraries which other targets
link against, on some platforms a linker will insert a full path to
the library (as specified at link time) into the dynamic section of
the dependent binary.  Therefore, once installed, dynamic loader may
eventually fail to locate the library for the binary.


code:
NO_SYSTEM_FROM_IMPORTED
-----------------------

Do not treat include directories from the interfaces of consumed
:ref:`imported targets` as system directories.

When the consumed target's :prop_tgt:`SYSTEM` property is set to true, the
contents of the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` target property are
treated as system includes or, on Apple platforms, when the target is a
framework, it will be treated as system.  By default, :prop_tgt:`SYSTEM` is
true for imported targets and false for other target types.  If the
``NO_SYSTEM_FROM_IMPORTED`` property is set to true on a *consuming* target,
compilation of sources in that consuming target will not treat the contents of
the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` of consumed imported targets as
system includes, even if that imported target's :prop_tgt:`SYSTEM` property
is false.

Directories listed in the :prop_tgt:`INTERFACE_SYSTEM_INCLUDE_DIRECTORIES`
property of consumed targets are not affected by ``NO_SYSTEM_FROM_IMPORTED``.
Those directories will always be treated as system include directories by
consumers.

This property is initialized by the value of the
:variable:`CMAKE_NO_SYSTEM_FROM_IMPORTED` variable if it is set when a target
is created.

See the :prop_tgt:`EXPORT_NO_SYSTEM` target property to set this behavior
on the target providing the include directories rather than the target
consuming them.


code:
OBJCXX_EXTENSIONS
-----------------

.. versionadded:: 3.16

Boolean specifying whether compiler specific extensions are requested.

This property specifies whether compiler specific extensions should be
used.  For some compilers, this results in adding a flag such
as ``-std=gnu++11`` instead of ``-std=c++11`` to the compile line.  This
property is ``ON`` by default. The basic ObjC++ standard level is
controlled by the :prop_tgt:`OBJCXX_STANDARD` target property.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.

If the property is not set, and the project has set the :prop_tgt:`CXX_EXTENSIONS`,
the value of :prop_tgt:`CXX_EXTENSIONS` is set for ``OBJCXX_EXTENSIONS``.

This property is initialized by the value of
the :variable:`CMAKE_OBJCXX_EXTENSIONS` variable if set when a target is
created and otherwise by the value of
:variable:`CMAKE_OBJCXX_EXTENSIONS_DEFAULT <CMAKE_<LANG>_EXTENSIONS_DEFAULT>`
(see :policy:`CMP0128`).


code:
OBJCXX_STANDARD
---------------

.. versionadded:: 3.16

The ObjC++ standard whose features are requested to build this target.

This property specifies the ObjC++ standard whose features are requested
to build this target.  For some compilers, this results in adding a
flag such as ``-std=gnu++11`` to the compile line.

Supported values are:

``98``
  Objective C++98

``11``
  Objective C++11

``14``
  Objective C++14

``17``
  Objective C++17

``20``
  Objective C++20

``23``
  .. versionadded:: 3.20

  Objective C++23

``26``
  .. versionadded:: 3.25

  Objective C++26. CMake 3.25 and later *recognize* ``26`` as a valid value,
  no version has support for any compiler.

If the value requested does not result in a compile flag being added for
the compiler in use, a previous standard flag will be added instead.  This
means that using:

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY OBJCXX_STANDARD 11)

with a compiler which does not support ``-std=gnu++11`` or an equivalent
flag will not result in an error or warning, but will instead add the
``-std=gnu++98`` flag if supported.  This "decay" behavior may be controlled
with the :prop_tgt:`OBJCXX_STANDARD_REQUIRED` target property.
Additionally, the :prop_tgt:`OBJCXX_EXTENSIONS` target property may be used to
control whether compiler-specific extensions are enabled on a per-target basis.

If the property is not set, and the project has set the :prop_tgt:`CXX_STANDARD`,
the value of :prop_tgt:`CXX_STANDARD` is set for ``OBJCXX_STANDARD``.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.

This property is initialized by the value of
the :variable:`CMAKE_OBJCXX_STANDARD` variable if it is set when a target
is created.


code:
OBJCXX_STANDARD_REQUIRED
------------------------

.. versionadded:: 3.16

Boolean describing whether the value of :prop_tgt:`OBJCXX_STANDARD` is a requirement.

If this property is set to ``ON``, then the value of the
:prop_tgt:`OBJCXX_STANDARD` target property is treated as a requirement.  If this
property is ``OFF`` or unset, the :prop_tgt:`OBJCXX_STANDARD` target property is
treated as optional and may "decay" to a previous standard if the requested is
not available.

If the property is not set, and the project has set the :prop_tgt:`CXX_STANDARD_REQUIRED`,
the value of :prop_tgt:`CXX_STANDARD_REQUIRED` is set for ``OBJCXX_STANDARD_REQUIRED``.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.

This property is initialized by the value of
the :variable:`CMAKE_OBJCXX_STANDARD_REQUIRED` variable if it is set when a
target is created.


code:
OBJC_EXTENSIONS
---------------

.. versionadded:: 3.16

Boolean specifying whether compiler specific extensions are requested.

This property specifies whether compiler specific extensions should be
used.  For some compilers, this results in adding a flag such
as ``-std=gnu11`` instead of ``-std=c11`` to the compile line.  This
property is ``ON`` by default. The basic OBJC standard level is
controlled by the :prop_tgt:`OBJC_STANDARD` target property.

If the property is not set, and the project has set the :prop_tgt:`C_EXTENSIONS`,
the value of :prop_tgt:`C_EXTENSIONS` is set for ``OBJC_EXTENSIONS``.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.

This property is initialized by the value of
the :variable:`CMAKE_OBJC_EXTENSIONS` variable if set when a target is created
and otherwise by the value of
:variable:`CMAKE_OBJC_EXTENSIONS_DEFAULT <CMAKE_<LANG>_EXTENSIONS_DEFAULT>`
(see :policy:`CMP0128`).


code:
OBJC_STANDARD
-------------

.. versionadded:: 3.16

The OBJC standard whose features are requested to build this target.

This property specifies the OBJC standard whose features are requested
to build this target.  For some compilers, this results in adding a
flag such as ``-std=gnu11`` to the compile line.

Supported values are:

``90``
  Objective C89/C90

``99``
  Objective C99

``11``
  Objective C11

If the value requested does not result in a compile flag being added for
the compiler in use, a previous standard flag will be added instead.  This
means that using:

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY OBJC_STANDARD 11)

with a compiler which does not support ``-std=gnu11`` or an equivalent
flag will not result in an error or warning, but will instead add the
``-std=gnu99`` or ``-std=gnu90`` flag if supported.  This "decay" behavior may
be controlled with the :prop_tgt:`OBJC_STANDARD_REQUIRED` target property.
Additionally, the :prop_tgt:`OBJC_EXTENSIONS` target property may be used to
control whether compiler-specific extensions are enabled on a per-target basis.

If the property is not set, and the project has set the :prop_tgt:`C_STANDARD`,
the value of :prop_tgt:`C_STANDARD` is set for ``OBJC_STANDARD``.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.

This property is initialized by the value of
the :variable:`CMAKE_OBJC_STANDARD` variable if it is set when a target
is created.


code:
OBJC_STANDARD_REQUIRED
----------------------

.. versionadded:: 3.16

Boolean describing whether the value of :prop_tgt:`OBJC_STANDARD` is a requirement.

If this property is set to ``ON``, then the value of the
:prop_tgt:`OBJC_STANDARD` target property is treated as a requirement.  If this
property is ``OFF`` or unset, the :prop_tgt:`OBJC_STANDARD` target property is
treated as optional and may "decay" to a previous standard if the requested is
not available.

If the property is not set, and the project has set the :prop_tgt:`C_STANDARD_REQUIRED`,
the value of :prop_tgt:`C_STANDARD_REQUIRED` is set for ``OBJC_STANDARD_REQUIRED``.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.

This property is initialized by the value of
the :variable:`CMAKE_OBJC_STANDARD_REQUIRED` variable if it is set when a
target is created.


code:
OPTIMIZE_DEPENDENCIES
---------------------

.. versionadded:: 3.19

Activates dependency optimization of static and object libraries.

When this property is set to true, some dependencies for a static or object
library may be removed at generation time if they are not necessary to build
the library, since static and object libraries don't actually link against
anything.

If a static or object library has dependency optimization enabled, it first
discards all dependencies. Then, it looks through all of the direct and
indirect dependencies that it initially had, and adds them back if they meet
any of the following criteria:

* The dependency was added to the library by :command:`add_dependencies`.
* The dependency was added to the library through a source file in the library
  generated by a custom command that uses the dependency.
* The dependency has any ``PRE_BUILD``, ``PRE_LINK``, or ``POST_BUILD`` custom
  commands associated with it.
* The dependency contains any source files that were generated by a custom
  command.
* The dependency contains any languages which produce side effects that are
  relevant to the library. Currently, all languages except C, C++, Objective-C,
  Objective-C++, assembly, and CUDA are assumed to produce side effects.
  However, side effects from one language are assumed not to be relevant to
  another (for example, a Fortran library is assumed to not have any side
  effects that are relevant for a Swift library.)

As an example, assume you have a static Fortran library which depends on a
static C library, which in turn depends on a static Fortran library. The
top-level Fortran library has optimization enabled, but the middle C library
does not. If you build the top Fortran library, the bottom Fortran library will
also build, but not the middle C library, since the C library does not have any
side effects that are relevant for the Fortran library. However, if you build
the middle C library, the bottom Fortran library will also build, even though
it does not have any side effects that are relevant to the C library, since the
C library does not have optimization enabled.

This property is initialized by the value of the
:variable:`CMAKE_OPTIMIZE_DEPENDENCIES` variable when the target is created.


code:
OSX_ARCHITECTURES
-----------------

Target specific architectures for macOS.

The ``OSX_ARCHITECTURES`` property sets the target binary architecture for
targets on macOS (``-arch``).  This property is initialized by the value of the
variable :variable:`CMAKE_OSX_ARCHITECTURES` if it is set when a target is
created.  Use :prop_tgt:`OSX_ARCHITECTURES_<CONFIG>` to set the binary
architectures on a per-configuration basis, where ``<CONFIG>`` is an
upper-case name (e.g. ``OSX_ARCHITECTURES_DEBUG``).


code:
OSX_ARCHITECTURES_<CONFIG>
--------------------------

Per-configuration macOS and iOS binary architectures for a target.

This property is the configuration-specific version of
:prop_tgt:`OSX_ARCHITECTURES`.


code:
OUTPUT_NAME
-----------

Output name for target files.

This sets the base name for output files created for an executable or
library target.  If not set, the logical target name is used by
default during generation. The value is not set by default during
configuration.

Contents of ``OUTPUT_NAME`` and the variants listed below may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.

See also the variants:

* :prop_tgt:`OUTPUT_NAME_<CONFIG>`
* :prop_tgt:`ARCHIVE_OUTPUT_NAME_<CONFIG>`
* :prop_tgt:`ARCHIVE_OUTPUT_NAME`
* :prop_tgt:`LIBRARY_OUTPUT_NAME_<CONFIG>`
* :prop_tgt:`LIBRARY_OUTPUT_NAME`
* :prop_tgt:`RUNTIME_OUTPUT_NAME_<CONFIG>`
* :prop_tgt:`RUNTIME_OUTPUT_NAME`


code:
OUTPUT_NAME_<CONFIG>
--------------------

Per-configuration target file base name.

This is the configuration-specific version of the :prop_tgt:`OUTPUT_NAME`
target property.


code:
PCH_INSTANTIATE_TEMPLATES
-------------------------

.. versionadded:: 3.19

When this property is set to true, the precompiled header compiler options
will contain a flag to instantiate templates during the generation of the PCH
if supported. This can significantly improve compile times. Supported in Clang
since version 11.

This property is initialized by the value of the
:variable:`CMAKE_PCH_INSTANTIATE_TEMPLATES` variable if it is set when a target
is created.  If that variable is not set, the property defaults to ``ON``.


code:
PCH_WARN_INVALID
----------------

.. versionadded:: 3.18

When this property is set to true, the precompile header compiler options
will contain a compiler flag which should warn about invalid precompiled
headers e.g. ``-Winvalid-pch`` for GNU compiler.

This property is initialized by the value of the
:variable:`CMAKE_PCH_WARN_INVALID` variable if it is set when a target is
created.  If that variable is not set, the property defaults to ``ON``.


code:
PDB_NAME
--------

Output name for the MS debug symbol ``.pdb`` file generated by the
linker for an executable or shared library target.

This property specifies the base name for the debug symbols file.
If not set, the :prop_tgt:`OUTPUT_NAME` target property value or
logical target name is used by default.

.. |COMPILE_PDB_XXX| replace:: :prop_tgt:`COMPILE_PDB_NAME`
.. include:: PDB_NOTE.txt


code:
PDB_NAME_<CONFIG>
-----------------

Per-configuration output name for the MS debug symbol ``.pdb`` file
generated by the linker for an executable or shared library target.

This is the configuration-specific version of :prop_tgt:`PDB_NAME`.

.. |COMPILE_PDB_XXX| replace:: :prop_tgt:`COMPILE_PDB_NAME_<CONFIG>`
.. include:: PDB_NOTE.txt


code:
.. note::
 This property does not apply to STATIC library targets because no linker
 is invoked to produce them so they have no linker-generated ``.pdb`` file
 containing debug symbols.

 The linker-generated program database files are specified by the
 ``/pdb`` linker flag and are not the same as compiler-generated
 program database files specified by the ``/Fd`` compiler flag.
 Use the |COMPILE_PDB_XXX| property to specify the latter.


code:
PDB_OUTPUT_DIRECTORY
--------------------

Output directory for the MS debug symbols ``.pdb`` file
generated by the linker for an executable or shared library target.

This property specifies the directory into which the MS debug symbols
will be placed by the linker. The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
Multi-configuration generators append a per-configuration
subdirectory to the specified directory unless a generator expression
is used.

This property is initialized by the value of the
:variable:`CMAKE_PDB_OUTPUT_DIRECTORY` variable if it is
set when a target is created.

.. |COMPILE_PDB_XXX| replace:: :prop_tgt:`COMPILE_PDB_OUTPUT_DIRECTORY`
.. include:: PDB_NOTE.txt


code:
PDB_OUTPUT_DIRECTORY_<CONFIG>
-----------------------------

Per-configuration output directory for the MS debug symbol ``.pdb`` file
generated by the linker for an executable or shared library target.

This is a per-configuration version of :prop_tgt:`PDB_OUTPUT_DIRECTORY`,
but multi-configuration generators (:ref:`Visual Studio Generators`,
:generator:`Xcode`) do NOT append a
per-configuration subdirectory to the specified directory.  This
property is initialized by the value of the
:variable:`CMAKE_PDB_OUTPUT_DIRECTORY_<CONFIG>` variable if it is
set when a target is created.

Contents of ``PDB_OUTPUT_DIRECTORY_<CONFIG>`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.

.. |COMPILE_PDB_XXX| replace:: :prop_tgt:`COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>`
.. include:: PDB_NOTE.txt


code:
POSITION_INDEPENDENT_CODE
-------------------------

Whether to create a position-independent target

The ``POSITION_INDEPENDENT_CODE`` property determines whether position
independent executables or shared libraries will be created.  This
property is ``True`` by default for ``SHARED`` and ``MODULE`` library
targets and ``False`` otherwise.  This property is initialized by the value
of the :variable:`CMAKE_POSITION_INDEPENDENT_CODE` variable  if it is set
when a target is created.

.. note::

  For executable targets, the link step is controlled by the :policy:`CMP0083`
  policy and the :module:`CheckPIESupported` module.


code:
POST_INSTALL_SCRIPT
-------------------

Deprecated install support.

The :prop_tgt:`PRE_INSTALL_SCRIPT` and ``POST_INSTALL_SCRIPT`` properties are
the old way to specify CMake scripts to run before and after installing a
target.  They are used only when the old ``INSTALL_TARGETS`` command is
used to install the target.  Use the :command:`install` command instead.


code:
PRECOMPILE_HEADERS
------------------

.. versionadded:: 3.16

List of header files to precompile.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>`
of header files to precompile specified so far for its target.
Use the :command:`target_precompile_headers` command to append more header
files.

This property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`.


code:
PRECOMPILE_HEADERS_REUSE_FROM
-----------------------------

.. versionadded:: 3.16

Target from which to reuse the precompiled headers build artifact.

See the second signature of :command:`target_precompile_headers` command
for more detailed information.


code:
PREFIX
------

What comes before the library name.

A target property that can be set to override the prefix (such as
``lib``) on a library name.


code:
PRE_INSTALL_SCRIPT
------------------

Deprecated install support.

The ``PRE_INSTALL_SCRIPT`` and :prop_tgt:`POST_INSTALL_SCRIPT` properties are
the old way to specify CMake scripts to run before and after installing a
target.  They are used only when the old ``INSTALL_TARGETS`` command is
used to install the target.  Use the :command:`install` command instead.


code:
PRIVATE_HEADER
--------------

Specify private header files in a :prop_tgt:`FRAMEWORK` shared library target.

Shared library targets marked with the :prop_tgt:`FRAMEWORK` property generate
frameworks on macOS, iOS and normal shared libraries on other platforms.
This property may be set to a list of header files to be placed in the
PrivateHeaders directory inside the framework folder.  On non-Apple
platforms these headers may be installed using the ``PRIVATE_HEADER``
option to the :command:`install(TARGETS)` command.


code:
PROJECT_LABEL
-------------

Change the name of a target in an IDE.

Can be used to change the name of the target in an IDE like Visual
Studio.


code:
PUBLIC_HEADER
-------------

Specify public header files in a :prop_tgt:`FRAMEWORK` shared library target.

Shared library targets marked with the :prop_tgt:`FRAMEWORK` property generate
frameworks on macOS, iOS and normal shared libraries on other platforms.
This property may be set to a list of header files to be placed in the
``Headers`` directory inside the framework folder.  On non-Apple platforms
these headers may be installed using the ``PUBLIC_HEADER`` option to the
:command:`install(TARGETS)` command.


code:
RESOURCE
--------

Specify resource files in a :prop_tgt:`FRAMEWORK` or :prop_tgt:`BUNDLE`.

Target marked with the :prop_tgt:`FRAMEWORK` or :prop_tgt:`BUNDLE` property
generate framework or application bundle (both macOS and iOS is supported)
or normal shared libraries on other platforms.
This property may be set to a list of files to be placed in the corresponding
directory (eg. ``Resources`` directory for macOS) inside the bundle.
On non-Apple platforms these files may be installed using the ``RESOURCE``
option to the :command:`install(TARGETS)` command.

Following example of Application Bundle:

.. code-block:: cmake

  add_executable(ExecutableTarget
    addDemo.c
    resourcefile.txt
    appresourcedir/appres.txt)

  target_link_libraries(ExecutableTarget heymath mul)

  set(RESOURCE_FILES
    resourcefile.txt
    appresourcedir/appres.txt)

  set_target_properties(ExecutableTarget PROPERTIES
    MACOSX_BUNDLE TRUE
    MACOSX_FRAMEWORK_IDENTIFIER org.cmake.ExecutableTarget
    RESOURCE "${RESOURCE_FILES}")

will produce flat structure for iOS systems::

  ExecutableTarget.app
    appres.txt
    ExecutableTarget
    Info.plist
    resourcefile.txt

For macOS systems it will produce following directory structure::

  ExecutableTarget.app/
    Contents
      Info.plist
      MacOS
        ExecutableTarget
      Resources
        appres.txt
        resourcefile.txt

For Linux, such CMake script produce following files::

  ExecutableTarget
  Resources
    appres.txt
    resourcefile.txt


code:
RULE_LAUNCH_COMPILE
-------------------

Specify a launcher for compile rules.

.. note::
  This property is intended for internal use by :manual:`ctest(1)`.  Projects
  and developers should use the :prop_tgt:`<LANG>_COMPILER_LAUNCHER` target
  properties or the associated :variable:`CMAKE_<LANG>_COMPILER_LAUNCHER`
  variables instead.

See the :prop_gbl:`global property <RULE_LAUNCH_COMPILE>` of the same name
for details.  This overrides the global and directory property for a target.


code:
RULE_LAUNCH_CUSTOM
------------------

Specify a launcher for custom rules.

See the global property of the same name for details.  This overrides
the global and directory property for a target.


code:
RULE_LAUNCH_LINK
----------------

Specify a launcher for link rules.

.. note::
  This property is intended for internal use by :manual:`ctest(1)`.  Projects
  and developers should use the :prop_tgt:`<LANG>_LINKER_LAUNCHER` target
  properties or the associated :variable:`CMAKE_<LANG>_LINKER_LAUNCHER`
  variables instead.

See the :prop_gbl:`global property <RULE_LAUNCH_LINK>` of the same name for
details.  This overrides the global and directory property for a target.


code:
RUNTIME_OUTPUT_DIRECTORY
------------------------

.. |XXX| replace:: :ref:`RUNTIME <Runtime Output Artifacts>`
.. |xxx| replace:: runtime
.. |CMAKE_XXX_OUTPUT_DIRECTORY| replace:: :variable:`CMAKE_RUNTIME_OUTPUT_DIRECTORY`
.. include:: XXX_OUTPUT_DIRECTORY.txt

See also the :prop_tgt:`RUNTIME_OUTPUT_DIRECTORY_<CONFIG>` target property.


code:
RUNTIME_OUTPUT_DIRECTORY_<CONFIG>
---------------------------------

Per-configuration output directory for
:ref:`RUNTIME <Runtime Output Artifacts>` target files.

This is a per-configuration version of the
:prop_tgt:`RUNTIME_OUTPUT_DIRECTORY` target property, but
multi-configuration generators (:ref:`Visual Studio Generators`,
:generator:`Xcode`) do NOT append a
per-configuration subdirectory to the specified directory.  This
property is initialized by the value of the
:variable:`CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG>` variable if
it is set when a target is created.

Contents of ``RUNTIME_OUTPUT_DIRECTORY_<CONFIG>`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.


code:
RUNTIME_OUTPUT_NAME
-------------------

.. |XXX| replace:: :ref:`RUNTIME <Runtime Output Artifacts>`
.. |xxx| replace:: runtime
.. include:: XXX_OUTPUT_NAME.txt

See also the :prop_tgt:`RUNTIME_OUTPUT_NAME_<CONFIG>` target property.


code:
RUNTIME_OUTPUT_NAME_<CONFIG>
----------------------------

Per-configuration output name for
:ref:`RUNTIME <Runtime Output Artifacts>` target files.

This is the configuration-specific version of the
:prop_tgt:`RUNTIME_OUTPUT_NAME` target property.


code:
SKIP_BUILD_RPATH
----------------

Should rpaths be used for the build tree.

``SKIP_BUILD_RPATH`` is a boolean specifying whether to skip automatic
generation of an rpath allowing the target to run from the build tree,
see also the :prop_tgt:`BUILD_RPATH` target property.
This property is initialized by the value of the variable
:variable:`CMAKE_SKIP_BUILD_RPATH` if it is set when a target is created.


code:
SOURCES
-------

This specifies the list of paths to source files for the target.
The following commands all set or add to the ``SOURCES`` target property
and are the usual way to manipulate it:

* :command:`add_executable`
* :command:`add_library`
* :command:`add_custom_target`
* :command:`target_sources`

Contents of ``SOURCES`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
If a path starts with a generator expression, it is expected to
evaluate to an absolute path. Not doing so is considered undefined behavior.

Paths that are for files generated by the build will be treated
as relative to the build directory of the target, if the path is not
already specified as an absolute path.  Note that whether a file is seen as
generated may be affected by policy :policy:`CMP0118`.

If a path does not start with a generator expression, is not an
absolute path and is not a generated file, it will be treated as relative to
the location selected by the first of the following that matches:

* If a file by the specified path exists relative to the target's source
  directory, use that file.
* If policy :policy:`CMP0115` is not set to ``NEW``, try appending each
  known source file extension to the path and check if that exists
  relative to the target's source directory.
* Repeat the above two steps, this time relative to the target's binary
  directory instead.

Note that the above decisions are made at generation time, not build time.

See the :manual:`cmake-buildsystem(7)` manual for more on defining
buildsystem properties.


code:
SOURCE_DIR
----------

.. versionadded:: 3.4

This read-only property reports the value of the
:variable:`CMAKE_CURRENT_SOURCE_DIR` variable in the directory in which
the target was defined.


code:
SOVERSION
---------

ABI version number of a shared library target.

For shared libraries :prop_tgt:`VERSION` and ``SOVERSION`` can be used to
specify the build version and ABI version respectively.  When building or
installing appropriate symlinks are created if the platform supports
symlinks and the linker supports so-names.  If only one of both is
specified the missing is assumed to have the same version number.
``SOVERSION`` is ignored if :prop_tgt:`NO_SONAME` property is set.

.. include:: VERSION_SOVERSION_EXAMPLE.txt

Windows Versions
^^^^^^^^^^^^^^^^

For shared libraries and executables on Windows the :prop_tgt:`VERSION`
attribute is parsed to extract a ``<major>.<minor>`` version number.
These numbers are used as the image version of the binary.

Mach-O Versions
^^^^^^^^^^^^^^^

For shared libraries and executables on Mach-O systems (e.g. macOS, iOS),
the ``SOVERSION`` property corresponds to the *compatibility version* and
:prop_tgt:`VERSION` corresponds to the *current version* (unless Mach-O
specific overrides are provided, as discussed below).
See the :prop_tgt:`FRAMEWORK` target property for an example.

For shared libraries, the :prop_tgt:`MACHO_COMPATIBILITY_VERSION` and
:prop_tgt:`MACHO_CURRENT_VERSION` properties can be used to
override the *compatibility version* and *current version* respectively.
Note that ``SOVERSION`` will still be used to form the ``install_name``
and both ``SOVERSION`` and :prop_tgt:`VERSION` may also affect the file
and symlink names.

Versions of Mach-O binaries may be checked with the ``otool -L <binary>``
command.


code:
STATIC_LIBRARY_FLAGS
--------------------

Archiver (or MSVC librarian) flags for a static library target.
Targets that are shared libraries, modules, or executables need to use
the :prop_tgt:`LINK_OPTIONS` or :prop_tgt:`LINK_FLAGS` target properties.

The ``STATIC_LIBRARY_FLAGS`` property, managed as a string, can be used to add
extra flags to the link step of a static library target.
:prop_tgt:`STATIC_LIBRARY_FLAGS_<CONFIG>` will add to the configuration
``<CONFIG>``, for example, ``DEBUG``, ``RELEASE``, ``MINSIZEREL``,
``RELWITHDEBINFO``, ...

.. note::

  This property has been superseded by :prop_tgt:`STATIC_LIBRARY_OPTIONS`
  property.


code:
STATIC_LIBRARY_FLAGS_<CONFIG>
-----------------------------

Per-configuration archiver (or MSVC librarian) flags for a static library
target.

This is the configuration-specific version of :prop_tgt:`STATIC_LIBRARY_FLAGS`.

.. note::

  This property has been superseded by :prop_tgt:`STATIC_LIBRARY_OPTIONS`
  property.


code:
STATIC_LIBRARY_OPTIONS
----------------------

.. versionadded:: 3.13

Archiver (or MSVC librarian) flags for a static library target.
Targets that are shared libraries, modules, or executables need to use
the :prop_tgt:`LINK_OPTIONS` target property.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>` of options
specified so far for its target.  Use :command:`set_target_properties` or
:command:`set_property` commands to set its content.

Contents of ``STATIC_LIBRARY_OPTIONS`` may use "generator expressions" with the
syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)` manual
for available expressions.  See the :manual:`cmake-buildsystem(7)` manual
for more on defining buildsystem properties.

.. note::

  This property must be used in preference to :prop_tgt:`STATIC_LIBRARY_FLAGS`
  property.

.. include:: ../command/OPTIONS_SHELL.txt


code:
SUFFIX
------

What comes after the target name.

A target property that can be set to override the suffix (such as
``.so`` or ``.exe``) on the name of a library, module or executable.


code:
SYSTEM
------

.. versionadded:: 3.25

Specifies that a target is a system target.  This has the following
effects:

* Entries of :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` are treated as
  system include directories when compiling consumers.
  Entries of :prop_tgt:`INTERFACE_SYSTEM_INCLUDE_DIRECTORIES` are not
  affected, and will always be treated as system include directories.
* On Apple platforms, If the :prop_tgt:`FRAMEWORK` target property is true,
  the frameworks directory is treated as system.

For imported targets, this property defaults to true, which means
that their :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` and, if the
:prop_tgt:`FRAMEWORK` target property is true, frameworks directory are
treated as system directories by default.  If their ``SYSTEM`` property is
false, then their :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` as well as
frameworks will not be treated as system.  Use the :prop_tgt:`EXPORT_NO_SYSTEM`
property to change how a target's ``SYSTEM`` property is set when it is
installed.

For non-imported targets, this target property is initialized from
the :prop_dir:`SYSTEM` directory property when the target is created.


code:
``incremental``
  Compiles each Swift source in the module separately, resulting in better
  parallelism in the build. The compiler emits additional information into
  the build directory improving rebuild performance when small changes are made
  to the source between rebuilds. This is the best option to use while
  iterating on changes in a project.

``wholemodule``
  Whole-module optimizations are slowest to compile, but results in the most
  optimized library. The entire context is loaded into once instance of the
  compiler, so there is no parallelism across source files in the module.

``singlefile``
  Compiles each source in a Swift modules separately, resulting in better
  parallelism. Unlike the ``incremental`` build mode, no additional information
  is emitted by the compiler during the build, so rebuilding after making small
  changes to the source file will not run faster. This option should be used
  sparingly, preferring ``incremental`` builds, unless working around a compiler
  bug.


code:
Swift_COMPILATION_MODE
----------------------

.. versionadded:: 3.29

Specify how Swift compiles a target.

The allowed values are:

.. include:: Swift_COMPILATION_MODE-VALUES.txt

Use :manual:`generator expressions <cmake-generator-expressions(7)>` to support
per-configuration specification. For example, the code:

.. code-block:: cmake

  add_library(foo foo.swift)
  set_property(TARGET foo PROPERTY
    Swift_COMPILATION_MODE "$<IF:$<CONFIG:Release>,wholemodule,incremental>")

sets the Swift compilation mode to wholemodule mode in the release configuration
and sets the property to incremental mode in other configurations.

The property is initialized from the value of the
:variable:`CMAKE_Swift_COMPILATION_MODE` variable, if it is set. If the property
is not set or is empty, then CMake uses the default value ``incremental`` to
specify the swift compilation mode.

.. note::

   This property only has effect when policy :policy:`CMP0157` is set to ``NEW``
   prior to the first :command:`project` or :command:`enable_language` command
   that enables the Swift language.


code:
Swift_DEPENDENCIES_FILE
-----------------------

.. versionadded:: 3.15

This property sets the path for the Swift dependency file (swiftdep) for the
target.  If one is not specified, it will default to ``<TARGET>.swiftdeps``.


code:
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
:variable:`CMAKE_Swift_LANGUAGE_VERSION` if specified, otherwise it is the
latest version supported by the compiler.


code:
Swift_MODULE_DIRECTORY
----------------------

.. versionadded:: 3.15

Specify output directory for Swift modules provided by the target.

If the target contains Swift source files, this specifies the directory in which
the modules will be placed.  When this property is not set, the modules will be
placed in the build directory corresponding to the target's source directory.
If the variable :variable:`CMAKE_Swift_MODULE_DIRECTORY` is set when a target is
created its value is used to initialize this property.


code:
Swift_MODULE_NAME
-----------------

.. versionadded:: 3.15

This property specifies the name of the Swift module.  It is defaulted to the
name of the target.


code:
TEST_LAUNCHER
-------------

.. versionadded:: 3.29

Use the given launcher to run executables.
This command will be added as a prefix to :command:`add_test` commands
for build target system executables and is meant to be run on the host
machine.

It effectively acts as a run script for tests in a similar way
to how :variable:`CMAKE_<LANG>_COMPILER_LAUNCHER` works for compilation.

If this property contains a :ref:`semicolon-separated list <CMake Language
Lists>`, then the first value is the command and remaining values are its
arguments.

Contents of ``TEST_LAUNCHER`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.

This property is initialized by the value of the
:variable:`CMAKE_TEST_LAUNCHER` variable if it is set when a target
is created.


code:
TYPE
----

The type of the target.

This read-only property can be used to test the type of the given
target.  It will be one of ``STATIC_LIBRARY``, ``MODULE_LIBRARY``,
``SHARED_LIBRARY``, ``OBJECT_LIBRARY``, ``INTERFACE_LIBRARY``, ``EXECUTABLE``
or one of the internal target types.


code:
UNITY_BUILD
-----------

.. versionadded:: 3.16

When this property is set to true, the target source files will be combined
into batches for faster compilation.  This is done by creating a (set of)
unity sources which ``#include`` the original sources, then compiling these
unity sources instead of the originals.  This is known as a *Unity* or *Jumbo*
build.

CMake provides different algorithms for selecting which sources are grouped
together into a *bucket*. Algorithm selection is decided by the
:prop_tgt:`UNITY_BUILD_MODE` target property, which has the following acceptable
values:

* ``BATCH``
  When in this mode CMake determines which files are grouped together.
  The :prop_tgt:`UNITY_BUILD_BATCH_SIZE` property controls the upper limit on
  how many sources can be combined per unity source file.

* ``GROUP``
  When in this mode each target explicitly specifies how to group
  source files. Each source file that has the same
  :prop_sf:`UNITY_GROUP` value will be grouped together. Any sources
  that don't have this property will be compiled individually. The
  :prop_tgt:`UNITY_BUILD_BATCH_SIZE` property is ignored when using
  this mode.

If no explicit :prop_tgt:`UNITY_BUILD_MODE` has been specified, CMake will
default to ``BATCH``.

Unity builds are supported for the following languages:

``C``
  .. versionadded:: 3.16

``CXX``
  .. versionadded:: 3.16

``OBJC``
  .. versionadded:: 3.29

``OBJCXX``
  .. versionadded:: 3.29

For targets that mix source files from more than one language, CMake
separates the languages such that each generated unity source file only
contains sources for a single language.

This property is initialized by the value of the :variable:`CMAKE_UNITY_BUILD`
variable when a target is created.

.. note::

  Projects should not directly set the ``UNITY_BUILD`` property or its
  associated :variable:`CMAKE_UNITY_BUILD` variable to true.  Depending
  on the capabilities of the build machine and compiler used, it might or
  might not be appropriate to enable unity builds.  Therefore, this feature
  should be under developer control, which would normally be through the
  developer choosing whether or not to set the :variable:`CMAKE_UNITY_BUILD`
  variable on the :manual:`cmake(1)` command line or some other equivalent
  method.  However, it IS recommended to set the ``UNITY_BUILD`` target
  property to false if it is known that enabling unity builds for the
  target can lead to problems.

ODR (One definition rule) errors
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When multiple source files are included into one source file, as is done
for unity builds, it can potentially lead to ODR errors.  CMake provides
a number of measures to help address such problems:

* Any source file that has a non-empty :prop_sf:`COMPILE_OPTIONS`,
  :prop_sf:`COMPILE_DEFINITIONS`, :prop_sf:`COMPILE_FLAGS`, or
  :prop_sf:`INCLUDE_DIRECTORIES` source property will not be combined
  into a unity source.

* Any source file which is scanned for C++ module sources via
  :prop_tgt:`CXX_SCAN_FOR_MODULES`, :prop_sf:`CXX_SCAN_FOR_MODULES`, or
  membership of a ``CXX_MODULES`` file set will not be combined into a unity
  source.  See :manual:`cmake-cxxmodules(7)` for details.

* Projects can prevent an individual source file from being combined into
  a unity source by setting its :prop_sf:`SKIP_UNITY_BUILD_INCLUSION`
  source property to true.  This can be a more effective way to prevent
  problems with specific files than disabling unity builds for an entire
  target.

* Projects can set :prop_tgt:`UNITY_BUILD_UNIQUE_ID` to cause a valid
  C-identifier to be generated which is unique per file in a unity
  build.  This can be used to avoid problems with anonymous namespaces
  in unity builds.

* The :prop_tgt:`UNITY_BUILD_CODE_BEFORE_INCLUDE` and
  :prop_tgt:`UNITY_BUILD_CODE_AFTER_INCLUDE` target properties can be used
  to inject code into the unity source files before and after every
  ``#include`` statement.

* The order of source files added to the target via commands like
  :command:`add_library`, :command:`add_executable` or
  :command:`target_sources` will be preserved in the generated unity source
  files.  This can be used to manually enforce a specific grouping based on
  the :prop_tgt:`UNITY_BUILD_BATCH_SIZE` target property.


code:
UNITY_BUILD_BATCH_SIZE
----------------------

.. versionadded:: 3.16

Specifies the maximum number of source files that can be combined into any one
unity source file when unity builds are enabled by the :prop_tgt:`UNITY_BUILD`
target property.  The original source files will be distributed across as many
unity source files as necessary to honor this limit.

The initial value for this property is taken from the
:variable:`CMAKE_UNITY_BUILD_BATCH_SIZE` variable when the target is created.
If that variable has not been set, the initial value will be 8.

The batch size needs to be selected carefully.  If set too high, the size of
the combined source files could result in the compiler using excessive memory
or hitting other similar limits.  In extreme cases, this can even result in
build failure.  On the other hand, if the batch size is too low, there will be
little gain in build performance.

Although strongly discouraged, the batch size may be set to a value of 0 to
combine all the sources for the target into a single unity file, regardless of
how many sources are involved.  This runs the risk of creating an excessively
large unity source file and negatively impacting the build performance, so
a value of 0 is not generally recommended.


code:
UNITY_BUILD_CODE_AFTER_INCLUDE
------------------------------

.. versionadded:: 3.16

Code snippet which is included verbatim by the :prop_tgt:`UNITY_BUILD`
feature just after every ``#include`` statement in the generated unity
source files.  For example:

.. code-block:: cmake

  set(after [[
  #if defined(NOMINMAX)
  #undef NOMINMAX
  #endif
  ]])
  set_target_properties(myTarget PROPERTIES
    UNITY_BUILD_CODE_AFTER_INCLUDE "${after}"
  )

See also :prop_tgt:`UNITY_BUILD_CODE_BEFORE_INCLUDE`.


code:
UNITY_BUILD_CODE_BEFORE_INCLUDE
-------------------------------

.. versionadded:: 3.16

Code snippet which is included verbatim by the :prop_tgt:`UNITY_BUILD`
feature just before every ``#include`` statement in the generated unity
source files.  For example:

.. code-block:: cmake

  set(before [[
  #if !defined(NOMINMAX)
  #define NOMINMAX
  #endif
  ]])
  set_target_properties(myTarget PROPERTIES
    UNITY_BUILD_CODE_BEFORE_INCLUDE "${before}"
  )

See also :prop_tgt:`UNITY_BUILD_CODE_AFTER_INCLUDE`.


code:
UNITY_BUILD_MODE
----------------

.. versionadded:: 3.18

CMake provides different algorithms for selecting which sources are grouped
together into a *bucket*. Selection is decided by this property,
which has the following acceptable values:

``BATCH``
  When in this mode CMake determines which files are grouped together.
  The :prop_tgt:`UNITY_BUILD_BATCH_SIZE` property controls the upper limit on
  how many sources can be combined per unity source file.

  Example usage:

  .. code-block:: cmake

    add_library(example_library
                source1.cxx
                source2.cxx
                source3.cxx
                source4.cxx)

    set_target_properties(example_library PROPERTIES
                          UNITY_BUILD_MODE BATCH
                          UNITY_BUILD_BATCH_SIZE 2
                          )

``GROUP``
  When in this mode each target explicitly specifies how to group
  source files. Each source file that has the same
  :prop_sf:`UNITY_GROUP` value will be grouped together. Any sources
  that don't have this property will be compiled individually. The
  :prop_tgt:`UNITY_BUILD_BATCH_SIZE` property is ignored when using
  this mode.

  Example usage:

  .. code-block:: cmake

    add_library(example_library
                source1.cxx
                source2.cxx
                source3.cxx
                source4.cxx)

    set_target_properties(example_library PROPERTIES
                          UNITY_BUILD_MODE GROUP
                          )

    set_source_files_properties(source1.cxx source2.cxx source3.cxx
                                PROPERTIES UNITY_GROUP "bucket1"
                                )
    set_source_files_properties(source4.cxx
                                PROPERTIES UNITY_GROUP "bucket2"
                                )

If no explicit ``UNITY_BUILD_MODE`` has been specified, CMake will
default to ``BATCH``.


code:
UNITY_BUILD_UNIQUE_ID
---------------------

.. versionadded:: 3.20

The name of a valid C-identifier which is set to a unique per-file
value during unity builds.

When this property is populated and when :prop_tgt:`UNITY_BUILD`
is true, the property value is used to define a compiler definition
of the specified name. The value of the defined symbol is unspecified,
but it is unique per file path.

Given:

.. code-block:: cmake

  set_target_properties(myTarget PROPERTIES
    UNITY_BUILD "ON"
    UNITY_BUILD_UNIQUE_ID "MY_UNITY_ID"
  )

the ``MY_UNITY_ID`` symbol is defined to a unique per-file value.

One known use case for this identifier is to disambiguate the
variables in an anonymous namespace in a limited scope.
Anonymous namespaces present a problem for unity builds because
they are used to ensure that certain variables and declarations
are scoped to a translation unit which is approximated by a
single source file.  When source files are combined in a unity
build file, those variables in different files are combined in
a single translation unit and the names clash.  This property can
be used to avoid that with code like the following:

.. code-block:: cpp

  // Needed for when unity builds are disabled
  #ifndef MY_UNITY_ID
  #define MY_UNITY_ID
  #endif

  namespace { namespace MY_UNITY_ID {
    // The name 'i' clashes (or could clash) with other
    // variables in other anonymous namespaces
    int i = 42;
  }}

  int use_var()
  {
    return MY_UNITY_ID::i;
  }

The pseudonymous namespace is used within a truly anonymous namespace.
On many platforms, this maintains the invariant that the symbols within
do not get external linkage when performing a unity build.