code:
LOCATION
--------

Read-only location of a target on disk.

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

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

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


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

Read-only property providing a target location on disk.

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

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

repo_name: lazytadpole/codenamesilverfish

license: mit


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

.. versionadded:: 3.17

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

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

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

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


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

.. versionadded:: 3.17

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

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

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

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


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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

.. versionadded:: 3.8

Get manually added dependencies to other top-level targets.

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


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

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

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

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

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

Example
^^^^^^^

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

.. code-block:: cmake

  add_library(foo STATIC IMPORTED)

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

.. code-block:: cmake

  set_property(
    TARGET foo APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG
    )

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

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

.. code-block:: cmake

  set_property(
    TARGET foo APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE
    )

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

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

.. code-block:: cmake

  set_target_properties(foo PROPERTIES
    MAP_IMPORTED_CONFIG_MINSIZEREL Release
    MAP_IMPORTED_CONFIG_RELWITHDEBINFO Release
    )


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

.. versionadded:: 3.25

Select debug information format when targeting the MSVC ABI.

The allowed values are:

.. include:: MSVC_DEBUG_INFORMATION_FORMAT-VALUES.txt

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

.. code-block:: cmake

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

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

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

.. note::

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


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

.. versionadded:: 3.15

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

The allowed values are:

.. include:: MSVC_RUNTIME_LIBRARY-VALUES.txt

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

.. code-block:: cmake

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

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

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

.. note::

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


code:
NAME
----

Logical name for the target.

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


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

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

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


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

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

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

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

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

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


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

.. versionadded:: 3.16

Boolean specifying whether compiler specific extensions are requested.

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

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

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

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


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

.. versionadded:: 3.16

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

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

Supported values are:

``98``
  Objective C++98

``11``
  Objective C++11

``14``
  Objective C++14

``17``
  Objective C++17

``20``
  Objective C++20

``23``
  .. versionadded:: 3.20

  Objective C++23

``26``
  .. versionadded:: 3.25

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

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

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY OBJCXX_STANDARD 11)

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

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

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

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


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

.. versionadded:: 3.16

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

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

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

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

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


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

.. versionadded:: 3.16

Boolean specifying whether compiler specific extensions are requested.

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

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

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

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


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

.. versionadded:: 3.16

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

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

Supported values are:

``90``
  Objective C89/C90

``99``
  Objective C99

``11``
  Objective C11

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

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY OBJC_STANDARD 11)

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

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

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

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


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

.. versionadded:: 3.16

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

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

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

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

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


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

.. versionadded:: 3.19

Activates dependency optimization of static and object libraries.

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

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

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

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

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


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

Target specific architectures for macOS.

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


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

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

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


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

Output name for target files.

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

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

See also the variants:

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


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

Per-configuration target file base name.

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


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

.. versionadded:: 3.19

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

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


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

.. versionadded:: 3.18

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

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


code:
PDB_NAME
--------

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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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


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

Whether to create a position-independent target

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

.. note::

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


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

Deprecated install support.

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


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

.. versionadded:: 3.16

List of header files to precompile.

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

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


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

.. versionadded:: 3.16

Target from which to reuse the precompiled headers build artifact.

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


code:
PREFIX
------

What comes before the library name.

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


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

Deprecated install support.

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


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

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

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


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

Change the name of a target in an IDE.

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


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

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

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


code:
RESOURCE
--------

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

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

Following example of Application Bundle:

.. code-block:: cmake

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

  target_link_libraries(ExecutableTarget heymath mul)

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

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

will produce flat structure for iOS systems::

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

For macOS systems it will produce following directory structure::

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

For Linux, such CMake script produce following files::

  ExecutableTarget
  Resources
    appres.txt
    resourcefile.txt


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

Specify a launcher for compile rules.

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

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


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

Specify a launcher for custom rules.

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


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

Specify a launcher for link rules.

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

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


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

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

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


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

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

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

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


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

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

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


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

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

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


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

Should rpaths be used for the build tree.

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


code:
SOURCES
-------

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

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

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

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

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

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

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

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


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

.. versionadded:: 3.4

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


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

ABI version number of a shared library target.

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

.. include:: VERSION_SOVERSION_EXAMPLE.txt

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

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

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

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

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

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


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

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

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

.. note::

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


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

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

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

.. note::

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


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

.. versionadded:: 3.13

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

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

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

.. note::

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

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


code:
SUFFIX
------

What comes after the target name.

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


code:
SYSTEM
------

.. versionadded:: 3.25

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

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

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

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


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

.. versionadded:: 3.29

Specify how Swift compiles a target.

The allowed values are:

.. include:: Swift_COMPILATION_MODE-VALUES.txt

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

.. code-block:: cmake

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

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

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

.. note::

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


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

.. versionadded:: 3.15

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


code:
Swift_LANGUAGE_VERSION
----------------------

.. versionadded:: 3.16

This property sets the language version for the Swift sources in the target.  If
one is not specified, it will default to
:variable:`CMAKE_Swift_LANGUAGE_VERSION` if specified, otherwise it is the
latest version supported by the compiler.


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

.. versionadded:: 3.15

Specify output directory for Swift modules provided by the target.

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


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

.. versionadded:: 3.15

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


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

.. versionadded:: 3.29

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

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

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

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

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


code:
TYPE
----

The type of the target.

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


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

.. versionadded:: 3.16

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

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

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

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

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

Unity builds are supported for the following languages:

``C``
  .. versionadded:: 3.16

``CXX``
  .. versionadded:: 3.16

``OBJC``
  .. versionadded:: 3.29

``OBJCXX``
  .. versionadded:: 3.29

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

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

.. note::

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

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

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

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

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

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

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

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

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


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

.. versionadded:: 3.16

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

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

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

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


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

.. versionadded:: 3.16

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

.. code-block:: cmake

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

See also :prop_tgt:`UNITY_BUILD_CODE_BEFORE_INCLUDE`.


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

.. versionadded:: 3.16

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

.. code-block:: cmake

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

See also :prop_tgt:`UNITY_BUILD_CODE_AFTER_INCLUDE`.


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

.. versionadded:: 3.18

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

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

  Example usage:

  .. code-block:: cmake

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

    set_target_properties(example_library PROPERTIES
                          UNITY_BUILD_MODE BATCH
                          UNITY_BUILD_BATCH_SIZE 2
                          )

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

  Example usage:

  .. code-block:: cmake

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

    set_target_properties(example_library PROPERTIES
                          UNITY_BUILD_MODE GROUP
                          )

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

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


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

.. versionadded:: 3.20

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

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

Given:

.. code-block:: cmake

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

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

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

.. code-block:: cpp

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

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

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

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


code:
VERIFY_INTERFACE_HEADER_SETS
----------------------------

.. versionadded:: 3.24

Used to verify that all headers in a target's ``PUBLIC`` and ``INTERFACE``
header sets can be included on their own.

When this property is set to true, and the target is an object library, static
library, shared library, interface library, or executable with exports enabled,
and the target has one or more ``PUBLIC`` or ``INTERFACE`` header sets, an
object library target named ``<target_name>_verify_interface_header_sets`` is
created. This verification target has one source file per header in the
``PUBLIC`` and ``INTERFACE`` header sets. Each source file only includes its
associated header file. The verification target links against the original
target to get all of its usage requirements. The verification target has its
:prop_tgt:`EXCLUDE_FROM_ALL` and :prop_tgt:`DISABLE_PRECOMPILE_HEADERS`
properties set to true, and its :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTORCC`,
:prop_tgt:`AUTOUIC`, and :prop_tgt:`UNITY_BUILD` properties set to false.

If the header's :prop_sf:`LANGUAGE` property is set, the value of that property
is used to determine the language with which to compile the header file.
Otherwise, if the target has any C++ sources, the header is compiled as C++.
Otherwise, if the target has any C sources, the header is compiled as C.
Otherwise, if C++ is enabled globally, the header is compiled as C++.
Otherwise, if C is enabled globally, the header is compiled as C. Otherwise,
the header file is not compiled.

If the header's :prop_sf:`SKIP_LINTING` property is set to true, the file is
not compiled.

If any verification targets are created, a top-level target called
``all_verify_interface_header_sets`` is created which depends on all
verification targets.

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

If the project wishes to control which header sets are verified by this
property, it can set :prop_tgt:`INTERFACE_HEADER_SETS_TO_VERIFY`.


code:
VERSION
-------

Version number of a shared library target.

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

.. include:: VERSION_SOVERSION_EXAMPLE.txt

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

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

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

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

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

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


code:
VISIBILITY_INLINES_HIDDEN
-------------------------

Whether to add a compile flag to hide symbols of inline functions

The ``VISIBILITY_INLINES_HIDDEN`` property determines whether a flag for
hiding symbols for inline functions, such as ``-fvisibility-inlines-hidden``,
should be used when invoking the compiler.  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_VISIBILITY_INLINES_HIDDEN` variable if it
is set when a target is created.


code:
VS_CONFIGURATION_TYPE
---------------------

.. versionadded:: 3.6

Visual Studio project configuration type.

Sets the ``ConfigurationType`` attribute for a generated Visual Studio project.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
If this property is set, it overrides the default setting that is based on the
target type (e.g. ``StaticLibrary``, ``Application``, ...).

Supported on :ref:`Visual Studio Generators` for VS 2010 and higher.


code:
VS_DEBUGGER_COMMAND
-------------------

.. versionadded:: 3.12

Sets the local debugger command for Visual Studio C++ targets.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
This is defined in ``<LocalDebuggerCommand>`` in the Visual Studio
project file.  This property is initialized by the value of the variable
:variable:`CMAKE_VS_DEBUGGER_COMMAND` if it is set when a target is
created.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.


code:
VS_DEBUGGER_COMMAND_ARGUMENTS
-----------------------------

.. versionadded:: 3.13

Sets the local debugger command line arguments for Visual Studio C++ targets.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
This is defined in ``<LocalDebuggerCommandArguments>`` in the Visual Studio
project file.  This property is initialized by the value of the variable
:variable:`CMAKE_VS_DEBUGGER_COMMAND_ARGUMENTS` if it is set when a target is
created.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.


code:
VS_DEBUGGER_ENVIRONMENT
-----------------------

.. versionadded:: 3.13

Sets the local debugger environment for Visual Studio C++ targets.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
This is defined in ``<LocalDebuggerEnvironment>`` in the Visual Studio
project file.  This property is initialized by the value of the variable
:variable:`CMAKE_VS_DEBUGGER_ENVIRONMENT` if it is set when a target is
created.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.


code:
VS_DEBUGGER_WORKING_DIRECTORY
-----------------------------

.. versionadded:: 3.8

Sets the local debugger working directory for Visual Studio C++ targets.
The property value may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.
This is defined in ``<LocalDebuggerWorkingDirectory>`` in the Visual Studio
project file.  This property is initialized by the value of the variable
:variable:`CMAKE_VS_DEBUGGER_WORKING_DIRECTORY` if it is set when a target is
created.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.


code:
VS_DESKTOP_EXTENSIONS_VERSION
-----------------------------

.. versionadded:: 3.4

Visual Studio Windows 10 Desktop Extensions Version

Specifies the version of the Desktop Extensions that should be included in the
target. For example ``10.0.10240.0``. If the value is not specified, the Desktop
Extensions will not be included. To use the same version of the extensions as
the Windows 10 SDK that is being used, you can use the
:variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable.


code:
VS_DOTNET_DOCUMENTATION_FILE
----------------------------

.. versionadded:: 3.17

Visual Studio managed project .NET documentation output

Sets the target XML documentation file output.


code:
VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname>
-----------------------------------------------

.. versionadded:: 3.10

Defines an XML property ``<tagname>`` for a .NET reference
``<refname>``.

Reference properties can be set for .NET references which are
defined by the target properties :prop_tgt:`VS_DOTNET_REFERENCES`,
:prop_tgt:`VS_DOTNET_REFERENCE_<refname>`
and also for project references to other C# targets which are
established by :command:`target_link_libraries()`.

This property is only applicable to C# targets and Visual Studio
generators 2010 and later.


code:
VS_DOTNET_REFERENCES
--------------------

Visual Studio managed project .NET references

Adds one or more semicolon-delimited .NET references to a generated
Visual Studio project.  For example, "System;System.Windows.Forms".


code:
VS_DOTNET_REFERENCES_COPY_LOCAL
-------------------------------

.. versionadded:: 3.8

Sets the **Copy Local** property for all .NET hint references in the target

Boolean property to enable/disable copying of .NET hint references to
output directory. The default is ``ON``.


code:
VS_DOTNET_REFERENCE_<refname>
-----------------------------

.. versionadded:: 3.8

Visual Studio managed project .NET reference with name ``<refname>``
and hint path.

Adds one .NET reference to generated Visual Studio project. The
reference will have the name ``<refname>`` and will point to the
assembly given as value of the property.

See also :prop_tgt:`VS_DOTNET_REFERENCES` and
:prop_tgt:`VS_DOTNET_REFERENCES_COPY_LOCAL`


code:
VS_DOTNET_STARTUP_OBJECT
------------------------

.. versionadded:: 3.24

Sets the startup object property in Visual Studio .NET targets.
The property value defines a full qualified class name (including package
name), for example: ``MyCompany.Package.MyStarterClass``.

If the property is unset, Visual Studio uses the first matching
``static void Main(string[])`` function signature by default. When more
than one ``Main()`` method is available in the current project, the property
becomes mandatory for building the project.

This property only works for Visual Studio 12 2013 and above;
it is ignored on other generators.

.. code-block:: cmake

  set_property(TARGET ${TARGET_NAME} PROPERTY
    VS_DOTNET_STARTUP_OBJECT "MyCompany.Package.MyStarterClass")


code:
VS_DOTNET_TARGET_FRAMEWORK_VERSION
----------------------------------

Specify the .NET target framework version.

Used to specify the .NET target framework version for C++/CLI. For
example, "v4.5".

This property is deprecated and should not be used anymore. Use
:prop_tgt:`DOTNET_TARGET_FRAMEWORK` or
:prop_tgt:`DOTNET_TARGET_FRAMEWORK_VERSION` instead.


code:
VS_DPI_AWARE
------------

.. versionadded:: 3.16

Set the Manifest Tool -> Input and Output -> DPI Awareness in the Visual Studio
target project properties.

Valid values are ``PerMonitor``, ``ON``, or ``OFF``.

For example:

.. code-block:: cmake

  add_executable(myproject myproject.cpp)
  set_property(TARGET myproject PROPERTY VS_DPI_AWARE "PerMonitor")


code:
VS_GLOBAL_KEYWORD
-----------------

Visual Studio project keyword for VS 10 (2010) and newer.

Sets the "keyword" attribute for a generated Visual Studio project.
Defaults to "Win32Proj".  You may wish to override this value with
"ManagedCProj", for example, in a Visual Studio managed C++ unit test
project.

Use the :prop_tgt:`VS_KEYWORD` target property to set the
keyword for Visual Studio 9 (2008) and older.


code:
VS_GLOBAL_PROJECT_TYPES
-----------------------

Visual Studio project type(s).

Can be set to one or more UUIDs recognized by Visual Studio to
indicate the type of project.  This value is copied verbatim into the
generated project file.  Example for a managed C++ unit testing
project:

::

 {3AC096D0-A1C2-E12C-1390-A8335801FDAB};{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}

UUIDs are semicolon-delimited.


code:
VS_GLOBAL_ROOTNAMESPACE
-----------------------

Visual Studio project root namespace.

Sets the "RootNamespace" attribute for a generated Visual Studio
project.  The attribute will be generated only if this is set.


code:
VS_GLOBAL_<variable>
--------------------

Visual Studio project-specific global variable.

Tell the Visual Studio generator to set the global variable
'<variable>' to a given value in the generated Visual Studio project.
Ignored on other generators.  Qt integration works better if
VS_GLOBAL_QtVersion is set to the version FindQt4.cmake found.  For
example, "4.7.3"


code:
VS_IOT_EXTENSIONS_VERSION
-------------------------

.. versionadded:: 3.4

Visual Studio Windows 10 IoT Extensions Version

Specifies the version of the IoT Extensions that should be included in the
target. For example ``10.0.10240.0``. If the value is not specified, the IoT
Extensions will not be included. To use the same version of the extensions as
the Windows 10 SDK that is being used, you can use the
:variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable.


code:
VS_IOT_STARTUP_TASK
-------------------

.. versionadded:: 3.4

Visual Studio Windows 10 IoT Continuous Background Task

Specifies that the target should be compiled as a Continuous Background Task library.


code:
VS_JUST_MY_CODE_DEBUGGING
-------------------------

.. versionadded:: 3.15

Enable Just My Code with Visual Studio debugger.

Supported on :ref:`Visual Studio Generators` for VS 2010 and higher,
:ref:`Makefile Generators` and the :generator:`Ninja` generators.

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


code:
VS_KEYWORD
----------

Visual Studio project keyword for VS 9 (2008) and older.

Can be set to change the visual studio keyword, for example Qt
integration works better if this is set to Qt4VSv1.0.

Use the :prop_tgt:`VS_GLOBAL_KEYWORD` target property to set the
keyword for Visual Studio 12 (2013) and newer.


code:
VS_MOBILE_EXTENSIONS_VERSION
----------------------------

.. versionadded:: 3.4

Visual Studio Windows 10 Mobile Extensions Version

Specifies the version of the Mobile Extensions that should be included in the
target. For example ``10.0.10240.0``. If the value is not specified, the Mobile
Extensions will not be included. To use the same version of the extensions as
the Windows 10 SDK that is being used, you can use the
:variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable.


code:
VS_NO_COMPILE_BATCHING
----------------------

.. versionadded:: 3.24

Turn off compile batching for the target. Usually MSBuild calls the compiler
with multiple c/cpp files and compiler starts subprocesses for each file to
make the build parallel. If you want compiler to be invoked with one file at
a time set ``VS_NO_COMPILE_BATCHING`` to ON. If this flag is set MSBuild will
call compiler with one c/cpp file at a time. Useful when you want to use tool
that replaces the compiler, for example some build caching tool.

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

Example
^^^^^^^

This shows setting the property for the target ``foo``.

.. code-block:: cmake

  add_library(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_NO_COMPILE_BATCHING ON)


code:
VS_NO_SOLUTION_DEPLOY
---------------------

.. versionadded:: 3.15

Specify that the target should not be marked for deployment to a Windows CE
or Windows Phone device in the generated Visual Studio solution.

Be default, all EXE and shared library (DLL) targets are marked to deploy to
the target device in the generated Visual Studio solution.

Generator expressions are supported.

There are reasons one might want to exclude a target / generated project from
deployment:

- The library or executable may not be necessary in the primary deploy/debug
  scenario, and excluding from deployment saves time in the
  develop/download/debug cycle.
- There may be insufficient space on the target device to accommodate all of
  the build products.
- Visual Studio 2013 requires a target device IP address be entered for each
  target marked for deployment.  For large numbers of targets, this can be
  tedious.
  NOTE: Visual Studio *will* deploy all project dependencies of a project
  tagged for deployment to the IP address configured for that project even
  if those dependencies are not tagged for deployment.

Example 1
^^^^^^^^^

This shows setting the variable for the target foo.

.. code-block:: cmake

  add_library(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_NO_SOLUTION_DEPLOY ON)

Example 2
^^^^^^^^^

This shows setting the variable for the Release configuration only.

.. code-block:: cmake

  add_library(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_NO_SOLUTION_DEPLOY "$<CONFIG:Release>")


code:
VS_PACKAGE_REFERENCES
---------------------

.. versionadded:: 3.15

Visual Studio package references for nuget.

Adds one or more semicolon-delimited package references to a generated
Visual Studio project. The version of the package will be
underscore delimited. For example, ``boost_1.7.0;nunit_3.12.*``.

.. code-block:: cmake

  set_property(TARGET ${TARGET_NAME} PROPERTY
    VS_PACKAGE_REFERENCES "boost_1.7.0")


code:
VS_PLATFORM_TOOLSET
-------------------

.. versionadded:: 3.18

Overrides the platform toolset used to build a target.

Only supported when the compiler used by the given toolset is the
same as the compiler used to build the whole source tree.

This is especially useful to create driver projects with the toolsets
"WindowsUserModeDriver10.0" or "WindowsKernelModeDriver10.0".


code:
VS_PROJECT_IMPORT
-----------------

.. versionadded:: 3.15

Visual Studio managed project imports

Adds to a generated Visual Studio project one or more semicolon-delimited paths
to .props files needed when building projects from some NuGet packages.
For example, ``my_packages_path/MyPackage.1.0.0/build/MyPackage.props``.


code:
VS_SCC_AUXPATH
--------------

Visual Studio Source Code Control Aux Path.

Can be set to change the visual studio source code control auxpath
property.


code:
VS_SCC_LOCALPATH
----------------

Visual Studio Source Code Control Local Path.

Can be set to change the visual studio source code control local path
property.


code:
VS_SCC_PROJECTNAME
------------------

Visual Studio Source Code Control Project.

Can be set to change the visual studio source code control project
name property.


code:
VS_SCC_PROVIDER
---------------

Visual Studio Source Code Control Provider.

Can be set to change the visual studio source code control provider
property.


code:
VS_SDK_REFERENCES
-----------------

.. versionadded:: 3.7

Visual Studio project SDK references.
Specify a :ref:`semicolon-separated list <CMake Language Lists>` of SDK references
to be added to a generated Visual Studio project, e.g.
``Microsoft.AdMediatorWindows81, Version=1.0``.


code:
VS_SOLUTION_DEPLOY
------------------

.. versionadded:: 3.18

Specify that the target should be marked for deployment when not targeting
Windows CE, Windows Phone or a Windows Store application.

If the target platform doesn't support deployment, this property won't have
any effect.

:manual:`Generator expressions <cmake-generator-expressions(7)>` are supported.

Examples
^^^^^^^^

Always deploy target ``foo``:

.. code-block:: cmake

  add_executable(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_SOLUTION_DEPLOY ON)

Deploy target ``foo`` for all configurations except ``Release``:

.. code-block:: cmake

  add_executable(foo SHARED foo.cpp)
  set_property(TARGET foo PROPERTY VS_SOLUTION_DEPLOY "$<NOT:$<CONFIG:Release>>")


code:
VS_SOURCE_SETTINGS_<tool>
-------------------------

.. versionadded:: 3.18

Set any item metadata on all non-built files that use <tool>.

Takes a list of ``Key=Value`` pairs. Tells the Visual Studio generator
to set ``Key`` to ``Value`` as item metadata on all non-built files
that use ``<tool>``.

For example:

.. code-block:: cmake

  set_property(TARGET main PROPERTY VS_SOURCE_SETTINGS_FXCompile "Key=Value" "Key2=Value2")

will set ``Key`` to ``Value`` and ``Key2`` to ``Value2`` for all
non-built files that use ``FXCompile``.

:manual:`Generator expressions <cmake-generator-expressions(7)>` are supported.


code:
VS_USER_PROPS
-------------

.. versionadded:: 3.8

Sets the user props file to be included in the visual studio
C++ project file. The standard path is
``$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props``, which is
in most cases the same as
``%LOCALAPPDATA%\\Microsoft\\MSBuild\\v4.0\\Microsoft.Cpp.Win32.user.props``
or ``%LOCALAPPDATA%\\Microsoft\\MSBuild\\v4.0\\Microsoft.Cpp.x64.user.props``.

The ``*.user.props`` files can be used for Visual Studio wide
configuration which is independent from cmake.


code:
VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION
--------------------------------------

.. versionadded:: 3.4

Visual Studio Windows Target Platform Minimum Version

For Windows 10. Specifies the minimum version of the OS that is being
targeted. For example ``10.0.10240.0``. If the value is not specified, the
value of the :variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable
will be used on WindowsStore projects.  Otherwise the target platform
minimum version will not be specified for the project.

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


code:
VS_WINRT_COMPONENT
------------------

.. versionadded:: 3.1

Mark a target as a Windows Runtime component for the Visual Studio generator.
Compile the target with ``C++/CX`` language extensions for Windows Runtime.
For ``SHARED`` and ``MODULE`` libraries, this also defines the
``_WINRT_DLL`` preprocessor macro.

.. note::
  Currently this is implemented only by Visual Studio generators.
  Support may be added to other generators in the future.


code:
VS_WINRT_EXTENSIONS
-------------------

Deprecated.  Use :prop_tgt:`VS_WINRT_COMPONENT` instead.
This property was an experimental partial implementation of that one.


code:
VS_WINRT_REFERENCES
-------------------

Visual Studio project Windows Runtime Metadata references

Adds one or more semicolon-delimited WinRT references to a generated
Visual Studio project.  For example, "Windows;Windows.UI.Core".


code:
WATCOM_RUNTIME_LIBRARY
----------------------

.. versionadded:: 3.24

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

The allowed values are:

.. include:: WATCOM_RUNTIME_LIBRARY-VALUES.txt

Use :manual:`generator expressions <cmake-generator-expressions(7)>` to
support per-configuration specification.

For example, the code:

.. code-block:: cmake

  add_executable(foo foo.c)
  set_property(TARGET foo PROPERTY
    WATCOM_RUNTIME_LIBRARY "MultiThreaded")

selects for the target ``foo`` a multi-threaded statically-linked runtime
library.

If this property is not set then CMake uses the default value
``MultiThreadedDLL`` on Windows and ``SingleThreaded`` on other
platforms to select a Watcom runtime library.

.. note::

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


code:
WIN32_EXECUTABLE
----------------

Build an executable with a WinMain entry point on windows.

When this property is set to true the executable when linked on
Windows will be created with a WinMain() entry point instead of just
main().  This makes it a GUI executable instead of a console application.
See the :variable:`CMAKE_MFC_FLAG` variable documentation to
configure use of the Microsoft Foundation Classes (MFC) for WinMain
executables.  This property is initialized by the value of the
:variable:`CMAKE_WIN32_EXECUTABLE` variable if it is set when
a target is created.

This property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`, except if the
target is managed (contains C# code.)


code:
WINDOWS_EXPORT_ALL_SYMBOLS
--------------------------

.. versionadded:: 3.4

This property is implemented only for MS-compatible tools on Windows.

Enable this boolean property to automatically create a module definition
(``.def``) file with all global symbols found in the input ``.obj`` files
for a ``SHARED`` library (or executable with :prop_tgt:`ENABLE_EXPORTS`)
on Windows.  The module definition file will be passed to the linker
causing all symbols to be exported from the ``.dll``.
For global *data* symbols, ``__declspec(dllimport)`` must still be used when
compiling against the code in the ``.dll``.  All other function symbols will
be automatically exported and imported by callers.  This simplifies porting
projects to Windows by reducing the need for explicit ``dllexport`` markup,
even in ``C++`` classes.

When this property is enabled, zero or more ``.def`` files may also be
specified as source files of the target.  The exports named by these files
will be merged with those detected from the object files to generate a
single module definition file to be passed to the linker.  This can be
used to export symbols from a ``.dll`` that are not in any of its object
files but are added by the linker from dependencies (e.g. ``msvcrt.lib``).

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


code:
XCODE_ATTRIBUTE_<an-attribute>
------------------------------

Set Xcode target attributes directly.

Tell the :generator:`Xcode` generator to set ``<an-attribute>`` to a given
value in the generated Xcode project.  Ignored on other generators.

This offers low-level control over the generated Xcode project file.
It is meant as a last resort for specifying settings that CMake does
not otherwise have a way to control.  Although this can override a
setting CMake normally produces on its own, doing so bypasses CMake's
model of the project and can break things.

See the :variable:`CMAKE_XCODE_ATTRIBUTE_<an-attribute>` variable
to set attributes on all targets in a directory tree.

Contents of ``XCODE_ATTRIBUTE_<an-attribute>`` 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:
XCODE_EMBED_FRAMEWORKS_CODE_SIGN_ON_COPY
----------------------------------------

.. versionadded:: 3.20

Tell the :generator:`Xcode` generator to perform code signing for all the
frameworks and libraries that are embedded using the
:prop_tgt:`XCODE_EMBED_FRAMEWORKS <XCODE_EMBED_<type>>` property.

.. versionadded:: 3.21

This property was generalized to other types of embedded items.  See
:prop_tgt:`XCODE_EMBED_<type>_CODE_SIGN_ON_COPY` for the more general form.


code:
XCODE_EMBED_FRAMEWORKS_REMOVE_HEADERS_ON_COPY
---------------------------------------------

.. versionadded:: 3.20

Tell the :generator:`Xcode` generator to remove headers from all the
frameworks that are embedded using the
:prop_tgt:`XCODE_EMBED_FRAMEWORKS <XCODE_EMBED_<type>>` property.

.. versionadded:: 3.21

This property was generalized to other types of embedded items.  See
:prop_tgt:`XCODE_EMBED_<type>_REMOVE_HEADERS_ON_COPY` for the more
general form.


code:
XCODE_EMBED_<type>
------------------

.. versionadded:: 3.20

Tell the :generator:`Xcode` generator to embed the specified list of items into
the target bundle.  ``<type>`` specifies the embed build phase to use.
See the Xcode documentation for the base location of each ``<type>``.

The supported values for ``<type>`` are:

``FRAMEWORKS``
  The specified items will be added to the ``Embed Frameworks`` build phase.
  The items can be CMake target names or paths to frameworks or libraries.

``APP_EXTENSIONS``
  .. versionadded:: 3.21

  The specified items will be added to the ``Embed App Extensions`` build
  phase, with ``Destination`` set to ``PlugIns and Foundation Extensions``
  They must be CMake target names.

``EXTENSIONKIT_EXTENSIONS``
  .. versionadded:: 3.26

  The specified items will be added to the ``Embed App Extensions`` build
  phase, with ``Destination`` set to ``ExtensionKit Extensions``
  They must be CMake target names, and should likely have the
  ``XCODE_PRODUCT_TYPE`` target property set to
  ``com.apple.product-type.extensionkit-extension``
  as well as the  ``XCODE_EXPLICIT_FILE_TYPE`` to
  ``wrapper.extensionkit-extension``

``PLUGINS``
  .. versionadded:: 3.23

  The specified items will be added to the ``Embed PlugIns`` build phase.
  They must be CMake target names.

``RESOURCES``
  .. versionadded:: 3.28

  The specified items will be added to the ``Embed Resources`` build phase.
  They must be CMake target names or folder paths.

``XPC_SERVICES``
  .. versionadded:: 3.29

  The specified items will be added to the ``Embed XPC Services`` build phase.
  They must be CMake target names.

When listing a target as any of the things to embed, Xcode must see that target
as part of the same Xcode project, or a sub-project of the one defining the
bundle.  In order to satisfy this constraint, the CMake project must ensure
at least one of the following:

* The :variable:`CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY` variable is set
  to true in the top level ``CMakeLists.txt`` file.  This is the simplest and
  most robust approach.
* Define the target-to-embed in a subdirectory of the one that defines the
  target being embedded into.
* If the target-to-embed and the target being embedded into are in separate,
  unrelated directories (i.e. they are siblings, not one a parent of the
  other), ensure they have a common :command:`project` call in a parent
  directory and no other :command:`project` calls between themselves and that
  common :command:`project` call.

See also :prop_tgt:`XCODE_EMBED_<type>_PATH`,
:prop_tgt:`XCODE_EMBED_<type>_REMOVE_HEADERS_ON_COPY` and
:prop_tgt:`XCODE_EMBED_<type>_CODE_SIGN_ON_COPY`.


code:
XCODE_EMBED_<type>_CODE_SIGN_ON_COPY
------------------------------------

.. versionadded:: 3.20

Boolean property used only by the :generator:`Xcode` generator.  It specifies
whether to perform code signing for the items that are embedded using the
:prop_tgt:`XCODE_EMBED_<type>` property.

The supported values for ``<type>`` are:

``FRAMEWORKS``

``APP_EXTENSIONS``
  .. versionadded:: 3.21

``EXTENSIONKIT_EXTENSIONS``
  .. versionadded:: 3.26

``PLUGINS``
  .. versionadded:: 3.23

If a ``XCODE_EMBED_<type>_CODE_SIGN_ON_COPY`` property is not defined on the
target, no code signing on copy will be performed for that ``<type>``.


code:
XCODE_EMBED_<type>_PATH
-----------------------

.. versionadded:: 3.20

This property is used only by the :generator:`Xcode` generator.  When defined,
it specifies the relative path to use when embedding the items specified by
:prop_tgt:`XCODE_EMBED_<type>`.  The path is relative
to the base location of the ``Embed XXX`` build phase associated with
``<type>``.  See the Xcode documentation for the base location of each
``<type>``.

The supported values for ``<type>`` are:

``FRAMEWORKS``

``APP_EXTENSIONS``
  .. versionadded:: 3.21

``EXTENSIONKIT_EXTENSIONS``
  .. versionadded:: 3.26

``PLUGINS``
  .. versionadded:: 3.23

``RESOURCES``
  .. versionadded:: 3.28

``XPC_SERVICES``
  .. versionadded:: 3.29


code:
XCODE_EMBED_<type>_REMOVE_HEADERS_ON_COPY
-----------------------------------------

.. versionadded:: 3.20

Boolean property used only by the :generator:`Xcode` generator.  It specifies
whether to remove headers from all the frameworks that are embedded using the
:prop_tgt:`XCODE_EMBED_<type>` property.

The supported values for ``<type>`` are:

``FRAMEWORKS``
  If the ``XCODE_EMBED_FRAMEWORKS_REMOVE_HEADERS_ON_COPY`` property is not
  defined, headers will not be removed on copy by default.

``APP_EXTENSIONS``
  .. versionadded:: 3.21

  If the ``XCODE_EMBED_APP_EXTENSIONS_REMOVE_HEADERS_ON_COPY`` property is not
  defined, headers WILL be removed on copy by default.

``EXTENSIONKIT_EXTENSIONS``
  .. versionadded:: 3.26

  If the ``XCODE_EMBED_APP_EXTENSIONS_REMOVE_HEADERS_ON_COPY`` property is not
  defined, headers WILL be removed on copy by default.

``PLUGINS``
  .. versionadded:: 3.23


code:
XCODE_EXPLICIT_FILE_TYPE
------------------------

.. versionadded:: 3.8

Set the Xcode ``explicitFileType`` attribute on its reference to a
target.  CMake computes a default based on target type but
can be told explicitly with this property.

See also :prop_tgt:`XCODE_PRODUCT_TYPE`.


code:
XCODE_GENERATE_SCHEME
---------------------

.. versionadded:: 3.15

If enabled, the :generator:`Xcode` generator will generate schema files.  These
are useful to invoke analyze, archive, build-for-testing and test
actions from the command line.

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

The following target properties overwrite the default of the
corresponding settings on the "Diagnostic" tab for each schema file.
Each of those is initialized by the respective ``CMAKE_`` variable
at target creation time.

- :prop_tgt:`XCODE_SCHEME_ADDRESS_SANITIZER`
- :prop_tgt:`XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN`
- :prop_tgt:`XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER`
- :prop_tgt:`XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS`
- :prop_tgt:`XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE`
- :prop_tgt:`XCODE_SCHEME_GUARD_MALLOC`
- :prop_tgt:`XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP`
- :prop_tgt:`XCODE_SCHEME_MALLOC_GUARD_EDGES`
- :prop_tgt:`XCODE_SCHEME_MALLOC_SCRIBBLE`
- :prop_tgt:`XCODE_SCHEME_MALLOC_STACK`
- :prop_tgt:`XCODE_SCHEME_THREAD_SANITIZER`
- :prop_tgt:`XCODE_SCHEME_THREAD_SANITIZER_STOP`
- :prop_tgt:`XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER`
- :prop_tgt:`XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP`
- :prop_tgt:`XCODE_SCHEME_LAUNCH_CONFIGURATION`
- :prop_tgt:`XCODE_SCHEME_ENABLE_GPU_API_VALIDATION`
- :prop_tgt:`XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION`
- :prop_tgt:`XCODE_SCHEME_ZOMBIE_OBJECTS`

The following target properties will be applied on the
"Info", "Arguments", and "Options" tab:

- :prop_tgt:`XCODE_SCHEME_ARGUMENTS`
- :prop_tgt:`XCODE_SCHEME_DEBUG_AS_ROOT`
- :prop_tgt:`XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING`
- :prop_tgt:`XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE`
- :prop_tgt:`XCODE_SCHEME_ENVIRONMENT`
- :prop_tgt:`XCODE_SCHEME_EXECUTABLE`
- :prop_tgt:`XCODE_SCHEME_LAUNCH_MODE`
- :prop_tgt:`XCODE_SCHEME_WORKING_DIRECTORY`


code:
XCODE_LINK_BUILD_PHASE_MODE
---------------------------

.. versionadded:: 3.19

When using the :generator:`Xcode` generator, libraries to be linked will be
specified in the Xcode project file using either the "Link Binary With
Libraries" build phase or directly as linker flags.  The former allows Xcode
to manage build paths, which may be necessary when creating Xcode archives
because it may use different build paths to a regular build.

This property controls usage of "Link Binary With Libraries" build phase for
a target that is an app bundle, executable, shared library, shared framework
or a module library.

Possible values are:

* ``NONE``
  The libraries will be linked by specifying the linker flags directly.

* ``BUILT_ONLY``
  The "Link Binary With Libraries" build phase will be used to link to another
  target under the following conditions:

  - The target to be linked to is a regular non-imported, non-interface library
    target.
  - The output directory of the target being built has not been changed from
    its default (see :prop_tgt:`RUNTIME_OUTPUT_DIRECTORY` and
    :prop_tgt:`LIBRARY_OUTPUT_DIRECTORY`).

* ``KNOWN_LOCATION``
  The "Link Binary With Libraries" build phase will be used to link to another
  target under the same conditions as with ``BUILT_ONLY`` and also:

  - Imported library targets except those of type ``UNKNOWN``.
  - Any non-target library specified directly with a path.

For all other cases, the libraries will be linked by specifying the linker
flags directly.

.. warning::
  Libraries linked using "Link Binary With Libraries" are linked after the
  ones linked through regular linker flags.  This order should be taken into
  account when different static libraries contain symbols with the same name,
  as the former ones will take precedence over the latter.

.. warning::
  If two or more directories contain libraries with identical file names and
  some libraries are linked from those directories, the library search path
  lookup will end up linking libraries from the first directory.  This is a
  known limitation of Xcode.

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


code:
XCODE_PRODUCT_TYPE
------------------

.. versionadded:: 3.8

Set the Xcode ``productType`` attribute on its reference to a
target.  CMake computes a default based on target type but
can be told explicitly with this property.

See also :prop_tgt:`XCODE_EXPLICIT_FILE_TYPE`.


code:
XCODE_SCHEME_ADDRESS_SANITIZER
------------------------------

.. versionadded:: 3.13

Whether to enable ``Address Sanitizer`` in the Diagnostics
section of the generated Xcode scheme.

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

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
-----------------------------------------------

.. versionadded:: 3.13

Whether to enable ``Detect use of stack after return``
in the Diagnostics section of the generated Xcode scheme.

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

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ARGUMENTS
----------------------

.. versionadded:: 3.13

Specify command line arguments that should be added to the Arguments
section of the generated Xcode scheme.

If set to a list of arguments those will be added to the scheme.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DEBUG_AS_ROOT
--------------------------

.. versionadded:: 3.15

Whether to debug the target as 'root'.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING
--------------------------------------

.. versionadded:: 3.16

Whether to enable
``Allow debugging when using document Versions Browser``
in the Options section of the generated Xcode scheme.

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

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
----------------------------------------

.. versionadded:: 3.13

Whether to disable the ``Main Thread Checker``
in the Diagnostics section of the generated Xcode scheme.

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

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
----------------------------------

.. versionadded:: 3.13

Whether to enable ``Dynamic Library Loads``
in the Diagnostics section of the generated Xcode scheme.

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

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
-------------------------------------

.. versionadded:: 3.13

Whether to enable ``Dynamic Linker API usage``
in the Diagnostics section of the generated Xcode scheme.

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

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
XCODE_SCHEME_ENABLE_GPU_API_VALIDATION
--------------------------------------

.. versionadded:: 3.25

Property value for ``Metal: API Validation`` in the Options section of
the generated Xcode scheme.

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

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.