code:
HEADER_SET_<NAME>
-----------------

.. versionadded:: 3.23

Semicolon-separated list of files in the target's ``<NAME>`` header set,
which has the set type ``HEADERS``. If any of the paths are relative,
they are computed relative to the target's source directory. The property
supports :manual:`generator expressions <cmake-generator-expressions(7)>`.

This property is normally only set by :command:`target_sources(FILE_SET)`
rather than being manipulated directly.

See :prop_tgt:`HEADER_SET` for the list of files in the default header set.
See :prop_tgt:`HEADER_SETS` for the file set names of all header sets.


code:
HIP_ARCHITECTURES
-----------------

.. versionadded:: 3.21

List of GPU architectures to for which to generate device code.
Architecture names are interpreted based on :variable:`CMAKE_HIP_PLATFORM`.

A non-empty false value (e.g. ``OFF``) disables adding architectures.
This is intended to support packagers and rare cases where full control
over the passed flags is required.

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

The HIP compilation model has two modes: whole and separable. Whole compilation
generates device code at compile time. Separable compilation generates device
code at link time. Therefore the ``HIP_ARCHITECTURES`` target property should
be set on targets that compile or link with any HIP sources.

Examples
^^^^^^^^

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY HIP_ARCHITECTURES gfx801 gfx900)

Generates code for both ``gfx801`` and ``gfx900``.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
HIP_EXTENSIONS
--------------

.. versionadded:: 3.21

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 HIP/C++ standard level is
controlled by the :prop_tgt:`HIP_STANDARD` target property.

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_HIP_EXTENSIONS` variable if set when a target is created
and otherwise by the value of
:variable:`CMAKE_HIP_EXTENSIONS_DEFAULT <CMAKE_<LANG>_EXTENSIONS_DEFAULT>` (see
:policy:`CMP0128`).


code:
HIP_STANDARD
------------

.. versionadded:: 3.21

The HIP/C++ standard requested to build this target.

Supported values are:

``98``
  HIP C++98

``11``
  HIP C++11

``14``
  HIP C++14

``17``
  HIP C++17

``20``
  HIP C++20

``23``
  HIP C++23

``26``
  .. versionadded:: 3.25

  HIP 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 HIP_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:`HIP_STANDARD_REQUIRED` target property.
Additionally, the :prop_tgt:`HIP_EXTENSIONS` target property may be used to
control whether compiler-specific extensions are enabled on a per-target basis.

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_HIP_STANDARD` variable if it is set when a target
is created.


code:
HIP_STANDARD_REQUIRED
---------------------

.. versionadded:: 3.21

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

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

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_HIP_STANDARD_REQUIRED` variable if it is set when a
target is created.


code:
IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
----------------------------------

Specify ``#include`` line transforms for dependencies in a target.

This property specifies rules to transform macro-like ``#include`` lines
during implicit dependency scanning of C and C++ source files.  The
list of rules must be semicolon-separated with each entry of the form
``A_MACRO(%)=value-with-%`` (the ``%`` must be literal).  During dependency
scanning occurrences of ``A_MACRO(...)`` on ``#include`` lines will be
replaced by the value given with the macro argument substituted for
``%``.  For example, the entry

::

  MYDIR(%)=<mydir/%>

will convert lines of the form

::

  #include MYDIR(myheader.h)

to

::

  #include <mydir/myheader.h>

allowing the dependency to be followed.

This property applies to sources in the target on which it is set.


code:
IMPORTED
--------

Read-only indication of whether a target is ``IMPORTED``.

The boolean value of this property is ``True`` for targets created with
the ``IMPORTED`` option to :command:`add_executable` or :command:`add_library`.
It is ``False`` for targets built within the project.


code:
IMPORTED_COMMON_LANGUAGE_RUNTIME
--------------------------------

.. versionadded:: 3.12

Property to define if the target uses ``C++/CLI``.

Ignored for non-imported targets.

See also the :prop_tgt:`COMMON_LANGUAGE_RUNTIME` target property.


code:
IMPORTED_CONFIGURATIONS
-----------------------

Configurations provided for an :ref:`imported target <Imported targets>`.

Set this to the list of configuration names available for an imported
target.  For each configuration named, the imported target's artifacts
must be specified in other target properties:

* :prop_tgt:`IMPORTED_LOCATION_<CONFIG>`, or
* :prop_tgt:`IMPORTED_IMPLIB_<CONFIG>` (on DLL platforms, on AIX for
  :ref:`Executables <Binary Executables>` or on Apple for
  :ref:`Shared Libraries <Normal Libraries>`), or
* :prop_tgt:`IMPORTED_OBJECTS_<CONFIG>` (for :ref:`Object Libraries`), or
* :prop_tgt:`IMPORTED_LIBNAME_<CONFIG>` (for :ref:`Interface Libraries`).

The configuration names correspond to those defined in the project from
which the target is imported.  If the importing project uses a different
set of configurations, the names may be mapped using the
:prop_tgt:`MAP_IMPORTED_CONFIG_<CONFIG>` target property.

The ``IMPORTED_CONFIGURATIONS`` property is ignored for non-imported targets.


code:
IMPORTED_CXX_MODULES_COMPILE_DEFINITIONS
----------------------------------------

.. versionadded:: 3.28

Preprocessor definitions for compiling an ``IMPORTED`` target's C++ module
sources.

CMake will automatically drop some definitions that are not supported
by the native build tool.


code:
IMPORTED_CXX_MODULES_COMPILE_FEATURES
-------------------------------------

.. versionadded:: 3.28

Compiler features enabled for this ``IMPORTED`` target's C++ modules.

The value of this property is used by the generators to set the include
paths for the compiler.


code:
IMPORTED_CXX_MODULES_COMPILE_OPTIONS
------------------------------------

.. versionadded:: 3.28

List of options to pass to the compiler for this ``IMPORTED`` target's C++
modules.

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


code:
IMPORTED_CXX_MODULES_INCLUDE_DIRECTORIES
----------------------------------------

.. versionadded:: 3.28

List of preprocessor include file search directories when compiling C++
modules for ``IMPORTED`` targets.

The value of this property is used by the generators to set the include
paths for the compiler.


code:
IMPORTED_CXX_MODULES_LINK_LIBRARIES
-----------------------------------

.. versionadded:: 3.28

List of direct dependencies to use for usage requirements for C++ modules in
the target's C++ modules.


code:
IMPORTED_GLOBAL
---------------

.. versionadded:: 3.11

Indication of whether an :ref:`IMPORTED target <Imported Targets>` is
globally visible.

The boolean value of this property is True for targets created with the
``IMPORTED`` ``GLOBAL`` options to :command:`add_executable()` or
:command:`add_library()`. It is always False for targets built within the
project.

For targets created with the ``IMPORTED`` option to
:command:`add_executable()` or :command:`add_library()` but without the
additional option ``GLOBAL`` this is False, too. However, setting this
property for such a locally ``IMPORTED`` target to True promotes that
target to global scope. This promotion can only be done in the same
directory where that ``IMPORTED`` target was created in the first place.

.. note::

  Once an imported target has been made global, it cannot be changed back to
  non-global. Therefore, if a project sets this property, it may only
  provide a value of True. CMake will issue an error if the project tries to
  set the property to a non-True value, even if the value was already False.

.. note::

  Local :ref:`ALIAS targets <Alias Targets>` created before promoting an
  :ref:`IMPORTED target <Imported Targets>` from ``LOCAL`` to ``GLOBAL``, keep
  their initial scope (see :prop_tgt:`ALIAS_GLOBAL` target property).


code:
IMPORTED_IMPLIB
---------------

Full path to the import library for an ``IMPORTED`` target.

This property may be set:

* On DLL platforms, to the location of the ``.lib`` part of the DLL.
* .. versionadded:: 3.16
    On AIX, to an import file (e.g. ``.imp``) created for executables that
    export symbols (see the :prop_tgt:`ENABLE_EXPORTS` target property).
* .. versionadded:: 3.27
    On Apple platforms, to an import file (e.g. ``.tbd``) created for shared
    libraries or frameworks (see the :prop_tgt:`ENABLE_EXPORTS` target
    property).  For frameworks, this is the location of the ``.tbd`` file
    symlink just inside the framework folder.
* .. versionadded:: 3.28
    On non-DLL platforms, to the location of a shared library.
    When set without also specifying an :prop_tgt:`IMPORTED_LOCATION`,
    the library is considered to be a stub, and its location will not
    be added as a runtime search path to dependents that link it.

.. versionchanged:: 3.28
  If an imported target is an Apple framework or XCFramework, the preferred
  arrangement is to set :prop_tgt:`IMPORTED_LOCATION` to the ``.framework``
  or ``.xcframework`` directory.  CMake will then find the relevant ``.tbd``
  file inside that framework or XCFramework automatically without requiring
  ``IMPORTED_IMPLIB`` to be set.

The ``IMPORTED_IMPLIB`` target property may be overridden for a
given configuration ``<CONFIG>`` by the configuration-specific
:prop_tgt:`IMPORTED_IMPLIB_<CONFIG>` target property.  Furthermore,
the :prop_tgt:`MAP_IMPORTED_CONFIG_<CONFIG>` target property may be
used to map between a project's configurations and those of an imported
target.  If none of these is set then the name of any other configuration
listed in the :prop_tgt:`IMPORTED_CONFIGURATIONS` target property may be
selected and its :prop_tgt:`IMPORTED_IMPLIB_<CONFIG>` value used.

This property is ignored for non-imported targets.


code:
IMPORTED_IMPLIB_<CONFIG>
------------------------

<CONFIG>-specific version of :prop_tgt:`IMPORTED_IMPLIB` property.

Configuration names correspond to those provided by the project from
which the target is imported.


code:
IMPORTED_LIBNAME
----------------

.. versionadded:: 3.8

Specify the link library name for an :ref:`imported <Imported Targets>`
:ref:`Interface Library <Interface Libraries>`.

An interface library builds no library file itself but does specify
usage requirements for its consumers.  The ``IMPORTED_LIBNAME``
property may be set to specify a single library name to be placed
on the link line in place of the interface library target name as
a requirement for using the interface.

This property is intended for use in naming libraries provided by
a platform SDK for which the full path to a library file may not
be known.  The value may be a plain library name such as ``foo``
but may *not* be a path (e.g. ``/usr/lib/libfoo.so``) or a flag
(e.g. ``-Wl,...``).  The name is never treated as a library target
name even if it happens to name one.

The ``IMPORTED_LIBNAME`` property is allowed only on
:ref:`imported <Imported Targets>` :ref:`Interface Libraries`
and is rejected on targets of other types (for which
the :prop_tgt:`IMPORTED_LOCATION` target property may be used).


code:
IMPORTED_LIBNAME_<CONFIG>
-------------------------

.. versionadded:: 3.8

<CONFIG>-specific version of :prop_tgt:`IMPORTED_LIBNAME` property.

Configuration names correspond to those provided by the project from
which the target is imported.


code:
IMPORTED_LINK_DEPENDENT_LIBRARIES
---------------------------------

Dependent shared libraries of an imported shared library.

Shared libraries may be linked to other shared libraries as part of
their implementation.  On some platforms the linker searches for the
dependent libraries of shared libraries they are including in the
link.  Set this property to the list of dependent shared libraries of
an imported library.  The list should be disjoint from the list of
interface libraries in the :prop_tgt:`INTERFACE_LINK_LIBRARIES` property.  On
platforms requiring dependent shared libraries to be found at link
time CMake uses this list to add appropriate files or paths to the
link command line.  Ignored for non-imported targets.


code:
IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG>
------------------------------------------

<CONFIG>-specific version of :prop_tgt:`IMPORTED_LINK_DEPENDENT_LIBRARIES`.

Configuration names correspond to those provided by the project from
which the target is imported.  If set, this property completely
overrides the generic property for the named configuration.


code:
IMPORTED_LINK_INTERFACE_LANGUAGES
---------------------------------

Languages compiled into an ``IMPORTED`` static library.

Set this to the list of languages of source files compiled to produce
a ``STATIC IMPORTED`` library (such as ``C`` or ``CXX``).  CMake accounts for
these languages when computing how to link a target to the imported
library.  For example, when a C executable links to an imported C++
static library CMake chooses the C++ linker to satisfy language
runtime dependencies of the static library.

This property is ignored for targets that are not ``STATIC`` libraries.
This property is ignored for non-imported targets.


code:
IMPORTED_LINK_INTERFACE_LANGUAGES_<CONFIG>
------------------------------------------

<CONFIG>-specific version of :prop_tgt:`IMPORTED_LINK_INTERFACE_LANGUAGES`.

Configuration names correspond to those provided by the project from
which the target is imported.  If set, this property completely
overrides the generic property for the named configuration.


code:
IMPORTED_LINK_INTERFACE_LIBRARIES
---------------------------------

Transitive link interface of an ``IMPORTED`` target.

Set this to the list of libraries whose interface is included when an
``IMPORTED`` library target is linked to another target.  The libraries
will be included on the link line for the target.  Unlike the
:prop_tgt:`LINK_INTERFACE_LIBRARIES` property, this property applies to all
imported target types, including ``STATIC`` libraries.  This property is
ignored for non-imported targets.

This property is ignored if the target also has a non-empty
:prop_tgt:`INTERFACE_LINK_LIBRARIES` property.

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


code:
IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG>
------------------------------------------

<CONFIG>-specific version of :prop_tgt:`IMPORTED_LINK_INTERFACE_LIBRARIES`.

Configuration names correspond to those provided by the project from
which the target is imported.  If set, this property completely
overrides the generic property for the named configuration.

This property is ignored if the target also has a non-empty
:prop_tgt:`INTERFACE_LINK_LIBRARIES` property.

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


code:
IMPORTED_LINK_INTERFACE_MULTIPLICITY
------------------------------------

Repetition count for cycles of ``IMPORTED`` static libraries.

This is :prop_tgt:`LINK_INTERFACE_MULTIPLICITY` for ``IMPORTED`` targets.


code:
IMPORTED_LINK_INTERFACE_MULTIPLICITY_<CONFIG>
---------------------------------------------

<CONFIG>-specific version of :prop_tgt:`IMPORTED_LINK_INTERFACE_MULTIPLICITY`.

If set, this property completely overrides the generic property for
the named configuration.


code:
IMPORTED_LOCATION
-----------------

Full path to the main file on disk for an ``IMPORTED`` target.

Set this to the location of an ``IMPORTED`` target file on disk.  For
executables this is the location of the executable file.  For ``STATIC``
libraries and modules this is the location of the library or module.
For ``SHARED`` libraries on non-DLL platforms this is the location of the
shared library.  For application bundles on macOS this is the location of
the executable file inside ``Contents/MacOS`` within the bundle folder.
For frameworks on macOS this is the location of the
library file symlink just inside the framework folder.  For DLLs this
is the location of the ``.dll`` part of the library.  For ``UNKNOWN``
libraries this is the location of the file to be linked.  Ignored for
non-imported targets.

.. versionadded:: 3.28

  For ordinary frameworks on Apple platforms, this may be the location of the
  ``.framework`` folder itself.  For XCFrameworks, it may be the location of
  the ``.xcframework`` folder, in which case any target that links against it
  will get the selected library's ``Headers`` directory as a usage requirement.

The ``IMPORTED_LOCATION`` target property may be overridden for a
given configuration ``<CONFIG>`` by the configuration-specific
:prop_tgt:`IMPORTED_LOCATION_<CONFIG>` target property.  Furthermore,
the :prop_tgt:`MAP_IMPORTED_CONFIG_<CONFIG>` target property may be
used to map between a project's configurations and those of an imported
target.  If none of these is set then the name of any other configuration
listed in the :prop_tgt:`IMPORTED_CONFIGURATIONS` target property may be
selected and its :prop_tgt:`IMPORTED_LOCATION_<CONFIG>` value used.

To get the location of an imported target read one of the :prop_tgt:`LOCATION`
or :prop_tgt:`LOCATION_<CONFIG>` properties.

For platforms with import libraries (e.g. Windows, AIX or Apple) see also
:prop_tgt:`IMPORTED_IMPLIB`.


code:
IMPORTED_LOCATION_<CONFIG>
--------------------------

<CONFIG>-specific version of :prop_tgt:`IMPORTED_LOCATION` property.

Configuration names correspond to those provided by the project from
which the target is imported.


code:
IMPORTED_NO_SONAME
------------------

Specifies that an ``IMPORTED`` shared library target has no ``soname``.

Set this property to true for an imported shared library file that has
no ``soname`` field.  CMake may adjust generated link commands for some
platforms to prevent the linker from using the path to the library in
place of its missing ``soname``.  Ignored for non-imported targets.


code:
IMPORTED_NO_SONAME_<CONFIG>
---------------------------

<CONFIG>-specific version of :prop_tgt:`IMPORTED_NO_SONAME` property.

Configuration names correspond to those provided by the project from
which the target is imported.


code:
IMPORTED_NO_SYSTEM
------------------

.. versionadded:: 3.23

.. deprecated:: 3.25

  ``IMPORTED_NO_SYSTEM`` is deprecated. Please use the following alternatives
  instead:

  * Set :prop_tgt:`SYSTEM` to false if you don't want a target's include
    directories to be treated as system directories when compiling consumers.
  * Set :prop_tgt:`EXPORT_NO_SYSTEM` to true if you don't want the include
    directories of the imported target generated by :command:`install(EXPORT)`
    and :command:`export` commands to be treated as system directories when
    compiling consumers.

Setting ``IMPORTED_NO_SYSTEM`` to true on an
:ref:`imported target <Imported Targets>` specifies that it is not a
system target.  This has the following effects:

* Entries of :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` are not treated
  as system include directories when compiling consumers (regardless of
  the value of the consumed target's :prop_tgt:`SYSTEM` property), as they
  would be by default.   Entries of
  :prop_tgt:`INTERFACE_SYSTEM_INCLUDE_DIRECTORIES` are not affected,
  and will always be treated as system include directories.
* On Apple platforms, when the target is a framework, it will not be treated as
  system.

This property can also be enabled on a non-imported target.  Doing so does
not affect the build system, but does tell the :command:`install(EXPORT)` and
:command:`export` commands to enable it on the imported targets they generate.

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


code:
IMPORTED_OBJECTS
----------------

.. versionadded:: 3.9

A :ref:`semicolon-separated list <CMake Language Lists>` of absolute paths
to the object files on disk for an :ref:`imported <Imported targets>`
:ref:`object library <object libraries>`.

Ignored for non-imported targets.

Projects may skip ``IMPORTED_OBJECTS`` if the configuration-specific
property :prop_tgt:`IMPORTED_OBJECTS_<CONFIG>` is set instead, except in
situations as noted in the section below.

Xcode Generator Considerations
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.20

For Apple platforms, a project may be built for more than one architecture.
This is controlled by the :variable:`CMAKE_OSX_ARCHITECTURES` variable.
For all but the :generator:`Xcode` generator, CMake invokes compilers once
per source file and passes multiple ``-arch`` flags, leading to a single
object file which will be a universal binary.  Such object files work well
when listed in the ``IMPORTED_OBJECTS`` of a separate CMake build, even for
the :generator:`Xcode` generator.  But producing such object files with the
:generator:`Xcode` generator is more difficult, since it invokes the compiler
once per architecture for each source file.  Unlike the other generators,
it does not generate universal object file binaries.

A further complication with the :generator:`Xcode` generator is that when
targeting device platforms (iOS, tvOS, visionOS or watchOS), the :generator:`Xcode`
generator has the ability to use either the device or simulator SDK without
needing CMake to be re-run.  The SDK can be selected at build time.
But since some architectures can be supported by both the device and the
simulator SDKs (e.g. ``arm64`` with Xcode 12 or later), not all combinations
can be represented in a single universal binary.  The only solution in this
case is to have multiple object files.

``IMPORTED_OBJECTS`` doesn't support generator expressions, so every file
it lists needs to be valid for every architecture and SDK.  If incorporating
object files that are not universal binaries, the path and/or file name of
each object file has to somehow encapsulate the different architectures and
SDKs.  With the :generator:`Xcode` generator, Xcode variables of the form
``$(...)`` can be used to represent these aspects and Xcode will substitute
the appropriate values at build time.  CMake doesn't interpret these
variables and embeds them unchanged in the Xcode project file.
``$(CURRENT_ARCH)`` can be used to represent the architecture, while
``$(EFFECTIVE_PLATFORM_NAME)`` can be used to differentiate between SDKs.

The following shows one example of how these two variables can be used to
refer to an object file whose location depends on both the SDK and the
architecture:

.. code-block:: cmake

  add_library(someObjs OBJECT IMPORTED)

  set_property(TARGET someObjs PROPERTY IMPORTED_OBJECTS
    # Quotes are required because of the ()
    "/path/to/somewhere/objects$(EFFECTIVE_PLATFORM_NAME)/$(CURRENT_ARCH)/func.o"
  )

  # Example paths:
  #   /path/to/somewhere/objects-iphoneos/arm64/func.o
  #   /path/to/somewhere/objects-iphonesimulator/x86_64/func.o

In some cases, you may want to have configuration-specific object files
as well.  The ``$(CONFIGURATION)`` Xcode variable is often used for this and
can be used in conjunction with the others mentioned above:

.. code-block:: cmake

  add_library(someObjs OBJECT IMPORTED)
  set_property(TARGET someObjs PROPERTY IMPORTED_OBJECTS
    "/path/to/somewhere/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/$(CURRENT_ARCH)/func.o"
  )

  # Example paths:
  #   /path/to/somewhere/Release-iphoneos/arm64/func.o
  #   /path/to/somewhere/Debug-iphonesimulator/x86_64/func.o

When any Xcode variable is used, CMake is not able to fully evaluate the
path(s) at configure time.  One consequence of this is that the
configuration-specific :prop_tgt:`IMPORTED_OBJECTS_<CONFIG>` properties cannot
be used, since CMake cannot determine whether an object file exists at a
particular ``<CONFIG>`` location.  The ``IMPORTED_OBJECTS`` property must be
used for these situations and the configuration-specific aspects of the path
should be handled by the ``$(CONFIGURATION)`` Xcode variable.


code:
IMPORTED_OBJECTS_<CONFIG>
-------------------------

.. versionadded:: 3.9

``<CONFIG>``-specific version of :prop_tgt:`IMPORTED_OBJECTS` property.

Configuration names correspond to those provided by the project from
which the target is imported.

Xcode Generator Considerations
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Do not use this ``<CONFIG>``-specific property if you need to use Xcode
variables like ``$(CURRENT_ARCH)`` or ``$(EFFECTIVE_PLATFORM_NAME)`` in
the value.  The ``<CONFIG>``-specific properties will be ignored in such
cases because CMake cannot determine whether a file exists at the
configuration-specific path at configuration time.  For such cases, use
:prop_tgt:`IMPORTED_OBJECTS` instead.


code:
IMPORTED_SONAME
---------------

The ``soname`` of an ``IMPORTED`` target of shared library type.

Set this to the ``soname`` embedded in an imported shared library.  This
is meaningful only on platforms supporting the feature.  Ignored for
non-imported targets.


code:
IMPORTED_SONAME_<CONFIG>
------------------------

<CONFIG>-specific version of :prop_tgt:`IMPORTED_SONAME` property.

Configuration names correspond to those provided by the project from
which the target is imported.


code:
IMPORT_PREFIX
-------------

What comes before the import library name.

Similar to the target property :prop_tgt:`PREFIX`, but used for import libraries
(typically corresponding to a ``DLL``) instead of regular libraries.  A
target property that can be set to override the prefix (such as ``lib``)
on an import library name.


code:
IMPORT_SUFFIX
-------------

What comes after the import library name.

Similar to the target property :prop_tgt:`SUFFIX`, but used
for import libraries (typically corresponding to a ``DLL``) instead of
regular libraries.  A target property that can be set to override
the suffix (such as ``.lib``) on an import library name.


code:
INCLUDE_DIRECTORIES
-------------------

List of preprocessor include file search directories.

This property specifies the list of directories given so far to the
:command:`target_include_directories` command.  In addition to accepting
values from that command, values may be set directly on any
target using the :command:`set_property` command.  A target gets its
initial value for this property from the value of the
:prop_dir:`INCLUDE_DIRECTORIES` directory property.  Both directory and
target property values are adjusted by calls to the
:command:`include_directories` command.

The value of this property is used by the generators to set the include
paths for the compiler.

Relative paths should not be added to this property directly. Use one of
the commands above instead to handle relative paths.

Contents of ``INCLUDE_DIRECTORIES`` may use :manual:`cmake-generator-expressions(7)` 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:
INSTALL_NAME_DIR
----------------

Directory name for installed targets on Apple platforms.

``INSTALL_NAME_DIR`` is a string specifying the directory portion of the
"install_name" field of shared libraries on Apple platforms for
installed targets.  When not set, the default directory used is determined
by :prop_tgt:`MACOSX_RPATH`.  If the :prop_tgt:`BUILD_WITH_INSTALL_NAME_DIR`
property is set, this will be used already in the build tree.
Policies :policy:`CMP0068` and :policy:`CMP0042` are also relevant.

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

This property supports :manual:`generator expressions <cmake-generator-expressions(7)>`.
In particular, the :genex:`$<INSTALL_PREFIX>` generator expression can be
used to set the directory relative to the install-time prefix.

On platforms that support runtime paths (``RPATH``), refer to the
:prop_tgt:`INSTALL_RPATH` target property.
Under Windows, the :genex:`TARGET_RUNTIME_DLLS` generator expression is related.


code:
INSTALL_REMOVE_ENVIRONMENT_RPATH
--------------------------------

.. versionadded:: 3.16

Controls whether toolchain-defined rpaths should be removed during installation.

When a target is being installed, CMake may need to rewrite its rpath
information.  This occurs when the install rpath (as specified by the
:prop_tgt:`INSTALL_RPATH` target property) has different contents to the rpath
that the target was built with.  Some toolchains insert their own rpath
contents into the binary as part of the build.  By default, CMake will
preserve those extra inserted contents in the install rpath.  For those
scenarios where such toolchain-inserted entries need to be discarded during
install, set the ``INSTALL_REMOVE_ENVIRONMENT_RPATH`` target property to true.

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


code:
INSTALL_RPATH
-------------

The rpath to use for installed targets.

By default, the install rpath is empty. It can be set using this property,
which is a semicolon-separated list specifying the rpath to use in installed
targets (for platforms that support it).  This property is initialized
by the value of the variable :variable:`CMAKE_INSTALL_RPATH` if it is set
when a target is created.
Beside setting the install rpath manually, using the
:prop_tgt:`INSTALL_RPATH_USE_LINK_PATH` target property it can also be
generated automatically by CMake.

Normally CMake uses the build tree for the RPATH when building executables
etc on systems that use RPATH, see the :prop_tgt:`BUILD_RPATH` target
property. When the software is installed
the targets are edited (or relinked) by CMake (see
:variable:`CMAKE_NO_BUILTIN_CHRPATH`) to have the install RPATH.
This editing during installation can be avoided via
the :prop_tgt:`BUILD_WITH_INSTALL_RPATH` target property.

For handling toolchain-dependent RPATH entries the
:prop_tgt:`INSTALL_REMOVE_ENVIRONMENT_RPATH` can be used.
Runtime paths can be disabled completely via the :variable:`CMAKE_SKIP_RPATH`
variable.

Because the rpath may contain ``${ORIGIN}``, which coincides with CMake syntax,
the contents of ``INSTALL_RPATH`` are properly escaped in the
``cmake_install.cmake`` script (see policy :policy:`CMP0095`.)

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

On Apple platforms, refer to the :prop_tgt:`INSTALL_NAME_DIR` target property.
Under Windows, the :genex:`TARGET_RUNTIME_DLLS` generator expression is related.


code:
INSTALL_RPATH_USE_LINK_PATH
---------------------------

Add paths to linker search and installed rpath.

``INSTALL_RPATH_USE_LINK_PATH`` is a boolean that if set to ``TRUE``
will append to the runtime search path (rpath) of installed binaries
any directories outside the project that are in the linker search path or
contain linked library files.  The directories are appended after the
value of the :prop_tgt:`INSTALL_RPATH` target property.

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


code:
INTERFACE_AUTOMOC_MACRO_NAMES
-----------------------------

.. versionadded:: 3.27

A :ref:`semicolon-separated list <CMake Language Lists>` of macro names for
:prop_tgt:`AUTOMOC` to be propagated to consumers.

When a target with :prop_tgt:`AUTOMOC` enabled links to a library that sets
``INTERFACE_AUTOMOC_MACRO_NAMES``, the target inherits the listed macro names
and merges them with those specified in its own :prop_tgt:`AUTOMOC_MACRO_NAMES`
property.  The target will then automatically generate MOC files for source
files that contain the inherited macro names too, not just the macro names
specified in its own :prop_tgt:`AUTOMOC_MACRO_NAMES` property.

By default ``INTERFACE_AUTOMOC_MACRO_NAMES`` is empty.

See the :manual:`cmake-qt(7)` manual for more information on using CMake
with Qt.

Example 1
^^^^^^^^^

In this example, ``myapp`` inherits the macro names ``STATIC_LIB_1`` and
``STATIC_LIB_2`` from ``static_lib``.  The ``moc`` tool will then automatically
be run on any of the ``myapp`` sources which contain ``STATIC_LIB_1`` or
``STATIC_LIB_2``.

.. code-block:: cmake

  set(AUTOMOC ON)
  add_executable(myapp main.cpp)
  target_link_libraries(myapp PRIVATE static_lib)

  add_library(static_lib STATIC static.cpp)
  set_property(TARGET static_lib PROPERTY
    INTERFACE_AUTOMOC_MACRO_NAMES "STATIC_LIB_1;STATIC_LIB_2"
  )

Example 2
^^^^^^^^^

In this example, the ``INTERFACE_AUTOMOC_MACRO_NAMES`` target property of the
various ``*_deep_lib`` libraries will propagate to ``shared_lib``,
``static_lib`` and ``interface_lib``.  Because the linking relationships are
specified as ``PUBLIC`` and ``INTERFACE``, those macro names will also further
propagate transitively up to ``app``.

.. code-block:: cmake

  set(AUTOMOC ON)

  add_library(shared_deep_lib SHARED deep_lib.cpp)
  add_library(static_deep_lib STATIC deep_lib.cpp)
  add_library(interface_deep_lib INTERFACE)

  set_property(TARGET shared_deep_lib PROPERTY
    INTERFACE_AUTOMOC_MACRO_NAMES "SHARED_LINK_LIB"
  )
  set_property(TARGET static_deep_lib PROPERTY
    INTERFACE_AUTOMOC_MACRO_NAMES "STATIC_LINK_LIB"
  )
  set_property(TARGET interface_deep_lib PROPERTY
    INTERFACE_AUTOMOC_MACRO_NAMES "INTERFACE_LINK_LIB"
  )

  add_library(shared_lib SHARED lib.cpp)
  add_library(static_lib STATIC lib.cpp)
  add_library(interface_lib INTERFACE)

  # PUBLIC and INTERFACE here ensure the macro names propagate to any
  # consumers of shared_lib, static_lib or interface_lib too
  target_link_libraries(shared_lib PUBLIC shared_deep_lib)
  target_link_libraries(static_lib PUBLIC static_deep_lib)
  target_link_libraries(interface_lib INTERFACE interface_deep_lib)

  # This consumer will receive all three of the above custom macro names as
  # transitive usage requirements
  add_executable(app main.cpp)
  target_link_libraries(app PRIVATE shared_lib static_lib interface_lib)

In the above:

* ``shared_lib`` sources will be processed by ``moc`` if they contain
  ``SHARED_LINK_LIB``.
* ``static_lib`` sources will be processed by ``moc`` if they contain
  ``STATIC_LINK_LIB``.
* ``app`` sources will be processed by ``moc`` if they contain
  ``SHARED_LINK_LIB``, ``STATIC_LINK_LIB`` or ``INTERFACE_LINK_LIB``.


code:
INTERFACE_AUTOUIC_OPTIONS
-------------------------

List of interface options to pass to uic.

Targets may populate this property to publish the options
required to use when invoking ``uic``.  Consuming targets can add entries to their
own :prop_tgt:`AUTOUIC_OPTIONS` property such as
``$<TARGET_PROPERTY:foo,INTERFACE_AUTOUIC_OPTIONS>`` to use the uic options
specified in the interface of ``foo``. This is done automatically by
the :command:`target_link_libraries` command.

This property supports generator expressions.  See the
:manual:`cmake-generator-expressions(7)` manual for available expressions.


code:
INTERFACE_COMPILE_DEFINITIONS
-----------------------------

.. |property_name| replace:: compile definitions
.. |command_name| replace:: :command:`target_compile_definitions`
.. |PROPERTY_INTERFACE_NAME| replace:: ``INTERFACE_COMPILE_DEFINITIONS``
.. |PROPERTY_LINK| replace:: :prop_tgt:`COMPILE_DEFINITIONS`
.. include:: INTERFACE_BUILD_PROPERTY.txt


code:
INTERFACE_COMPILE_FEATURES
--------------------------

.. versionadded:: 3.1

.. |property_name| replace:: compile features
.. |command_name| replace:: :command:`target_compile_features`
.. |PROPERTY_INTERFACE_NAME| replace:: ``INTERFACE_COMPILE_FEATURES``
.. |PROPERTY_LINK| replace:: :prop_tgt:`COMPILE_FEATURES`
.. include:: INTERFACE_BUILD_PROPERTY.txt

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


code:
INTERFACE_COMPILE_OPTIONS
-------------------------

.. |property_name| replace:: compile options
.. |command_name| replace:: :command:`target_compile_options`
.. |PROPERTY_INTERFACE_NAME| replace:: ``INTERFACE_COMPILE_OPTIONS``
.. |PROPERTY_LINK| replace:: :prop_tgt:`COMPILE_OPTIONS`
.. include:: INTERFACE_BUILD_PROPERTY.txt


code:
INTERFACE_CXX_MODULE_SETS
-------------------------

.. versionadded:: 3.28

Read-only list of the target's ``PUBLIC`` C++ module sets (i.e. all file sets
with the type ``CXX_MODULES``). Files listed in these C++ module sets can be
installed with :command:`install(TARGETS)` and exported with
:command:`install(EXPORT)` and :command:`export`.

C++ module sets may be defined using the :command:`target_sources` command
``FILE_SET`` option with type ``CXX_MODULES``.

See also :prop_tgt:`CXX_MODULE_SETS`.


code:
INTERFACE_HEADER_SETS
---------------------

.. versionadded:: 3.23

Read-only list of the target's ``INTERFACE`` and ``PUBLIC`` header sets (i.e.
all file sets with the type ``HEADERS``). Files listed in these header sets
can be installed with :command:`install(TARGETS)` and exported with
:command:`install(EXPORT)` and :command:`export`.

Header sets may be defined using the :command:`target_sources` command
``FILE_SET`` option with type ``HEADERS``.

See also :prop_tgt:`HEADER_SETS`.


code:
INTERFACE_HEADER_SETS_TO_VERIFY
-------------------------------

.. versionadded:: 3.24

Used to specify which ``PUBLIC`` and ``INTERFACE`` header sets of a target
should be verified.

This property contains a semicolon-separated list of header sets which
should be verified if :prop_tgt:`VERIFY_INTERFACE_HEADER_SETS` is set to
``TRUE``. If the list is empty, all ``PUBLIC`` and ``INTERFACE`` header sets
are verified. (If the project does not want to verify any header sets on the
target, simply set :prop_tgt:`VERIFY_INTERFACE_HEADER_SETS` to ``FALSE``.)


code:
INTERFACE_INCLUDE_DIRECTORIES
-----------------------------

.. |property_name| replace:: include directories
.. |command_name| replace:: :command:`target_include_directories`
.. |PROPERTY_INTERFACE_NAME| replace:: ``INTERFACE_INCLUDE_DIRECTORIES``
.. |PROPERTY_LINK| replace:: :prop_tgt:`INCLUDE_DIRECTORIES`
.. include:: INTERFACE_BUILD_PROPERTY.txt

Include directories usage requirements commonly differ between the build-tree
and the install-tree.  The ``BUILD_INTERFACE`` and ``INSTALL_INTERFACE``
generator expressions can be used to describe separate usage requirements
based on the usage location.  Relative paths are allowed within the
``INSTALL_INTERFACE`` expression and are interpreted relative to the
installation prefix.  For example:

.. code-block:: cmake

  target_include_directories(mylib INTERFACE
    $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include/mylib>
    $<INSTALL_INTERFACE:include/mylib>  # <prefix>/include/mylib
  )

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

.. |INTERFACE_PROPERTY_LINK| replace:: ``INTERFACE_INCLUDE_DIRECTORIES``
.. include:: /include/INTERFACE_INCLUDE_DIRECTORIES_WARNING.txt


code:
INTERFACE_LINK_DEPENDS
----------------------

.. versionadded:: 3.13

Additional public interface files on which a target binary depends for linking.

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.

When target dependencies are specified using :command:`target_link_libraries`,
CMake will read this property from all target dependencies to determine the
build properties of the consumer.

Contents of ``INTERFACE_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.

Link dependency files usage requirements commonly differ between the build-tree
and the install-tree.  The ``BUILD_INTERFACE`` and ``INSTALL_INTERFACE``
generator expressions can be used to describe separate usage requirements
based on the usage location.  Relative paths are allowed within the
``INSTALL_INTERFACE`` expression and are interpreted relative to the
installation prefix.  For example:

.. code-block:: cmake

  set_property(TARGET mylib PROPERTY INTERFACE_LINK_DEPENDS
    $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/mylinkscript>
    $<INSTALL_INTERFACE:mylinkscript>  # <prefix>/mylinkscript
  )


code:
INTERFACE_LINK_DIRECTORIES
--------------------------

.. versionadded:: 3.13

.. |property_name| replace:: link directories
.. |command_name| replace:: :command:`target_link_directories`
.. |PROPERTY_INTERFACE_NAME| replace:: ``INTERFACE_LINK_DIRECTORIES``
.. |PROPERTY_LINK| replace:: :prop_tgt:`LINK_DIRECTORIES`
.. include:: INTERFACE_BUILD_PROPERTY.txt


code:
INTERFACE_LINK_LIBRARIES
------------------------

List public interface libraries for a library.

This property contains the list of transitive link dependencies.  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.  This property is overridden by the
:prop_tgt:`LINK_INTERFACE_LIBRARIES` or
:prop_tgt:`LINK_INTERFACE_LIBRARIES_<CONFIG>` property if policy
:policy:`CMP0022` is ``OLD`` or unset.

The value of this property is used by the generators when constructing
the link rule for a dependent target.  A dependent target's direct
link dependencies, specified by its :prop_tgt:`LINK_LIBRARIES` target
property, are linked first, followed by indirect dependencies from the
transitive closure of the direct dependencies'
``INTERFACE_LINK_LIBRARIES`` properties.  See policy :policy:`CMP0022`.

Contents of ``INTERFACE_LINK_LIBRARIES`` 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.

.. include:: LINK_LIBRARIES_INDIRECTION.txt

``INTERFACE_LINK_LIBRARIES`` adds transitive link dependencies for a
target's dependents.  In advanced use cases, one may update the
direct link dependencies of a target's dependents by using the
:prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT` and
:prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE` target properties.

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

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


code:
INTERFACE_LINK_LIBRARIES_DIRECT
-------------------------------

.. versionadded:: 3.24

List of libraries that consumers of this library should treat
as direct link dependencies.

This target property may be set to *include* items in a dependent
target's final set of direct link dependencies.  See the
:prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE` target property
to exclude items.

The initial set of a dependent target's direct link dependencies is
specified by its :prop_tgt:`LINK_LIBRARIES` target property.  Indirect
link dependencies are specified by the transitive closure of the direct
link dependencies' :prop_tgt:`INTERFACE_LINK_LIBRARIES` properties.
Any link dependency may specify additional direct link dependencies
using the ``INTERFACE_LINK_LIBRARIES_DIRECT`` target property.
The set of direct link dependencies is then filtered to exclude items named
by any dependency's :prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE`
target property.

.. |INTERFACE_PROPERTY_LINK_DIRECT| replace:: ``INTERFACE_LINK_LIBRARIES_DIRECT``
.. include:: INTERFACE_LINK_LIBRARIES_DIRECT.txt

Direct Link Dependencies as Usage Requirements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The ``INTERFACE_LINK_LIBRARIES_DIRECT`` and
``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE`` target properties
are :ref:`usage requirements <Target Usage Requirements>`.
Their effects propagate to dependent targets transitively, and can
therefore affect the direct link dependencies of every target in a
chain of dependent libraries.  Whenever some library target ``X`` links
to another library target ``Y`` whose direct or transitive usage
requirements contain ``INTERFACE_LINK_LIBRARIES_DIRECT`` or
``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE``, the properties may affect
``X``'s list of direct link dependencies:

* If ``X`` is a shared library or executable, its dependencies are linked.
  They also affect the usage requirements with which ``X``'s sources are
  compiled.

* If ``X`` is a static library or object library, it does not actually
  link, so its dependencies at most affect the usage requirements with
  which ``X``'s sources are compiled.

The properties may also affect the list of direct link dependencies
on ``X``'s dependents:

* If ``X`` links ``Y`` publicly:

  .. code-block:: cmake

    target_link_libraries(X PUBLIC Y)

  then ``Y`` is placed in ``X``'s :prop_tgt:`INTERFACE_LINK_LIBRARIES`,
  so ``Y``'s usage requirements, including ``INTERFACE_LINK_LIBRARIES_DIRECT``,
  ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE``, and the usage requirements
  declared by the direct link dependencies they add, are propagated to
  ``X``'s dependents.

* If ``X`` is a static library or object library, and links ``Y`` privately:

  .. code-block:: cmake

    target_link_libraries(X PRIVATE Y)

  then ``$<LINK_ONLY:Y>`` is placed in ``X``'s
  :prop_tgt:`INTERFACE_LINK_LIBRARIES`.  ``Y``'s linking requirements,
  including ``INTERFACE_LINK_LIBRARIES_DIRECT``,
  ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE``, and the transitive link
  dependencies declared by the direct link dependencies they add, are
  propagated to ``X``'s dependents.  However, ``Y``'s non-linking
  usage requirements are blocked by the :genex:`LINK_ONLY` generator
  expression, and are not propagated to ``X``'s dependents.

* If ``X`` is a shared library or executable, and links ``Y`` privately:

  .. code-block:: cmake

    target_link_libraries(X PRIVATE Y)

  then ``Y`` is not placed in ``X``'s :prop_tgt:`INTERFACE_LINK_LIBRARIES`,
  so ``Y``'s usage requirements, even ``INTERFACE_LINK_LIBRARIES_DIRECT``
  and ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE``, are not propagated to
  ``X``'s dependents.

* In all cases, the content of ``X``'s :prop_tgt:`INTERFACE_LINK_LIBRARIES`
  is not affected by ``Y``'s ``INTERFACE_LINK_LIBRARIES_DIRECT`` or
  ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE``.

One may limit the effects of ``INTERFACE_LINK_LIBRARIES_DIRECT`` and
``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE`` to a subset of dependent
targets by using the :genex:`TARGET_PROPERTY` generator expression.
For example, to limit the effects to executable targets, use an
entry of the form::

  "$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,EXECUTABLE>:...>"

Similarly, to limit the effects to specific targets, use an entry
of the form::

  "$<$<BOOL:$<TARGET_PROPERTY:USE_IT>>:...>"

This entry will only affect targets that set their ``USE_IT``
target property to a true value.

Direct Link Dependency Ordering
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The list of direct link dependencies for a target is computed from an
initial ordered list in its :prop_tgt:`LINK_LIBRARIES` target property.
For each item, additional direct link dependencies are discovered from
its direct and transitive ``INTERFACE_LINK_LIBRARIES_DIRECT`` usage
requirements.  Each discovered item is injected before the item that
specified it.  However, a discovered item is added at most once,
and only if it did not appear anywhere in the initial list.
This gives :prop_tgt:`LINK_LIBRARIES` control over ordering of
those direct link dependencies that it explicitly specifies.

Once all direct link dependencies have been collected, items named by
all of their :prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE`
usage requirements are removed from the final list.  This does not
affect the order of the items that remain.

Example: Static Plugins
^^^^^^^^^^^^^^^^^^^^^^^

Consider a static library ``Foo`` that provides a static plugin
``FooPlugin`` to consuming application executables, where the
implementation of the plugin depends on ``Foo`` and other things.
In this case, the application should link to ``FooPlugin`` directly,
before ``Foo``.  However, the application author only knows about ``Foo``.
We can express this as follows:

.. code-block:: cmake

  # Core library used by other components.
  add_library(Core STATIC core.cpp)

  # Foo is a static library for use by applications.
  # Implementation of Foo depends on Core.
  add_library(Foo STATIC foo.cpp foo_plugin_helper.cpp)
  target_link_libraries(Foo PRIVATE Core)

  # Extra parts of Foo for use by its static plugins.
  # Implementation of Foo's extra parts depends on both Core and Foo.
  add_library(FooExtras STATIC foo_extras.cpp)
  target_link_libraries(FooExtras PRIVATE Core Foo)

  # The Foo library has an associated static plugin
  # that should be linked into the final executable.
  # Implementation of the plugin depends on Core, Foo, and FooExtras.
  add_library(FooPlugin STATIC foo_plugin.cpp)
  target_link_libraries(FooPlugin PRIVATE Core Foo FooExtras)

  # An app that links Foo should link Foo's plugin directly.
  set_property(TARGET Foo PROPERTY INTERFACE_LINK_LIBRARIES_DIRECT FooPlugin)

  # An app does not need to link Foo directly because the plugin links it.
  set_property(TARGET Foo PROPERTY INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE Foo)

An application ``app`` only needs to specify that it links to ``Foo``:

.. code-block:: cmake

  add_executable(app main.cpp)
  target_link_libraries(app PRIVATE Foo)

The ``INTERFACE_LINK_LIBRARIES_DIRECT`` target property on ``Foo`` tells
CMake to pretend that ``app`` also links directly to ``FooPlugin``.
The ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE`` target property on ``Foo``
tells CMake to pretend that ``app`` did *not* link directly to ``Foo``.
Instead, ``Foo`` will be linked as a dependency of ``FooPlugin``.  The
final link line for ``app`` will link the libraries in the following
order:

* ``FooPlugin`` as a direct link dependency of ``app``
  (via ``Foo``'s usage requirements).
* ``FooExtras`` as a dependency of ``FooPlugin``.
* ``Foo`` as a dependency of ``FooPlugin`` and ``FooExtras``.
* ``Core`` as a dependency of ``FooPlugin``, ``FooExtras``, and ``Foo``.

Note that without the ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE`` target
property, ``Foo`` would be linked twice: once as a direct dependency
of ``app``, and once as a dependency of ``FooPlugin``.

Example: Opt-In Static Plugins
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In the above `Example: Static Plugins`_, the ``app`` executable specifies
that it links directly to ``Foo``.  In a real application, there might
be an intermediate library:

.. code-block:: cmake

  add_library(app_impl STATIC app_impl.cpp)
  target_link_libraries(app_impl PRIVATE Foo)

  add_executable(app main.cpp)
  target_link_libraries(app PRIVATE app_impl)

In this case we do not want ``Foo``'s ``INTERFACE_LINK_LIBRARIES_DIRECT``
and ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE`` target properties to affect
the direct dependencies of ``app_impl``.  To avoid this, we can revise
the property values to make their effects opt-in:

.. code-block:: cmake

  # An app that links Foo should link Foo's plugin directly.
  set_property(TARGET Foo PROPERTY INTERFACE_LINK_LIBRARIES_DIRECT
    "$<$<BOOL:$<TARGET_PROPERTY:FOO_STATIC_PLUGINS>>:FooPlugin>"
  )

  # An app does not need to link Foo directly because the plugin links it.
  set_property(TARGET Foo PROPERTY INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE
    "$<$<BOOL:$<TARGET_PROPERTY:FOO_STATIC_PLUGINS>>:Foo>"
  )

Now, the ``app`` executable can opt-in to get ``Foo``'s plugin(s):

.. code-block:: cmake

  set_property(TARGET app PROPERTY FOO_STATIC_PLUGINS 1)

The final link line for ``app`` will now link the libraries in the following
order:

* ``FooPlugin`` as a direct link dependency of ``app``
  (via ``Foo``'s usage requirements).
* ``app_impl`` as a direct link dependency of ``app``.
* ``FooExtras`` as a dependency of ``FooPlugin``.
* ``Foo`` as a dependency of ``app_impl``, ``FooPlugin``, and ``FooExtras``.
* ``Core`` as a dependency of ``FooPlugin``, ``FooExtras``, and ``Foo``.


code:
INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE
---------------------------------------

.. versionadded:: 3.24

List of libraries that consumers of this library should *not* treat
as direct link dependencies.

This target property may be set to *exclude* items from a dependent
target's final set of direct link dependencies.  This property is
processed after the :prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT`
target property of all other dependencies of the dependent target, so
exclusion from direct link dependence takes priority over inclusion.

The initial set of a dependent target's direct link dependencies is
specified by its :prop_tgt:`LINK_LIBRARIES` target property.  Indirect
link dependencies are specified by the transitive closure of the direct
link dependencies' :prop_tgt:`INTERFACE_LINK_LIBRARIES` properties.
Any link dependency may specify additional direct link dependencies
using the :prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT` target property.
The set of direct link dependencies is then filtered to exclude items named
by any dependency's ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE`` target
property.

Excluding an item from a dependent target's direct link dependencies
does not mean the dependent target won't link the item.  The item
may still be linked as an indirect link dependency via the
:prop_tgt:`INTERFACE_LINK_LIBRARIES` property on other dependencies.

.. |INTERFACE_PROPERTY_LINK_DIRECT| replace:: ``INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE``
.. include:: INTERFACE_LINK_LIBRARIES_DIRECT.txt

See the :prop_tgt:`INTERFACE_LINK_LIBRARIES_DIRECT` target property
documentation for more details and examples.


code:
INTERFACE_LINK_OPTIONS
----------------------

.. versionadded:: 3.13

.. |property_name| replace:: link options
.. |command_name| replace:: :command:`target_link_options`
.. |PROPERTY_INTERFACE_NAME| replace:: ``INTERFACE_LINK_OPTIONS``
.. |PROPERTY_LINK| replace:: :prop_tgt:`LINK_OPTIONS`
.. include:: INTERFACE_BUILD_PROPERTY.txt


code:
INTERFACE_POSITION_INDEPENDENT_CODE
-----------------------------------

Whether consumers need to create a position-independent target

The ``INTERFACE_POSITION_INDEPENDENT_CODE`` property informs consumers of
this target whether they must set their
:prop_tgt:`POSITION_INDEPENDENT_CODE` property to ``ON``.  If this
property is set to ``ON``, then the :prop_tgt:`POSITION_INDEPENDENT_CODE`
property on  all consumers will be set to ``ON``. Similarly, if this
property is set to ``OFF``, then the :prop_tgt:`POSITION_INDEPENDENT_CODE`
property on all consumers will be set to ``OFF``.  If this property is
undefined, then consumers will determine their
:prop_tgt:`POSITION_INDEPENDENT_CODE` property by other means.  Consumers
must ensure that the targets that they link to have a consistent
requirement for their ``INTERFACE_POSITION_INDEPENDENT_CODE`` property.

Contents of ``INTERFACE_POSITION_INDEPENDENT_CODE`` 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:
INTERFACE_PRECOMPILE_HEADERS
----------------------------

.. versionadded:: 3.16

List of interface header files to precompile into consuming targets.

Targets may populate this property to publish the header files
for consuming targets to precompile.  The :command:`target_precompile_headers`
command populates this property with values given to the ``PUBLIC`` and
``INTERFACE`` keywords.  Projects may also get and set the property directly.
See the discussion in :command:`target_precompile_headers` for guidance on
appropriate use of this property for installed or exported targets.

Contents of ``INTERFACE_PRECOMPILE_HEADERS`` 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:
INTERFACE_SOURCES
-----------------

.. versionadded:: 3.1

List of interface sources to compile into consuming targets.

Targets may populate this property to publish the sources
for consuming targets to compile.  The :command:`target_sources` command
populates this property with values given to the ``PUBLIC`` and
``INTERFACE`` keywords.  Projects may also get and set the property directly.

When target dependencies are specified using :command:`target_link_libraries`,
CMake will read this property from all target dependencies to determine the
sources of the consumer.

Contents of ``INTERFACE_SOURCES`` 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:
INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
------------------------------------

List of public system include directories for a library.

Targets may populate this property to publish the include directories
which contain system headers, and therefore should not result in
compiler warnings.  Additionally, system include directories are searched
after normal include directories regardless of the order specified.

When the :command:`target_include_directories` command is given the
``SYSTEM`` keyword, it populates this property with values provided after the
``PUBLIC`` and ``INTERFACE`` keywords.

Projects may also get and set the property directly, but must be aware that
adding directories to this property does not make those directories used
during compilation.  Adding directories to this property marks directories
as system directories which otherwise would be used in a non-system manner.
This can appear similar to duplication, so prefer the high-level
:command:`target_include_directories` command with the ``SYSTEM`` keyword
and avoid setting the property directly.

When target dependencies are specified using :command:`target_link_libraries`,
CMake will read this property from all target dependencies to mark the
same include directories as containing system headers.

Contents of ``INTERFACE_SYSTEM_INCLUDE_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:
INTERPROCEDURAL_OPTIMIZATION
----------------------------

Enable interprocedural optimization for a target.

If set to true, enables interprocedural optimizations if they are
known :module:`to be supported <CheckIPOSupported>` by the compiler. Depending
on value of policy :policy:`CMP0069`, the error will be reported or ignored,
if interprocedural optimization is enabled but not supported.

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

There is also the per-configuration :prop_tgt:`INTERPROCEDURAL_OPTIMIZATION_<CONFIG>`
target property, which overrides :prop_tgt:`INTERPROCEDURAL_OPTIMIZATION`
if it is set.


code:
INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
-------------------------------------

Per-configuration interprocedural optimization for a target.

This is a per-configuration version of :prop_tgt:`INTERPROCEDURAL_OPTIMIZATION`.
If set, this property overrides the generic property for the named
configuration.

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


code:
IOS_INSTALL_COMBINED
--------------------

.. versionadded:: 3.5
.. deprecated:: 3.28

  :prop_tgt:`IOS_INSTALL_COMBINED` was designed to make universal binaries
  containing iOS/arm* device code paired with iOS Simulator/x86_64 code
  (or similar for other Apple embedded platforms). Universal binaries can only
  differentiate code based on CPU type, so this only made sense before the
  days of arm64 macOS machines (i.e. iOS Simulator/arm64). Apple now
  recommends xcframeworks, which contain multiple binaries for different
  platforms, for this use case.

Build a combined (device and simulator) target when installing.

When this property is set to false, which is the default, then it will
either be built with the device SDK or the simulator SDK depending on the SDK
set. But if this property is set to true then the target will at install time
also be built for the other SDK and combined into one library.

.. note::

  If a selected architecture is available for both device SDK and simulator
  SDK it will be built for the SDK selected by :variable:`CMAKE_OSX_SYSROOT`
  and removed from the other SDK.

This feature requires at least Xcode version 6.


code:
ISPC_HEADER_DIRECTORY
---------------------

.. versionadded:: 3.19

Specify relative output directory for ISPC headers provided by the target.

If the target contains ISPC source files, this specifies the directory in which
the generated headers will be placed. Relative paths are treated with respect to
the value of :variable:`CMAKE_CURRENT_BINARY_DIR`. When this property is not set, the
headers will be placed a generator defined build directory. If the variable
:variable:`CMAKE_ISPC_HEADER_DIRECTORY` is set when a target is created
its value is used to initialize this property.


code:
ISPC_HEADER_SUFFIX
------------------

.. versionadded:: 3.19.2

Specify output suffix to be used for ISPC generated headers provided by the target.

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

If the target contains ISPC source files, this specifies the header suffix to
be used for the generated headers.

The default value is ``_ispc.h``.


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


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