code:
ANDROID_SKIP_ANT_STEP
---------------------

.. versionadded:: 3.4

Set the Android property that defines whether or not to skip the Ant build step.
This is a boolean property initialized by the value of the
:variable:`CMAKE_ANDROID_SKIP_ANT_STEP` variable if it is set when a target is created.


code:
ANDROID_STL_TYPE
----------------

.. versionadded:: 3.4

When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
Edition`, this property specifies the type of STL support for the project.
This is a string property that could set to the one of the following values:

``none``
  No C++ Support
``system``
  Minimal C++ without STL
``gabi++_static``
  GAbi++ Static
``gabi++_shared``
  GAbi++ Shared
``gnustl_static``
  GNU libstdc++ Static
``gnustl_shared``
  GNU libstdc++ Shared
``stlport_static``
  STLport Static
``stlport_shared``
  STLport Shared

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

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
ARCHIVE_OUTPUT_DIRECTORY
------------------------

.. |XXX| replace:: :ref:`ARCHIVE <Archive Output Artifacts>`
.. |xxx| replace:: archive
.. |CMAKE_XXX_OUTPUT_DIRECTORY| replace:: :variable:`CMAKE_ARCHIVE_OUTPUT_DIRECTORY`
.. include:: XXX_OUTPUT_DIRECTORY.txt

.. |IDEM| replace:: in the same directory
.. include:: MACOS_IMPORT_FILES.txt

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


code:
ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>
---------------------------------

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

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

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


code:
ARCHIVE_OUTPUT_NAME
-------------------

.. |XXX| replace:: :ref:`ARCHIVE <Archive Output Artifacts>`
.. |xxx| replace:: archive
.. include:: XXX_OUTPUT_NAME.txt

.. |IDEM| replace:: with the same name
.. include:: MACOS_IMPORT_FILES.txt

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


code:
ARCHIVE_OUTPUT_NAME_<CONFIG>
----------------------------

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

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


code:
AUTOGEN_BETTER_GRAPH_MULTI_CONFIG
---------------------------------

.. versionadded:: 3.29

``AUTOGEN_BETTER_GRAPH_MULTI_CONFIG`` is a boolean property that can be set
on a target to have better dependency graph for multi-configuration generators.
When this property is enabled, ``CMake`` will generate more per-config targets.
Thus, the dependency graph will be more accurate for multi-configuration
generators and some recompilations will be avoided.

If the Qt version is 6.8 or newer, this property is enabled by default.
If the Qt version is older than 6.8, this property is disabled by default.
Consult the Qt documentation to check if the property can be enabled for older
Qt versions.

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

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


code:
AUTOGEN_BUILD_DIR
-----------------

.. versionadded:: 3.9

Directory where :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTOUIC` and :prop_tgt:`AUTORCC`
generate files for the target.

The directory is created on demand and automatically added to the
:prop_tgt:`ADDITIONAL_CLEAN_FILES` target property.

When unset or empty the directory ``<dir>/<target-name>_autogen`` is used where
``<dir>`` is :variable:`CMAKE_CURRENT_BINARY_DIR` and ``<target-name>``
is :prop_tgt:`NAME`.

By default ``AUTOGEN_BUILD_DIR`` is unset.

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


code:
AUTOGEN_COMMAND_LINE_LENGTH_MAX
-------------------------------

.. versionadded:: 3.29

Command line length limit for autogen targets, i.e. ``moc`` or ``uic``,
that triggers the use of response files on Windows instead of passing all
arguments to the command line.

- An empty (or unset) value sets the limit to 32000
- A positive non zero integer value sets the exact command line length
  limit.

By default ``AUTOGEN_COMMAND_LINE_LENGTH_MAX`` is initialized from
:variable:`CMAKE_AUTOGEN_COMMAND_LINE_LENGTH_MAX`.

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


code:
AUTOGEN_ORIGIN_DEPENDS
----------------------

.. versionadded:: 3.14

Switch for forwarding origin target dependencies to the corresponding
:ref:`<ORIGIN>_autogen` target.

  .. note::

    If Qt 5.15 or later is used and the generator is either :generator:`Ninja`
    or :ref:`Makefile Generators`, origin target dependencies are forwarded to
    the :ref:`<ORIGIN>_autogen_timestamp_deps` target instead of
    :ref:`<ORIGIN>_autogen`

Targets which have their :prop_tgt:`AUTOMOC` or :prop_tgt:`AUTOUIC` property
``ON`` have a corresponding :ref:`<ORIGIN>_autogen` target which generates
``moc`` and ``uic`` files.  As this :ref:`<ORIGIN>_autogen` target is created at
generate-time, it is not possible to define dependencies of it using
e.g.  :command:`add_dependencies`.  Instead the ``AUTOGEN_ORIGIN_DEPENDS``
target property decides whether the origin target dependencies should be
forwarded to the :ref:`<ORIGIN>_autogen` target or not.

By default ``AUTOGEN_ORIGIN_DEPENDS`` is initialized from
:variable:`CMAKE_AUTOGEN_ORIGIN_DEPENDS` which is ``ON`` by default.

In total the dependencies of the :ref:`<ORIGIN>_autogen` target are composed
from

- forwarded origin target dependencies
  (enabled by default via ``AUTOGEN_ORIGIN_DEPENDS``)
- additional user defined dependencies from :prop_tgt:`AUTOGEN_TARGET_DEPENDS`

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

.. note::

    Disabling ``AUTOGEN_ORIGIN_DEPENDS`` is useful to avoid building of
    origin target dependencies when building the :ref:`<ORIGIN>_autogen` target
    only. This is especially interesting when a
    :variable:`global autogen target <CMAKE_GLOBAL_AUTOGEN_TARGET>` is enabled.

    When the :ref:`<ORIGIN>_autogen` target doesn't require all the origin target's
    dependencies, and ``AUTOGEN_ORIGIN_DEPENDS`` is disabled, it might be
    necessary to extend :prop_tgt:`AUTOGEN_TARGET_DEPENDS` to add missing
    dependencies.


code:
AUTOGEN_PARALLEL
----------------

.. versionadded:: 3.11

Number of parallel ``moc`` or ``uic`` processes to start when using
:prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`.

The custom :ref:`<ORIGIN>_autogen` target starts a number of threads of which
each one parses a source file and on demand starts a ``moc`` or ``uic``
process. ``AUTOGEN_PARALLEL`` controls how many parallel threads
(and therefore ``moc`` or ``uic`` processes) are started.

- An empty (or unset) value or the string ``AUTO`` sets the number of
  threads/processes to the number of physical CPUs on the host system.
- A positive non zero integer value sets the exact thread/process count.
- Otherwise a single thread/process is started.

By default ``AUTOGEN_PARALLEL`` is initialized from
:variable:`CMAKE_AUTOGEN_PARALLEL`.

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


code:
AUTOGEN_TARGET_DEPENDS
----------------------

Additional target dependencies of the corresponding :ref:`<ORIGIN>_autogen`
target.

  .. note::

    If Qt 5.15 or later is used and the generator is either :generator:`Ninja`
    or :ref:`Makefile Generators`, additional target dependencies are added to
    the :ref:`<ORIGIN>_autogen_timestamp_deps` target instead of the
    :ref:`<ORIGIN>_autogen` target.

Targets which have their :prop_tgt:`AUTOMOC` or :prop_tgt:`AUTOUIC` property
``ON`` have a corresponding :ref:`<ORIGIN>_autogen`  target which generates
``moc`` and ``uic`` files.  As this :ref:`<ORIGIN>_autogen`  target is created
at generate-time, it is not possible to define dependencies of it using e.g.
:command:`add_dependencies`.  Instead the ``AUTOGEN_TARGET_DEPENDS`` target
property can be set to a :ref:`;-list <CMake Language Lists>` of additional
dependencies for the :ref:`<ORIGIN>_autogen`  target. Dependencies can be target
names or file names.

In total the dependencies of the :ref:`<ORIGIN>_autogen`  target are composed
from

- forwarded origin target dependencies
  (enabled by default via :prop_tgt:`AUTOGEN_ORIGIN_DEPENDS`)
- additional user defined dependencies from ``AUTOGEN_TARGET_DEPENDS``

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

Use cases
^^^^^^^^^

If :prop_tgt:`AUTOMOC` or :prop_tgt:`AUTOUIC` depends on a file that is either

- a :prop_sf:`GENERATED` non C++ file (e.g. a :prop_sf:`GENERATED` ``.json``
  or ``.ui`` file) or
- a :prop_sf:`GENERATED` C++ file that isn't recognized by :prop_tgt:`AUTOMOC`
  and :prop_tgt:`AUTOUIC` because it's skipped by :prop_sf:`SKIP_AUTOMOC`,
  :prop_sf:`SKIP_AUTOUIC`, :prop_sf:`SKIP_AUTOGEN` or :policy:`CMP0071` or
- a file that isn't in the origin target's sources

it must be added to ``AUTOGEN_TARGET_DEPENDS``.


code:
AUTOGEN_USE_SYSTEM_INCLUDE
--------------------------

.. versionadded:: 3.27

``AUTOGEN_USE_SYSTEM_INCLUDE`` is a boolean property that can be set
on a target to indicate that the autogen target include directory should
be added as a system include directory or normal include directory to the
target.

If this property is not set, the autogen target include directory is added
as a system include directory by default.  See policy :policy:`CMP0151`.

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

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


code:
AUTOMOC
-------

Should the target be processed with auto-moc (for Qt projects).

``AUTOMOC`` is a boolean specifying whether CMake will handle the Qt ``moc``
preprocessor automatically, i.e.  without having to use commands like
:module:`QT4_WRAP_CPP() <FindQt4>`, `qt5_wrap_cpp()`_, etc.
Currently, Qt versions 4 to 6 are supported.

.. _qt5_wrap_cpp(): https://doc.qt.io/qt-5/qtcore-cmake-qt5-wrap-cpp.html

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

When this property is set ``ON``, CMake will scan the header and
source files at build time and invoke ``moc`` accordingly.

Header file processing
^^^^^^^^^^^^^^^^^^^^^^

At configuration time, a list of header files that should be scanned by
``AUTOMOC`` is computed from the target's sources.

- All header files in the target's sources are added to the scan list.
- For all C++ source files ``<source_base>.<source_extension>`` in the
  target's sources, CMake searches for

  - a regular header with the same base name
    (``<source_base>.<header_extention>``) and
  - a private header with the same base name and a ``_p`` suffix
    (``<source_base>_p.<header_extention>``)

  and adds these to the scan list.

At build time, CMake scans each unknown or modified header file from the
list and searches for

- a Qt macro from :prop_tgt:`AUTOMOC_MACRO_NAMES`,
- additional file dependencies from the ``FILE`` argument of a
  ``Q_PLUGIN_METADATA`` macro and
- additional file dependencies detected by filters defined in
  :prop_tgt:`AUTOMOC_DEPEND_FILTERS`.

If a Qt macro is found, then the header will be compiled by the ``moc`` to the
output file ``moc_<base_name>.cpp``.  The complete output file path is
described in the section `Output file location`_.

The header will be ``moc`` compiled again if a file from the additional file
dependencies changes.

Header ``moc`` output files ``moc_<base_name>.cpp`` can be included in source
files.  In the section `Including header moc files in sources`_ there is more
information on that topic.

Source file processing
^^^^^^^^^^^^^^^^^^^^^^

At build time, CMake scans each unknown or modified C++ source file from the
target's sources for

- a Qt macro from :prop_tgt:`AUTOMOC_MACRO_NAMES`,
- includes of header ``moc`` files
  (see `Including header moc files in sources`_),
- additional file dependencies from the ``FILE`` argument of a
  ``Q_PLUGIN_METADATA`` macro and
- additional file dependencies detected by filters defined in
  :prop_tgt:`AUTOMOC_DEPEND_FILTERS`.

If a Qt macro is found, then the C++ source file
``<base>.<source_extension>`` is expected to as well contain an include
statement

.. code-block:: c++

  #include <<base>.moc> // or
  #include "<base>.moc"

The source file then will be compiled by the ``moc`` to the output file
``<base>.moc``.  A description of the complete output file path is in section
`Output file location`_.

The source will be ``moc`` compiled again if a file from the additional file
dependencies changes.

Including header moc files in sources
"""""""""""""""""""""""""""""""""""""

A source file can include the ``moc`` output file of a header
``<header_base>.<header_extension>`` by using an include statement of
the form

.. code-block:: c++

  #include <moc_<header_base>.cpp> // or
  #include "moc_<header_base>.cpp"

If the ``moc`` output file of a header is included by a source, it will
be generated in a different location than if it was not included.  This is
described in the section `Output file location`_.

Output file location
^^^^^^^^^^^^^^^^^^^^

Included moc output files
"""""""""""""""""""""""""

``moc`` output files that are included by a source file will be generated in

- ``<AUTOGEN_BUILD_DIR>/include``
  for single configuration generators or in
- ``<AUTOGEN_BUILD_DIR>/include_<CONFIG>``
  for :prop_gbl:`multi configuration <GENERATOR_IS_MULTI_CONFIG>` generators.

Where ``<AUTOGEN_BUILD_DIR>`` is the value of the target property
:prop_tgt:`AUTOGEN_BUILD_DIR`.

The include directory is automatically added to the target's
:prop_tgt:`INCLUDE_DIRECTORIES`.

Not included moc output files
"""""""""""""""""""""""""""""

``moc`` output files that are not included in a source file will be generated
in

- ``<AUTOGEN_BUILD_DIR>/<SOURCE_DIR_CHECKSUM>``
  for single configuration generators or in,
- ``<AUTOGEN_BUILD_DIR>/include_<CONFIG>/<SOURCE_DIR_CHECKSUM>``
  for :prop_gbl:`multi configuration <GENERATOR_IS_MULTI_CONFIG>` generators.

Where ``<SOURCE_DIR_CHECKSUM>`` is a checksum computed from the relative
parent directory path of the ``moc`` input file.  This scheme allows to have
``moc`` input files with the same name in different directories.

All not included ``moc`` output files will be included automatically by the
CMake generated file

- ``<AUTOGEN_BUILD_DIR>/mocs_compilation.cpp``, or
- ``<AUTOGEN_BUILD_DIR>/mocs_compilation_$<CONFIG>.cpp``,

which is added to the target's sources.

Qt version detection
^^^^^^^^^^^^^^^^^^^^

``AUTOMOC`` enabled targets need to know the Qt major and minor
version they're working with.  The major version usually is provided by the
``INTERFACE_QT_MAJOR_VERSION`` property of the ``Qt[456]Core`` library,
that the target links to.  To find the minor version, CMake builds a list of
available Qt versions from

- ``Qt6Core_VERSION_MAJOR`` and ``Qt6Core_VERSION_MINOR`` variables
  (usually set by ``find_package(Qt6...)``)
- ``Qt6Core_VERSION_MAJOR`` and ``Qt6Core_VERSION_MINOR`` directory properties
- ``Qt5Core_VERSION_MAJOR`` and ``Qt5Core_VERSION_MINOR`` variables
  (usually set by ``find_package(Qt5...)``)
- ``Qt5Core_VERSION_MAJOR`` and ``Qt5Core_VERSION_MINOR`` directory properties
- ``QT_VERSION_MAJOR`` and ``QT_VERSION_MINOR``  variables
  (usually set by ``find_package(Qt4...)``)
- ``QT_VERSION_MAJOR`` and ``QT_VERSION_MINOR``  directory properties

in the context of the :command:`add_executable` or :command:`add_library` call.

Assumed  ``INTERFACE_QT_MAJOR_VERSION`` is a valid number, the first
entry in the list with a matching major version is taken.  If no matching major
version was found, an error is generated.
If  ``INTERFACE_QT_MAJOR_VERSION`` is not a valid number, the first
entry in the list is taken.

A ``find_package(Qt[456]...)`` call sets the ``QT/Qt[56]Core_VERSION_MAJOR/MINOR``
variables.  If the call is in a different context than the
:command:`add_executable` or :command:`add_library` call, e.g. in a function,
then the version variables might not be available to the ``AUTOMOC``
enabled target.
In that case the version variables can be forwarded from the
``find_package(Qt[456]...)`` calling context to the :command:`add_executable`
or :command:`add_library` calling context as directory properties.
The following Qt5 example demonstrates the procedure.

.. code-block:: cmake

  function (add_qt5_client)
    find_package(Qt5 REQUIRED QUIET COMPONENTS Core Widgets)
    ...
    set_property(DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
      PROPERTY Qt5Core_VERSION_MAJOR "${Qt5Core_VERSION_MAJOR}")
    set_property(DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
      PROPERTY Qt5Core_VERSION_MINOR "${Qt5Core_VERSION_MAJOR}")
    ...
  endfunction ()
  ...
  add_qt5_client()
  add_executable(myTarget main.cpp)
  target_link_libraries(myTarget Qt5::QtWidgets)
  set_property(TARGET myTarget PROPERTY AUTOMOC ON)

Modifiers
^^^^^^^^^

:prop_tgt:`AUTOMOC_EXECUTABLE`:
The ``moc`` executable will be detected automatically, but can be forced to
a certain binary using this target property.

:prop_tgt:`AUTOMOC_MOC_OPTIONS`:
Additional command line options for ``moc`` can be set in this target property.

:prop_tgt:`AUTOMOC_MACRO_NAMES`:
This list of Qt macro names can be extended to search for additional macros in
headers and sources.

:prop_tgt:`AUTOMOC_DEPEND_FILTERS`:
``moc`` dependency file names can be extracted from headers or sources by
defining file name filters in this target property.

:prop_tgt:`AUTOMOC_COMPILER_PREDEFINES`:
Compiler pre definitions for ``moc`` are written to the ``moc_predefs.h`` file.
The generation of this file can be enabled or disabled in this target property.

:prop_sf:`SKIP_AUTOMOC`:
Sources and headers can be excluded from ``AUTOMOC`` processing by
setting this source file property.

:prop_sf:`SKIP_AUTOGEN`:
Source files can be excluded from ``AUTOMOC``,
:prop_tgt:`AUTOUIC` and :prop_tgt:`AUTORCC` processing by
setting this source file property.

:prop_gbl:`AUTOGEN_SOURCE_GROUP`:
This global property can be used to group files generated by
``AUTOMOC`` or :prop_tgt:`AUTORCC` together in an IDE, e.g.  in MSVS.

:prop_gbl:`AUTOGEN_TARGETS_FOLDER`:
This global property can be used to group ``AUTOMOC``,
:prop_tgt:`AUTOUIC` and :prop_tgt:`AUTORCC` targets together in an IDE,
e.g.  in MSVS.

:variable:`CMAKE_GLOBAL_AUTOGEN_TARGET`:
A global ``autogen`` target, that depends on all ``AUTOMOC`` or
:prop_tgt:`AUTOUIC` generated :ref:`<ORIGIN>_autogen` targets in the project,
will be generated when this variable is ``ON``.

:prop_tgt:`AUTOGEN_PARALLEL`:
This target property controls the number of ``moc`` or ``uic`` processes to
start in parallel during builds.

:prop_tgt:`AUTOGEN_COMMAND_LINE_LENGTH_MAX`:
This target property controls the limit when to use response files for
``moc`` or ``uic`` processes on Windows.

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


code:
AUTOMOC_COMPILER_PREDEFINES
---------------------------

.. versionadded:: 3.10

Boolean value used by :prop_tgt:`AUTOMOC` to determine if the
compiler pre definitions file ``moc_predefs.h`` should be generated.

CMake generates a ``moc_predefs.h`` file with compiler pre definitions
from the output of the command defined in
:variable:`CMAKE_CXX_COMPILER_PREDEFINES_COMMAND <CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND>`
when

- :prop_tgt:`AUTOMOC` is enabled,
- ``AUTOMOC_COMPILER_PREDEFINES`` is enabled,
- :variable:`CMAKE_CXX_COMPILER_PREDEFINES_COMMAND <CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND>` isn't empty and
- the Qt version is greater or equal 5.8.

The ``moc_predefs.h`` file, which is generated in :prop_tgt:`AUTOGEN_BUILD_DIR`,
is passed to ``moc`` as the argument to the ``--include`` option.

By default ``AUTOMOC_COMPILER_PREDEFINES`` is initialized from
:variable:`CMAKE_AUTOMOC_COMPILER_PREDEFINES`, which is ON by default.

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


code:
AUTOMOC_DEPEND_FILTERS
----------------------

.. versionadded:: 3.9

Filter definitions used by :prop_tgt:`AUTOMOC` to extract file names from a
source file that are registered as additional dependencies for the
``moc`` file of the source file.

Filters are defined as ``KEYWORD;REGULAR_EXPRESSION`` pairs. First the file
content is searched for ``KEYWORD``. If it is found at least once, then file
names are extracted by successively searching for ``REGULAR_EXPRESSION`` and
taking the first match group.

The file name found in the first match group is searched for

- first in the vicinity of the source file
- and afterwards in the target's :prop_tgt:`INCLUDE_DIRECTORIES`.

If any of the extracted files changes, then the ``moc`` file for the source
file gets rebuilt even when the source file itself doesn't change.

If any of the extracted files is :prop_sf:`GENERATED` or if it is not in the
target's sources, then it might be necessary to add it to the
:ref:`<ORIGIN>_autogen` target  dependencies.
See :prop_tgt:`AUTOGEN_TARGET_DEPENDS` for reference.

By default ``AUTOMOC_DEPEND_FILTERS`` is initialized from
:variable:`CMAKE_AUTOMOC_DEPEND_FILTERS`, which is empty by default.

From Qt 5.15.0 on this variable is ignored as ``moc`` is able to output the
correct dependencies.

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

Example 1
^^^^^^^^^

A header file ``my_class.hpp`` uses a custom macro ``JSON_FILE_MACRO`` which
is defined in an other header ``macros.hpp``.
We want the ``moc`` file of ``my_class.hpp`` to depend on the file name
argument of ``JSON_FILE_MACRO``::

  // my_class.hpp
  class My_Class : public QObject
  {
    Q_OBJECT
    JSON_FILE_MACRO ( "info.json" )
  ...
  };

In ``CMakeLists.txt`` we add a filter to
:variable:`CMAKE_AUTOMOC_DEPEND_FILTERS` like this::

  list( APPEND CMAKE_AUTOMOC_DEPEND_FILTERS
    "JSON_FILE_MACRO"
    "[\n][ \t]*JSON_FILE_MACRO[ \t]*\\([ \t]*\"([^\"]+)\""
  )

We assume ``info.json`` is a plain (not :prop_sf:`GENERATED`) file that is
listed in the target's source.  Therefore we do not need to add it to
:prop_tgt:`AUTOGEN_TARGET_DEPENDS`.

Example 2
^^^^^^^^^

In the target ``my_target`` a header file ``complex_class.hpp`` uses a
custom macro ``JSON_BASED_CLASS`` which is defined in an other header
``macros.hpp``::

  // macros.hpp
  ...
  #define JSON_BASED_CLASS(name, json) \
  class name : public QObject \
  { \
    Q_OBJECT \
    Q_PLUGIN_METADATA(IID "demo" FILE json) \
    name() {} \
  };
  ...

::

  // complex_class.hpp
  #pragma once
  JSON_BASED_CLASS(Complex_Class, "meta.json")
  // end of file

Since ``complex_class.hpp`` doesn't contain a ``Q_OBJECT`` macro it would be
ignored by :prop_tgt:`AUTOMOC`.  We change this by adding ``JSON_BASED_CLASS``
to :variable:`CMAKE_AUTOMOC_MACRO_NAMES`::

  list(APPEND CMAKE_AUTOMOC_MACRO_NAMES "JSON_BASED_CLASS")

We want the ``moc`` file of ``complex_class.hpp`` to depend on
``meta.json``.  So we add a filter to
:variable:`CMAKE_AUTOMOC_DEPEND_FILTERS`::

  list(APPEND CMAKE_AUTOMOC_DEPEND_FILTERS
    "JSON_BASED_CLASS"
    "[\n^][ \t]*JSON_BASED_CLASS[ \t]*\\([^,]*,[ \t]*\"([^\"]+)\""
  )

Additionally we assume ``meta.json`` is :prop_sf:`GENERATED` which is
why we have to add it to :prop_tgt:`AUTOGEN_TARGET_DEPENDS`::

  set_property(TARGET my_target APPEND PROPERTY AUTOGEN_TARGET_DEPENDS "meta.json")


code:
AUTOMOC_EXECUTABLE
------------------

.. versionadded:: 3.14

``AUTOMOC_EXECUTABLE`` is file path pointing to the ``moc``
executable to use for :prop_tgt:`AUTOMOC` enabled files. Setting
this property will make CMake skip the automatic detection of the
``moc`` binary as well as the sanity-tests normally run to ensure
that the binary is available and working as expected.

Usually this property does not need to be set. Only consider this
property if auto-detection of ``moc`` can not work -- e.g. because
you are building the ``moc`` binary as part of your project.

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


code:
AUTOMOC_MACRO_NAMES
-------------------

.. versionadded:: 3.10

A :ref:`semicolon-separated list <CMake Language Lists>` of macro names used by
:prop_tgt:`AUTOMOC` to determine if a C++ file needs to be processed by ``moc``.

This property is only used if the :prop_tgt:`AUTOMOC` property is ``ON``
for this target.

When running :prop_tgt:`AUTOMOC`, CMake searches for the strings listed in
``AUTOMOC_MACRO_NAMES`` in C++ source and header files.
If any of the strings is found

- as the first non space string on a new line or
- as the first non space string after a ``{`` on a new line,

then the file will be processed by ``moc``.

By default ``AUTOMOC_MACRO_NAMES`` is initialized from
:variable:`CMAKE_AUTOMOC_MACRO_NAMES`.

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

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

Example
^^^^^^^

In this case the ``Q_OBJECT`` macro is hidden inside another macro
called ``CUSTOM_MACRO``.  To let CMake know that source files that contain
``CUSTOM_MACRO`` need to be ``moc`` processed, we call:

.. code-block:: cmake

  set_property(TARGET tgt APPEND PROPERTY AUTOMOC_MACRO_NAMES "CUSTOM_MACRO")


code:
AUTOMOC_MOC_OPTIONS
-------------------

Additional options for ``moc`` when using :prop_tgt:`AUTOMOC`

This property is only used if the :prop_tgt:`AUTOMOC` property is ``ON``
for this target.  In this case, it holds additional command line
options which will be used when ``moc`` is executed during the build, i.e.
it is equivalent to the optional ``OPTIONS`` argument of the
:module:`qt4_wrap_cpp() <FindQt4>` macro.

This property is initialized by the value of the
:variable:`CMAKE_AUTOMOC_MOC_OPTIONS` variable if it is set when a target
is created, or an empty string otherwise.

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

EXAMPLE
^^^^^^^

In this example, the ``moc`` tool is invoked with the ``-D_EXTRA_DEFINE``
option when generating the moc file for ``object.cpp``.

``CMakeLists.txt``
  .. code-block:: cmake

    add_executable(mocOptions object.cpp main.cpp)
    set_property(TARGET mocOptions PROPERTY AUTOMOC ON)
    target_compile_options(mocOptions PRIVATE "-D_EXTRA_DEFINE")
    set_property(TARGET mocOptions PROPERTY AUTOMOC_MOC_OPTIONS "-D_EXTRA_DEFINE")
    target_link_libraries(mocOptions Qt6::Core)

``object.hpp``
  .. code-block:: c++

    #ifndef Object_HPP
    #define Object_HPP

    #include <QObject>

    #ifdef _EXTRA_DEFINE
    class Object : public QObject
    {
    Q_OBJECT
    public:

      Object();

    };
    #endif

    #endif


code:
AUTOMOC_PATH_PREFIX
-------------------

.. versionadded:: 3.16

When this property is ``ON``, CMake will generate the ``-p`` path prefix
option for ``moc`` on :prop_tgt:`AUTOMOC` enabled Qt targets.

To generate the path prefix, CMake tests if the header compiled by ``moc``
is in any of the target
:command:`include directories <target_include_directories>`.  If so, CMake will
compute the relative path accordingly.  If the header is not in the
:command:`include directories <target_include_directories>`, CMake will omit
the ``-p`` path prefix option.  ``moc`` usually generates a
relative include path in that case.

``AUTOMOC_PATH_PREFIX`` is initialized from the variable
:variable:`CMAKE_AUTOMOC_PATH_PREFIX`, which is ``OFF`` by default.

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

Reproducible builds
^^^^^^^^^^^^^^^^^^^

For reproducible builds it is recommended to keep headers that are ``moc``
compiled in one of the target
:command:`include directories <target_include_directories>` and set
``AUTOMOC_PATH_PREFIX`` to ``ON``.  This ensures that:

- ``moc`` output files are identical on different build setups,
- ``moc`` output files will compile correctly when the source and/or
  build directory is a symbolic link.


code:
AUTORCC
-------

Should the target be processed with auto-rcc (for Qt projects).

``AUTORCC`` is a boolean specifying whether CMake will handle
the Qt ``rcc`` code generator automatically, i.e. without having to use
commands like :module:`QT4_ADD_RESOURCES() <FindQt4>`, `qt5_add_resources()`_,
etc.  Currently, Qt versions 4 to 6 are supported.

.. _`qt5_add_resources()`: https://doc.qt.io/qt-5/qtcore-cmake-qt5-add-resources.html

When this property is ``ON``, CMake will handle ``.qrc`` files added
as target sources at build time and invoke ``rcc`` accordingly.
This property is initialized by the value of the :variable:`CMAKE_AUTORCC`
variable if it is set when a target is created.

By default ``AUTORCC`` is processed by a
:command:`custom command <add_custom_command>`.
If the ``.qrc`` file is :prop_sf:`GENERATED`, a
:command:`custom target <add_custom_target>` is used instead.

When there are multiple ``.qrc`` files with the same name, CMake will
generate unspecified unique output file names for ``rcc``.  Therefore, if
``Q_INIT_RESOURCE()`` or ``Q_CLEANUP_RESOURCE()`` need to be used, the
``.qrc`` file name must be unique.

Modifiers
^^^^^^^^^

:prop_tgt:`AUTORCC_EXECUTABLE`:
The ``rcc`` executable will be detected automatically, but can be forced to
a certain binary by setting this target property.

:prop_tgt:`AUTORCC_OPTIONS`:
Additional command line options for ``rcc`` can be set via this target
property.  The corresponding :prop_sf:`AUTORCC_OPTIONS` source file property
can be used to specify options to be applied only to a specific ``.qrc`` file.

:prop_sf:`SKIP_AUTORCC`:
``.qrc`` files can be excluded from ``AUTORCC`` processing by
setting this source file property.

:prop_sf:`SKIP_AUTOGEN`:
Source files can be excluded from :prop_tgt:`AUTOMOC`,
:prop_tgt:`AUTOUIC` and ``AUTORCC`` processing by
setting this source file property.

:prop_gbl:`AUTOGEN_SOURCE_GROUP`:
This global property can be used to group files generated by
:prop_tgt:`AUTOMOC` or ``AUTORCC`` together in an IDE, e.g.  in MSVS.

:prop_gbl:`AUTOGEN_TARGETS_FOLDER`:
This global property can be used to group :prop_tgt:`AUTOMOC`,
:prop_tgt:`AUTOUIC` and ``AUTORCC`` targets together in an IDE,
e.g.  in MSVS.

:variable:`CMAKE_GLOBAL_AUTORCC_TARGET`:
A global ``autorcc`` target that depends on all ``AUTORCC`` targets
in the project will be generated when this variable is ``ON``.

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


code:
AUTORCC_EXECUTABLE
------------------

.. versionadded:: 3.14

``AUTORCC_EXECUTABLE`` is file path pointing to the ``rcc``
executable to use for :prop_tgt:`AUTORCC` enabled files. Setting
this property will make CMake skip the automatic detection of the
``rcc`` binary as well as the sanity-tests normally run to ensure
that the binary is available and working as expected.

Usually this property does not need to be set. Only consider this
property if auto-detection of ``rcc`` can not work -- e.g. because
you are building the ``rcc`` binary as part of your project.

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


code:
AUTORCC_OPTIONS
---------------

Additional options for ``rcc`` when using :prop_tgt:`AUTORCC`

This property holds additional command line options which will be used
when ``rcc`` is executed during the build via :prop_tgt:`AUTORCC`,
i.e. it is equivalent to the optional ``OPTIONS`` argument of the
:module:`qt4_add_resources() <FindQt4>` macro.

This property is initialized by the value of the
:variable:`CMAKE_AUTORCC_OPTIONS` variable if it is set when a target is
created, or an empty string otherwise.

The options set on the target may be overridden by :prop_sf:`AUTORCC_OPTIONS`
set on the ``.qrc`` source file.

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

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set_property(TARGET tgt PROPERTY AUTORCC_OPTIONS "--compress;9")
  # ...


code:
AUTOUIC
-------

Should the target be processed with auto-uic (for Qt projects).

``AUTOUIC`` is a boolean specifying whether CMake will handle
the Qt ``uic`` code generator automatically, i.e. without having to use
commands like :module:`QT4_WRAP_UI() <FindQt4>`, `qt5_wrap_ui()`_, etc.
Currently, Qt versions 4 to 6 are supported.

.. _`qt5_wrap_ui()`: https://doc.qt.io/qt-5/qtwidgets-cmake-qt5-wrap-ui.html

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

When this property is ``ON``, CMake will scan the header and source files at
build time and invoke ``uic`` accordingly.

Header and source file processing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

At build time, CMake scans each header and source file from the
target's sources for include statements of the form

.. code-block:: c++

  #include "ui_<ui_base>.h"

Once such an include statement is found in a file, CMake searches for the
``uic`` input file ``<ui_base>.ui``

- in the vicinity of the file and
- in the :prop_tgt:`AUTOUIC_SEARCH_PATHS` of the target.

If the ``<ui_base>.ui`` file was found, ``uic`` is called on it to generate
``ui_<ui_base>.h`` in the directory

- ``<AUTOGEN_BUILD_DIR>/include`` for single configuration generators or in
- ``<AUTOGEN_BUILD_DIR>/include_<CONFIG>`` for
  :prop_gbl:`multi configuration <GENERATOR_IS_MULTI_CONFIG>` generators.

Where ``<AUTOGEN_BUILD_DIR>`` is the value of the target property
:prop_tgt:`AUTOGEN_BUILD_DIR`.

The include directory is automatically added to the target's
:prop_tgt:`INCLUDE_DIRECTORIES`.

Modifiers
^^^^^^^^^

:prop_tgt:`AUTOUIC_EXECUTABLE`:
The ``uic`` executable will be detected automatically, but can be forced to
a certain binary using this target property.

:prop_tgt:`AUTOUIC_OPTIONS`:
Additional command line options for ``uic`` can be set via this target
property.  The corresponding :prop_sf:`AUTOUIC_OPTIONS` source file property
can be used to specify options to be applied only to a specific
``<base_name>.ui`` file.

:prop_sf:`SKIP_AUTOUIC`:
Source files can be excluded from ``AUTOUIC`` processing by setting
this source file property.

:prop_sf:`SKIP_AUTOGEN`:
Source files can be excluded from :prop_tgt:`AUTOMOC`,
``AUTOUIC`` and :prop_tgt:`AUTORCC` processing by
setting this source file property.

:prop_gbl:`AUTOGEN_TARGETS_FOLDER`:
This global property can be used to group :prop_tgt:`AUTOMOC`,
``AUTOUIC`` and :prop_tgt:`AUTORCC` targets together in an IDE,
e.g.  in MSVS.

:variable:`CMAKE_GLOBAL_AUTOGEN_TARGET`:
A global ``autogen`` target, that depends on all :prop_tgt:`AUTOMOC` or
``AUTOUIC`` generated :ref:`<ORIGIN>_autogen` targets in the project,
will be generated when this variable is ``ON``.

:prop_tgt:`AUTOGEN_PARALLEL`:
This target property controls the number of ``moc`` or ``uic`` processes to
start in parallel during builds.

:prop_tgt:`AUTOGEN_COMMAND_LINE_LENGTH_MAX`:
This target property controls the limit when to use response files for
``moc`` or ``uic`` processes on Windows.

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


code:
AUTOUIC_EXECUTABLE
------------------

.. versionadded:: 3.14

``AUTOUIC_EXECUTABLE`` is file path pointing to the ``uic``
executable to use for :prop_tgt:`AUTOUIC` enabled files. Setting
this property will make CMake skip the automatic detection of the
``uic`` binary as well as the sanity-tests normally run to ensure
that the binary is available and working as expected.

Usually this property does not need to be set. Only consider this
property if auto-detection of ``uic`` can not work -- e.g. because
you are building the ``uic`` binary as part of your project.

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


code:
AUTOUIC_OPTIONS
---------------

Additional options for ``uic`` when using :prop_tgt:`AUTOUIC`

This property holds additional command line options which will be used when
``uic`` is executed during the build via :prop_tgt:`AUTOUIC`, i.e. it is
equivalent to the optional ``OPTIONS`` argument of the
:module:`qt4_wrap_ui() <FindQt4>` macro.

This property is initialized by the value of the
:variable:`CMAKE_AUTOUIC_OPTIONS` variable if it is set when a target is
created, or an empty string otherwise.

The options set on the target may be overridden by :prop_sf:`AUTOUIC_OPTIONS`
set on the ``.ui`` source file.

This property may use "generator expressions" with the syntax ``$<...>``.
See the :manual:`cmake-generator-expressions(7)` manual for available
expressions.

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

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set_property(TARGET tgt PROPERTY AUTOUIC_OPTIONS "--no-protection")
  # ...


code:
AUTOUIC_SEARCH_PATHS
--------------------

.. versionadded:: 3.9

Search path list used by :prop_tgt:`AUTOUIC` to find included
``.ui`` files.

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

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


code:
BINARY_DIR
----------

.. versionadded:: 3.4

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


code:
BUILD_RPATH
-----------

.. versionadded:: 3.8

A :ref:`semicolon-separated list <CMake Language Lists>` specifying
runtime path (``RPATH``) entries to add to binaries linked in the
build tree (for platforms that support it).  By default, CMake sets
the runtime path of binaries in the build tree to contain search
paths it knows are needed to find the shared libraries they link.
Projects may set ``BUILD_RPATH`` to specify additional search paths.

The build-tree runtime path will *not* be used for binaries in the
install tree.  It will be replaced with the install-tree runtime path
during the installation step.  See also the :prop_tgt:`INSTALL_RPATH`
target property.

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

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

Other settings that affect the build-tree runtime path include:

* The :variable:`CMAKE_SKIP_RPATH` variable completely disables runtime
  paths in both the build tree and install tree.

* The :prop_tgt:`SKIP_BUILD_RPATH` target property disables setting any
  runtime path in the build tree.

* The :prop_tgt:`BUILD_RPATH_USE_ORIGIN` target property causes the
  automatically-generated runtime path to use entries relative to ``$ORIGIN``.

* The :prop_tgt:`BUILD_WITH_INSTALL_RPATH` target property causes binaries
  in the build tree to be built with the install-tree runtime path.


code:
BUILD_RPATH_USE_ORIGIN
----------------------

.. versionadded:: 3.14

Whether to use relative paths for the build ``RPATH``.

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

On platforms that support runtime paths (``RPATH``) with the
``$ORIGIN`` token, setting this property to ``TRUE`` enables relative
paths in the build ``RPATH`` for executables and shared libraries that
point to shared libraries in the same build tree.

Normally the build ``RPATH`` of a binary contains absolute paths
to the directory of each shared library it links to.  The ``RPATH``
entries for directories contained within the build tree can be made
relative to enable relocatable builds and to help achieve reproducible
builds by omitting the build directory from the build environment.

This property has no effect on platforms that do not support the
``$ORIGIN`` token in ``RPATH``, or when the :variable:`CMAKE_SKIP_RPATH`
variable is set. The runtime path set through the
:prop_tgt:`BUILD_RPATH` target property is also unaffected by this
property.


code:
BUILD_WITH_INSTALL_NAME_DIR
---------------------------

.. versionadded:: 3.9

``BUILD_WITH_INSTALL_NAME_DIR`` is a boolean specifying whether the macOS
``install_name`` of a target in the build tree uses the directory given by
:prop_tgt:`INSTALL_NAME_DIR`.  This setting only applies to targets on macOS.

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

If this property is not set and policy :policy:`CMP0068` is not ``NEW``, the
value of :prop_tgt:`BUILD_WITH_INSTALL_RPATH` is used in its place.


code:
BUILD_WITH_INSTALL_RPATH
------------------------

``BUILD_WITH_INSTALL_RPATH`` is a boolean specifying whether to link the target
in the build tree with the :prop_tgt:`INSTALL_RPATH`.  This takes precedence
over :prop_tgt:`SKIP_BUILD_RPATH` and avoids the need for relinking before
installation.

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

If policy :policy:`CMP0068` is not ``NEW``, this property also controls use of
:prop_tgt:`INSTALL_NAME_DIR` in the build tree on macOS.  Either way, the
:prop_tgt:`BUILD_WITH_INSTALL_NAME_DIR` target property takes precedence.


code:
BUNDLE
------

This target is a ``CFBundle`` on the macOS.

If a module library target has this property set to true it will be
built as a ``CFBundle`` when built on the mac.  It will have the directory
structure required for a ``CFBundle`` and will be suitable to be used for
creating Browser Plugins or other application resources.


code:
BUNDLE_EXTENSION
----------------

The file extension used to name a :prop_tgt:`BUNDLE`, a :prop_tgt:`FRAMEWORK`,
or a :prop_tgt:`MACOSX_BUNDLE` target on the macOS and iOS.

The default value is ``bundle``, ``framework``, or ``app`` for the respective
target types.


code:
COMMON_LANGUAGE_RUNTIME
-----------------------

.. versionadded:: 3.12

By setting this target property, the target is configured to build with
``C++/CLI`` support.

The Visual Studio generator defines the ``clr`` parameter depending on
the value of the ``COMMON_LANGUAGE_RUNTIME`` target property:

Not Set (default)

  Native C++.

``""`` (set but empty)

  Mixed unmanaged/managed C++ using .NET Framework.

``netcore``
  .. versionadded:: 3.26

  Mixed unmanaged/managed C++ using .NET Core.

  This required VS 2019's v142 toolset or higher.

``pure``

  Managed C++.

``safe``

  Managed C++.

This property is only evaluated :ref:`Visual Studio Generators` for
VS 2010 and above.

To be able to build managed C++ targets with VS 2017 and above the component
``C++/CLI support`` must be installed, which may not be done by default.

See also :prop_tgt:`IMPORTED_COMMON_LANGUAGE_RUNTIME`


code:
COMPATIBLE_INTERFACE_BOOL
-------------------------

Properties which must be compatible with their link interface

The ``COMPATIBLE_INTERFACE_BOOL`` property may contain a list of
properties for this target which must be consistent when evaluated as a
boolean with the ``INTERFACE`` variant of the property in all linked
dependees.  For example, if a property ``FOO`` appears in the list, then
for each dependee, the ``INTERFACE_FOO`` property content in all of its
dependencies must be consistent with each other, and with the ``FOO``
property in the depender.

Consistency in this sense has the meaning that if the property is set,
then it must have the same boolean value as all others, and if the
property is not set, then it is ignored.

Note that for each dependee, the set of properties specified in this
property must not intersect with the set specified in any of the other
:ref:`Compatible Interface Properties`.


code:
COMPATIBLE_INTERFACE_NUMBER_MAX
-------------------------------

Properties whose maximum value from the link interface will be used.

The ``COMPATIBLE_INTERFACE_NUMBER_MAX`` property may contain a list of
properties for this target whose maximum value may be read at generate
time when evaluated in the ``INTERFACE`` variant of the property in all
linked dependees.  For example, if a property ``FOO`` appears in the list,
then for each dependee, the ``INTERFACE_FOO`` property content in all of
its dependencies will be compared with each other and with the ``FOO``
property in the depender.  When reading the ``FOO`` property at generate
time, the maximum value will be returned. If the property is not set,
then it is ignored.

Note that for each dependee, the set of properties specified in this
property must not intersect with the set specified in any of the other
:ref:`Compatible Interface Properties`.


code:
COMPATIBLE_INTERFACE_NUMBER_MIN
-------------------------------

Properties whose minimum value from the link interface will be used.

The ``COMPATIBLE_INTERFACE_NUMBER_MIN`` property may contain a list of
properties for this target whose minimum value may be read at generate
time when evaluated in the ``INTERFACE`` variant of the property of all
linked dependees.  For example, if a
property ``FOO`` appears in the list, then for each dependee, the
``INTERFACE_FOO`` property content in all of its dependencies will be
compared with each other and with the ``FOO`` property in the depender.
When reading the ``FOO`` property at generate time, the minimum value
will be returned.  If the property is not set, then it is ignored.

Note that for each dependee, the set of properties specified in this
property must not intersect with the set specified in any of the other
:ref:`Compatible Interface Properties`.


code:
COMPATIBLE_INTERFACE_STRING
---------------------------

Properties which must be string-compatible with their link interface

The ``COMPATIBLE_INTERFACE_STRING`` property may contain a list of
properties for this target which must be the same when evaluated as a
string in the ``INTERFACE`` variant of the property all linked dependees.
For example, if a property ``FOO`` appears in the list, then for each
dependee, the ``INTERFACE_FOO`` property content in all of its
dependencies must be equal with each other, and with the ``FOO`` property
in the depender.  If the property is not set, then it is ignored.

Note that for each dependee, the set of properties specified in this
property must not intersect with the set specified in any of the other
:ref:`Compatible Interface Properties`.


code:
COMPILE_DEFINITIONS
-------------------

Preprocessor definitions for compiling a target's sources.

The ``COMPILE_DEFINITIONS`` property may be set to a semicolon-separated
list of preprocessor definitions using the syntax ``VAR`` or ``VAR=value``.
Function-style definitions are not supported.  CMake will
automatically escape the value correctly for the native build system
(note that CMake language syntax may require escapes to specify some
values).

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

.. versionadded:: 3.26
  Any leading ``-D`` on an item will be removed.

.. include:: /include/COMPILE_DEFINITIONS_DISCLAIMER.txt

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

The corresponding :prop_tgt:`COMPILE_DEFINITIONS_<CONFIG>` property may
be set to specify per-configuration definitions.  Generator expressions
should be preferred instead of setting the alternative property.


code:
COMPILE_DEFINITIONS_<CONFIG>
----------------------------

Ignored.  See CMake Policy :policy:`CMP0043`.

Per-configuration preprocessor definitions on a target.

This is the configuration-specific version of :prop_tgt:`COMPILE_DEFINITIONS`
where ``<CONFIG>`` is an upper-case name (ex. ``COMPILE_DEFINITIONS_DEBUG``).

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

Generator expressions should be preferred instead of setting this property.


code:
COMPILE_FEATURES
----------------

.. versionadded:: 3.1

Compiler features enabled for this target.

The list of features in this property are a subset of the features listed
in the :variable:`CMAKE_C_COMPILE_FEATURES`, :variable:`CMAKE_CUDA_COMPILE_FEATURES`, and
:variable:`CMAKE_CXX_COMPILE_FEATURES` variables.

Contents of ``COMPILE_FEATURES`` may use "generator expressions" with the
syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)` manual for
available expressions.  See the :manual:`cmake-compile-features(7)` manual
for information on compile features and a list of supported compilers.


code:
COMPILE_FLAGS
-------------

Additional flags to use when compiling this target's sources.

The ``COMPILE_FLAGS`` property sets additional compiler flags used to
build sources within the target.  Use :prop_tgt:`COMPILE_DEFINITIONS`
to pass additional preprocessor definitions.

This property is deprecated.  Use the :prop_tgt:`COMPILE_OPTIONS`
property or the :command:`target_compile_options` command instead.


code:
COMPILE_OPTIONS
---------------

List of options to pass to the compiler.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>`
of options specified so far for its target.  Use the
:command:`target_compile_options` command to append more options.
The options will be added after flags in the
:variable:`CMAKE_<LANG>_FLAGS` and :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>`
variables, but before those propagated from dependencies by the
:prop_tgt:`INTERFACE_COMPILE_OPTIONS` property.

This property adds compile options for all languages in a target.
Use the :genex:`COMPILE_LANGUAGE` generator expression to specify
per-language compile options.

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

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

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


code:
COMPILE_PDB_NAME
----------------

.. versionadded:: 3.1

Output name for the MS debug symbol ``.pdb`` file generated by the
compiler while building source files.

This property specifies the base name for the debug symbols file.
If not set, the default is unspecified.

.. |PDB_XXX| replace:: :prop_tgt:`PDB_NAME`
.. include:: COMPILE_PDB_NOTE.txt


code:
COMPILE_PDB_NAME_<CONFIG>
-------------------------

.. versionadded:: 3.1

Per-configuration output name for the MS debug symbol ``.pdb`` file
generated by the compiler while building source files.

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

.. |PDB_XXX| replace:: :prop_tgt:`PDB_NAME_<CONFIG>`
.. include:: COMPILE_PDB_NOTE.txt


code:
COMPILE_PDB_OUTPUT_DIRECTORY
----------------------------

.. versionadded:: 3.1

Output directory for the MS debug symbol ``.pdb`` file
generated by the compiler while building source files.

This property specifies the directory into which the MS debug symbols
will be placed by the compiler.  This property is initialized by the
value of the :variable:`CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY` variable
if it is set when a target is created.

.. |PDB_XXX| replace:: :prop_tgt:`PDB_OUTPUT_DIRECTORY`
.. include:: COMPILE_PDB_NOTE.txt


code:
COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>
-------------------------------------

.. versionadded:: 3.1

Per-configuration output directory for the MS debug symbol ``.pdb`` file
generated by the compiler while building source files.

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

.. |PDB_XXX| replace:: :prop_tgt:`PDB_OUTPUT_DIRECTORY_<CONFIG>`
.. include:: COMPILE_PDB_NOTE.txt


code:
COMPILE_WARNING_AS_ERROR
------------------------

.. versionadded:: 3.24

Specify whether to treat warnings on compile as errors.
If enabled, adds a flag to treat warnings on compile as errors.
If the :option:`cmake --compile-no-warning-as-error` option is given
on the :manual:`cmake(1)` command line, this property is ignored.

This property is not implemented for all compilers.  It is silently ignored
if there is no implementation for the compiler being used.  The currently
implemented :variable:`compiler IDs <CMAKE_<LANG>_COMPILER_ID>` are:

* ``GNU``
* ``Clang``
* ``AppleClang``
* ``Fujitsu``
* ``FujitsuClang``
* ``IBMClang``
* ``Intel``
* ``IntelLLVM``
* ``LCC``
* ``MSVC``
* ``NVHPC``
* ``NVIDIA`` (CUDA)
* ``QCC``
* ``SunPro``
* ``Tasking``
* ``TI``
* ``VisualAge``
* ``XL``
* ``XLClang``

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


code:
<CONFIG>_OUTPUT_NAME
--------------------

Old per-configuration target file base name.
Use :prop_tgt:`OUTPUT_NAME_<CONFIG>` instead.

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


code:
<CONFIG>_POSTFIX
----------------

Postfix to append to the target file name for configuration ``<CONFIG>``.

When building with configuration ``<CONFIG>`` the value of this property
is appended to the target file name built on disk.  For non-executable
targets, this property is initialized by the value of the
:variable:`CMAKE_<CONFIG>_POSTFIX` variable if it is set when a target is
created.  This property is ignored on macOS for Frameworks and App Bundles.

For macOS see also the :prop_tgt:`FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>`
target property.


code:
CROSSCOMPILING_EMULATOR
-----------------------

.. versionadded:: 3.3

Use the given emulator to run executables created when crosscompiling.
This command will be added as a prefix to :command:`add_test`,
:command:`add_custom_command`, and :command:`add_custom_target` commands
for built target system executables.

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

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

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


code:
CUDA_ARCHITECTURES
------------------

.. versionadded:: 3.18

List of architectures to generate device code for.

An architecture can be suffixed by either ``-real`` or ``-virtual`` to specify
the kind of architecture to generate code for.
If no suffix is given then code is generated for both real and virtual
architectures.

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

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

The ``CUDA_ARCHITECTURES`` target property must be set to a non-empty value on targets
that compile CUDA sources, or it is an error.  See policy :policy:`CMP0104`.

The ``CUDA_ARCHITECTURES`` may be set to one of the following special values:

``all``
  .. versionadded:: 3.23

  Compile for all supported major and minor real architectures,
  and the highest major virtual architecture.

``all-major``
  .. versionadded:: 3.23

  Compile for all supported major real architectures, and the highest
  major virtual architecture.

``native``
  .. versionadded:: 3.24

  Compile for the architecture(s) of the host's GPU(s).

Examples
^^^^^^^^

.. code-block:: cmake

  set_target_properties(tgt PROPERTIES CUDA_ARCHITECTURES "35;50;72")

Generates code for real and virtual architectures ``30``, ``50`` and ``72``.

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES 70-real 72-virtual)

Generates code for real architecture ``70`` and virtual architecture ``72``.

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES OFF)

CMake will not pass any architecture flags to the compiler.


code:
CUDA_CUBIN_COMPILATION
----------------------

.. versionadded:: 3.27

Compile CUDA sources to ``.cubin`` files instead of ``.obj`` files
within :ref:`Object Libraries`.

For example:

.. code-block:: cmake

  add_library(mycubin OBJECT a.cu b.cu)
  set_property(TARGET mycubin PROPERTY CUDA_CUBIN_COMPILATION ON)


code:
CUDA_EXTENSIONS
---------------

.. versionadded:: 3.8

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

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

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


code:
CUDA_FATBIN_COMPILATION
-----------------------

.. versionadded:: 3.27

Compile CUDA sources to ``.fatbin`` files instead of ``.obj`` files
within :ref:`Object Libraries`.

For example:

.. code-block:: cmake

  add_library(myfbins OBJECT a.cu b.cu)
  set_property(TARGET myfbins PROPERTY CUDA_FATBIN_COMPILATION ON)


code:
CUDA_OPTIX_COMPILATION
----------------------

.. versionadded:: 3.27

Compile CUDA sources to ``.optixir`` files instead of ``.obj`` files
within :ref:`Object Libraries`.

For example:

.. code-block:: cmake

  add_library(myoptix OBJECT a.cu b.cu)
  set_property(TARGET myoptix PROPERTY CUDA_OPTIX_COMPILATION ON)


code:
CUDA_PTX_COMPILATION
--------------------

.. versionadded:: 3.9

Compile CUDA sources to ``.ptx`` files instead of ``.obj`` files
within :ref:`Object Libraries`.

For example:

.. code-block:: cmake

  add_library(myptx OBJECT a.cu b.cu)
  set_property(TARGET myptx PROPERTY CUDA_PTX_COMPILATION ON)


code:
CUDA_RESOLVE_DEVICE_SYMBOLS
---------------------------

.. versionadded:: 3.9

CUDA only: Enables device linking for the specific library target where
required.

If set, this will tell the required compilers to enable device linking
on the library target. Device linking is an additional link step
required by some CUDA compilers when :prop_tgt:`CUDA_SEPARABLE_COMPILATION` is
enabled. Normally device linking is deferred until a shared library or
executable is generated, allowing for multiple static libraries to resolve
device symbols at the same time when they are used by a shared library or
executable.

If this property or :variable:`CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS` is unset,
static libraries are treated as if it is disabled while shared, module,
and executable targets behave as if it is on.

If :variable:`CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS` has been defined,
this property is initialized to the value the variable and overriding
the default behavior.

Note that device linking is not supported for :ref:`Object Libraries`.

For instance:

.. code-block:: cmake

  set_property(TARGET mystaticlib PROPERTY CUDA_RESOLVE_DEVICE_SYMBOLS ON)


code:
CUDA_RUNTIME_LIBRARY
--------------------

.. versionadded:: 3.17

Select the CUDA runtime library for use by compilers targeting the CUDA language.

The allowed case insensitive values are:

.. include:: CUDA_RUNTIME_LIBRARY-VALUES.txt

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

If that property is not set then CMake uses an appropriate default
value based on the compiler to select the CUDA runtime library.

.. note::

  This property has effect only when the ``CUDA`` language is enabled. To
  control the CUDA runtime linking when only using the CUDA SDK with the
  ``C`` or ``C++`` language we recommend using the :module:`FindCUDAToolkit`
  module.


code:
CUDA_SEPARABLE_COMPILATION
--------------------------

.. versionadded:: 3.8

CUDA only: Enables separate compilation of device code

If set this will enable separable compilation for all CUDA files for
the given target.

For instance:

.. code-block:: cmake

  set_property(TARGET myexe PROPERTY CUDA_SEPARABLE_COMPILATION ON)

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


code:
CUDA_STANDARD
-------------

.. versionadded:: 3.8

The CUDA/C++ standard whose features are requested to build this target.

This property specifies the CUDA/C++ 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``
  CUDA C++98. Note that this maps to the same as ``03`` internally.

``03``
  CUDA C++03

``11``
  CUDA C++11

``14``
  CUDA C++14. While CMake 3.8 and later *recognize* ``14`` as a valid value,
  CMake 3.9 was the first version to include support for any compiler.

``17``
  CUDA C++17. While CMake 3.8 and later *recognize* ``17`` as a valid value,
  CMake 3.18 was the first version to include support for any compiler.

``20``
  .. versionadded:: 3.12

  CUDA C++20. While CMake 3.12 and later *recognize* ``20`` as a valid value,
  CMake 3.18 was the first version to include support for any compiler.

``23``
  .. versionadded:: 3.20

  CUDA C++23

``26``
  .. versionadded:: 3.25

  CUDA 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 CUDA_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++03`` flag if supported.  This "decay" behavior may be controlled
with the :prop_tgt:`CUDA_STANDARD_REQUIRED` target property.
Additionally, the :prop_tgt:`CUDA_EXTENSIONS` target property may be used to
control whether compiler-specific extensions are enabled on a per-target basis.

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

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


code:
CUDA_STANDARD_REQUIRED
----------------------

.. versionadded:: 3.8

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

If this property is set to ``ON``, then the value of the
:prop_tgt:`CUDA_STANDARD` target property is treated as a requirement.  If this
property is ``OFF`` or unset, the :prop_tgt:`CUDA_STANDARD` target property is
treated as optional and may "decay" to a previous standard if the requested is
not available.  For compilers that have no notion of a standard level, such as
MSVC 1800 (Visual Studio 2013) and lower, this has no effect.

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


code:
CXX_EXTENSIONS
--------------

.. versionadded:: 3.1

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

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

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


code:
CXX_MODULE_DIRS
---------------

.. versionadded:: 3.28

Semicolon-separated list of base directories of the target's default
C++ module set (i.e. the file set with name and type ``CXX_MODULES``). The
property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`.

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

See :prop_tgt:`CXX_MODULE_DIRS_<NAME>` for the list of base directories in
other C++ module sets.


code:
CXX_MODULE_DIRS_<NAME>
----------------------

.. versionadded:: 3.28

Semicolon-separated list of base directories of the target's ``<NAME>`` C++
module set, which has the set type ``CXX_MODULES``. The property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`.

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

See :prop_tgt:`CXX_MODULE_DIRS` for the list of base directories in the
default C++ module set. See :prop_tgt:`CXX_MODULE_SETS` for the file set names
of all C++ module sets.


code:
CXX_MODULE_SET
--------------

.. versionadded:: 3.28

Semicolon-separated list of files in the target's default C++ module set,
(i.e. the file set with name and type ``CXX_MODULES``). If any of the paths
are relative, they are computed relative to the target's source directory. The
property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`.

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

See :prop_tgt:`CXX_MODULE_SET_<NAME>` for the list of files in other C++
module sets.


code:
CXX_MODULE_SETS
---------------

.. versionadded:: 3.28

Read-only list of the target's ``PRIVATE`` and ``PUBLIC`` C++ module sets (i.e.
all file sets with the type ``CXX_MODULES``). Files listed in these file sets
are treated as source files for the purpose of IDE integration.

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

See also :prop_tgt:`CXX_MODULE_SET_<NAME>`, :prop_tgt:`CXX_MODULE_SET` and
:prop_tgt:`INTERFACE_CXX_MODULE_SETS`.


code:
CXX_MODULE_SET_<NAME>
---------------------

.. versionadded:: 3.28

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

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

See :prop_tgt:`CXX_MODULE_SET` for the list of files in the default C++ module
set. See :prop_tgt:`CXX_MODULE_SETS` for the file set names of all C++ module
sets.


code:
CXX_SCAN_FOR_MODULES
--------------------

.. versionadded:: 3.28

``CXX_SCAN_FOR_MODULES`` is a boolean specifying whether CMake will scan C++
sources in the target for module dependencies.  See also the
:prop_sf:`CXX_SCAN_FOR_MODULES` for per-source settings which, if set,
overrides the target-wide settings.

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

When this property is set ``ON`` or unset, CMake will scan the target's
``CXX`` sources at build time and add module dependency information to the
compile line as necessary.  When this property is set ``OFF``, CMake will not
scan the target's ``CXX`` sources at build time.

Note that scanning is only performed if C++20 or higher is enabled for the
target.  Scanning for modules in the target's sources belonging to file sets
of type ``CXX_MODULES`` is always performed.


code:
CXX_STANDARD
------------

.. versionadded:: 3.1

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

This property specifies the C++ 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.  For compilers that
have no notion of a standard level, such as Microsoft Visual C++ before
2015 Update 3, this has no effect.

Supported values are:

``98``
  C++98

``11``
  C++11

``14``
  C++14

``17``
  .. versionadded:: 3.8

  C++17

``20``
  .. versionadded:: 3.12

  C++20

``23``
  .. versionadded:: 3.20

  C++23

``26``
  .. versionadded:: 3.25

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

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

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


code:
CXX_STANDARD_REQUIRED
---------------------

.. versionadded:: 3.1

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

If this property is set to ``ON``, then the value of the
:prop_tgt:`CXX_STANDARD` target property is treated as a requirement.  If this
property is ``OFF`` or unset, the :prop_tgt:`CXX_STANDARD` target property is
treated as optional and may "decay" to a previous standard if the requested is
not available.  For compilers that have no notion of a standard level, such as
MSVC 1800 (Visual Studio 2013) and lower, this has no effect.

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


code:
C_EXTENSIONS
------------

.. versionadded:: 3.1

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

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

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


code:
C_STANDARD
----------

.. versionadded:: 3.1

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

This property specifies the C 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.  For compilers that
have no notion of a C standard level, such as Microsoft Visual C++ before
VS 16.7, this property has no effect.

Supported values are:

``90``
  C89/C90

``99``
  C99

``11``
  C11

``17``
  .. versionadded:: 3.21

  C17

``23``
  .. versionadded:: 3.21

  C23

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

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

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


code:
C_STANDARD_REQUIRED
-------------------

.. versionadded:: 3.1

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

If this property is set to ``ON``, then the value of the
:prop_tgt:`C_STANDARD` target property is treated as a requirement.  If this
property is ``OFF`` or unset, the :prop_tgt:`C_STANDARD` target property is
treated as optional and may "decay" to a previous standard if the requested is
not available.  For compilers that have no notion of a C standard level, such
as Microsoft Visual C++ before VS 16.7, this property has no effect.

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


code:
DEBUG_POSTFIX
-------------

See target property :prop_tgt:`<CONFIG>_POSTFIX`.

This property is a special case of the more-general :prop_tgt:`<CONFIG>_POSTFIX`
property for the ``DEBUG`` configuration.


code:
DEFINE_SYMBOL
-------------

Define a symbol when compiling this target's sources.

``DEFINE_SYMBOL`` sets the name of the preprocessor symbol defined when
compiling sources in a shared library.  If not set here then it is set
to ``target_EXPORTS`` by default (with some substitutions if the target is
not a valid C identifier).  This is useful for headers to know whether
they are being included from inside their library or outside to
properly setup dllexport/dllimport decorations on Windows.

On POSIX platforms, this can optionally be used to control the visibility
of symbols.

CMake provides support for such decorations with the :module:`GenerateExportHeader`
module.


code:
DEPLOYMENT_ADDITIONAL_FILES
---------------------------

.. versionadded:: 3.13

Set the WinCE project ``AdditionalFiles`` in ``DeploymentTool`` in ``.vcproj``
files generated by the :generator:`Visual Studio 9 2008` generator.
This is useful when you want to debug on remote WinCE device.
Specify additional files that will be copied to the device.
For example:

.. code-block:: cmake

  set_property(TARGET ${TARGET} PROPERTY
    DEPLOYMENT_ADDITIONAL_FILES "english.lng|local_folder|remote_folder|0"
    "german.lng|local_folder|remote_folder|0")

produces::

  <DeploymentTool AdditionalFiles="english.lng|local_folder|remote_folder|0;german.lng|local_folder|remote_folder|0" ... />


code:
DEPLOYMENT_REMOTE_DIRECTORY
---------------------------

.. versionadded:: 3.6

Set the WinCE project ``RemoteDirectory`` in ``DeploymentTool`` and
``RemoteExecutable`` in ``DebuggerTool`` in ``.vcproj`` files generated
by the :generator:`Visual Studio 9 2008` generator.
This is useful when you want to debug on remote WinCE device.
For example:

.. code-block:: cmake

  set_property(TARGET ${TARGET} PROPERTY
    DEPLOYMENT_REMOTE_DIRECTORY "\\FlashStorage")

produces::

  <DeploymentTool RemoteDirectory="\FlashStorage" ... />
  <DebuggerTool RemoteExecutable="\FlashStorage\target_file" ... />


code:
DEPRECATION
-----------

.. versionadded:: 3.17

Deprecation message from imported target's developer.

``DEPRECATION`` is the message regarding a deprecation status to be displayed
to downstream users of a target.

The message is formatted as follows:

* Lines that do not start in whitespace are wrapped as paragraph text.
* Lines that start in whitespace are preserved as preformatted text.


code:
DISABLE_PRECOMPILE_HEADERS
--------------------------

.. versionadded:: 3.16

Disables the precompilation of header files specified by
:prop_tgt:`PRECOMPILE_HEADERS` property.

If the property is not set, CMake will use the value provided
by :variable:`CMAKE_DISABLE_PRECOMPILE_HEADERS`.


code:
DLL_NAME_WITH_SOVERSION
-----------------------

.. versionadded:: 3.27

This property controls whether the :prop_tgt:`SOVERSION` target
property is added to the filename of generated DLL filenames
for the Windows platform, which is selected when the
:variable:`WIN32` variable is set.

The value of the listed property is appended to the
basename of the runtime component of the shared library
target as ``-<SOVERSION>``.

Please note that setting this property has no effect
if versioned filenames are globally disabled with the
:variable:`CMAKE_PLATFORM_NO_VERSIONED_SONAME` variable.


code:
DOTNET_SDK
----------

.. versionadded:: 3.23

Specify the .NET SDK for C# projects.  For example: ``Microsoft.NET.Sdk``.

This property tells :ref:`Visual Studio Generators` for VS 2019 and
above to generate a .NET SDK-style project using the specified SDK.
The property is meaningful only to these generators, and only in C#
targets.  It is ignored for C++ projects, even if they are managed
(e.g. using :prop_tgt:`COMMON_LANGUAGE_RUNTIME`).

This property must be a non-empty string to generate .NET SDK-style projects.
CMake does not perform any validations for the value of the property.

This property may be initialized for all targets using the
:variable:`CMAKE_DOTNET_SDK` variable.

.. note::

  The :ref:`Visual Studio Generators` in this version of CMake have not
  yet learned to support :command:`add_custom_command` in .NET SDK-style
  projects.  It is currently an error to attach a custom command to a
  target with the ``DOTNET_SDK`` property set.


code:
DOTNET_TARGET_FRAMEWORK
-----------------------

.. versionadded:: 3.17

Specify the .NET target framework.

Used to specify the .NET target framework for C++/CLI and C#.  For
example: ``netcoreapp2.1``.

This property is only evaluated for :ref:`Visual Studio Generators`
VS 2010 and above.

Can be initialized for all targets using the variable
:variable:`CMAKE_DOTNET_TARGET_FRAMEWORK`.


code:
DOTNET_TARGET_FRAMEWORK_VERSION
-------------------------------

.. versionadded:: 3.12

Specify the .NET target framework version.

Used to specify the .NET target framework version for C++/CLI and C#.
For example: ``v4.5``.

This property is only evaluated for :ref:`Visual Studio Generators`
VS 2010 and above.

To initialize this variable for all targets set
:variable:`CMAKE_DOTNET_TARGET_FRAMEWORK` or
:variable:`CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION`. If both are set,
the latter is ignored.


code:
ENABLE_EXPORTS
--------------

Specify whether an executable or a shared library exports symbols.

Normally an executable does not export any symbols because it is the
final program.  It is possible for an executable to export symbols to
be used by loadable modules.  When this property is set to true CMake
will allow other targets to "link" to the executable with the
:command:`target_link_libraries` command.  On all platforms a target-level
dependency on the executable is created for targets that link to it.
Handling of the executable on the link lines of the loadable modules
varies by platform:

* On Windows-based systems (including Cygwin) an "import library" is
  created along with the executable to list the exported symbols.
  Loadable modules link to the import library to get the symbols.

* On macOS, loadable modules link to the executable itself using the
  ``-bundle_loader`` flag.

* On AIX, a linker "import file" is created along with the executable
  to list the exported symbols for import when linking other targets.
  Loadable modules link to the import file to get the symbols.

* On other platforms, loadable modules are simply linked without
  referencing the executable since the dynamic loader will
  automatically bind symbols when the module is loaded.

This property is initialized by the value of the
:variable:`CMAKE_EXECUTABLE_ENABLE_EXPORTS` variable, if it is set when an
executable target is created.  If :variable:`CMAKE_EXECUTABLE_ENABLE_EXPORTS`
is not set, the :variable:`CMAKE_ENABLE_EXPORTS` variable is used to initialize
the property instead for backward compatibility reasons.
See below for alternative initialization behavior for shared library targets.

.. versionadded:: 3.27
  To link with a shared library on macOS, or to a shared framework on any Apple
  platform, a linker import file can be used instead of the actual shared
  library. These linker import files are also known as text-based stubs, and
  they have a ``.tbd`` file extension.

  The generation of these linker import files, as well as their consumption, is
  controlled by this property. When this property is set to true on a shared
  library target, CMake will generate a ``.tbd`` file for the library.
  Other targets that link to the shared library target will then use this
  ``.tbd`` file when linking rather than linking to the shared library binary.

  .. note::

    For backward compatibility reasons, this property will be ignored if the
    :prop_tgt:`XCODE_ATTRIBUTE_GENERATE_TEXT_BASED_STUBS <XCODE_ATTRIBUTE_<an-attribute>>`
    target property or the
    :variable:`CMAKE_XCODE_ATTRIBUTE_GENERATE_TEXT_BASED_STUBS <CMAKE_XCODE_ATTRIBUTE_<an-attribute>>`
    variable is set to false.

  For shared library targets, this property is initialized by the value of the
  :variable:`CMAKE_SHARED_LIBRARY_ENABLE_EXPORTS` variable, if it is set when
  the target is created.


code:
EXCLUDE_FROM_ALL
----------------

Set this target property to a true (or false) value to exclude (or include)
the target from the "all" target of the containing directory and its
ancestors.  If excluded, running e.g. ``make`` in the containing directory
or its ancestors will not build the target by default.

If this target property is not set then the target will be included in
the "all" target of the containing directory.  Furthermore, it will be
included in the "all" target of its ancestor directories unless the
:prop_dir:`EXCLUDE_FROM_ALL` directory property is set.

With ``EXCLUDE_FROM_ALL`` set to false or not set at all, the target
will be brought up to date as part of doing a ``make install`` or its
equivalent for the CMake generator being used.

If a target has ``EXCLUDE_FROM_ALL`` set to true, it may still be listed
in an :command:`install(TARGETS)` command, but the user is responsible for
ensuring that the target's build artifacts are not missing or outdated when
an install is performed.

This property may use "generator expressions" with the syntax ``$<...>``. See
the :manual:`cmake-generator-expressions(7)` manual for available expressions.

Only the "Ninja Multi-Config" generator supports a property value that varies by
configuration.  For all other generators the value of this property must be the
same for all configurations.


code:
EXCLUDE_FROM_DEFAULT_BUILD
--------------------------

Exclude target from ``Build Solution``.

This property is only used by Visual Studio generators.
When set to ``TRUE``, the target will not be built when you press
``Build Solution``.


code:
EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>
-----------------------------------

Per-configuration version of target exclusion from ``Build Solution``.

This is the configuration-specific version of
:prop_tgt:`EXCLUDE_FROM_DEFAULT_BUILD`.  If the generic
:prop_tgt:`EXCLUDE_FROM_DEFAULT_BUILD` is also set on a target,
``EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>`` takes
precedence in configurations for which it has a value.


code:
EXPORT_COMPILE_COMMANDS
-----------------------

.. versionadded:: 3.20

Enable/Disable output of compile commands during generation for a target.

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


code:
EXPORT_FIND_PACKAGE_NAME
------------------------

.. versionadded:: 3.29

Control the package name associated with a dependency target when exporting a
:command:`find_dependency` call in :command:`install(EXPORT)` or
:command:`export(EXPORT)`. This can be used to assign a package name to a
package that is built by CMake and exported, or to override the package in the
:command:`find_package` call that created the target.

This property is initialized by :variable:`CMAKE_EXPORT_FIND_PACKAGE_NAME`.


code:
EXPORT_NAME
-----------

Exported name for target files.

This sets the name for the ``IMPORTED`` target generated by the
:command:`install(EXPORT)` and :command:`export` commands.
If not set, the logical target name is used by default.


code:
EXPORT_NO_SYSTEM
----------------

.. versionadded:: 3.25

This property affects the behavior of the :command:`install(EXPORT)` and
:command:`export` commands when they install or export the target respectively.
When ``EXPORT_NO_SYSTEM`` is set to true, those commands generate an imported
target with :prop_tgt:`SYSTEM` property set to false.

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


code:
EXPORT_PROPERTIES
-----------------

.. versionadded:: 3.12

List additional properties to export for a target.

This property contains a list of property names that should be exported by
the :command:`install(EXPORT)` and :command:`export` commands.  By default
only a limited number of properties are exported. This property can be used
to additionally export other properties as well.

Properties starting with ``INTERFACE_`` or ``IMPORTED_`` are not allowed as
they are reserved for internal CMake use.

Properties containing generator expressions are also not allowed.

.. note::

  Since CMake 3.19, :ref:`Interface Libraries` may have arbitrary
  target properties.  If a project exports an interface library
  with custom properties, the resulting package may not work with
  dependents configured by older versions of CMake that reject the
  custom properties.


code:
EchoString
----------

A message to be displayed when the target is built.

A message to display on some generators (such as :ref:`Makefile Generators`)
when the target is built.


code:
FOLDER
------

For IDEs that present targets using a folder hierarchy, this property
specifies the name of the folder to place the target under.
To nest folders, use ``FOLDER`` values such as ``GUI/Dialogs`` with ``/``
characters separating folder levels.  Targets with no ``FOLDER`` property
will appear as top level entities.  Targets with the same ``FOLDER``
property value will appear in the same folder as siblings.

Only some CMake generators honor the ``FOLDER`` property
(e.g. :generator:`Xcode` or any of the
:ref:`Visual Studio <Visual Studio Generators>` generators).
Those generators that don't will simply ignore it.

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

The global property :prop_gbl:`USE_FOLDERS` must be set to true, otherwise
the ``FOLDER`` property is ignored.


code:
FRAMEWORK
---------

Build ``SHARED`` or ``STATIC`` library as Framework Bundle on the macOS and iOS.

If such a library target has this property set to ``TRUE`` it will be
built as a framework when built on the macOS and iOS.  It will have the
directory structure required for a framework and will be suitable to
be used with the ``-framework`` option.  This property is initialized by the
value of the :variable:`CMAKE_FRAMEWORK` variable if it is set when a target is
created.

To customize ``Info.plist`` file in the framework, use
:prop_tgt:`MACOSX_FRAMEWORK_INFO_PLIST` target property.

For macOS see also the :prop_tgt:`FRAMEWORK_VERSION` target property.

Example of creation ``dynamicFramework``:

.. code-block:: cmake

  add_library(dynamicFramework SHARED
              dynamicFramework.c
              dynamicFramework.h
  )
  set_target_properties(dynamicFramework PROPERTIES
    FRAMEWORK TRUE
    FRAMEWORK_VERSION C
    MACOSX_FRAMEWORK_IDENTIFIER com.cmake.dynamicFramework
    MACOSX_FRAMEWORK_INFO_PLIST Info.plist
    # "current version" in semantic format in Mach-O binary file
    VERSION 16.4.0
    # "compatibility version" in semantic format in Mach-O binary file
    SOVERSION 1.0.0
    PUBLIC_HEADER dynamicFramework.h
    XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
  )


code:
FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>
---------------------------------------

.. versionadded:: 3.18

Postfix to append to the framework file name for configuration ``<CONFIG>``,
when using a multi-config generator (like Xcode and Ninja Multi-Config).

When building with configuration ``<CONFIG>`` the value of this property
is appended to the framework file name built on disk.

For example, given a framework called ``my_fw``, a value of ``_debug``
for the ``FRAMEWORK_MULTI_CONFIG_POSTFIX_DEBUG`` property, and
``Debug;Release`` in :variable:`CMAKE_CONFIGURATION_TYPES`, the following
relevant files would be created for the ``Debug`` and ``Release``
configurations:

- ``Release/my_fw.framework/my_fw``
- ``Release/my_fw.framework/Versions/A/my_fw``
- ``Debug/my_fw.framework/my_fw_debug``
- ``Debug/my_fw.framework/Versions/A/my_fw_debug``

For framework targets, this property is initialized by the value of the
:variable:`CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>` variable if it
is set when a target is created.

This property is ignored for non-framework targets, and when using single
config generators.


code:
FRAMEWORK_VERSION
-----------------

.. versionadded:: 3.4

Version of a framework created using the :prop_tgt:`FRAMEWORK` target
property (e.g. ``A``).

This property only affects macOS, as iOS doesn't have versioned
directory structure.


code:
Fortran_BUILDING_INSTRINSIC_MODULES
-----------------------------------

.. versionadded:: 3.22

Instructs the CMake Fortran preprocessor that the target is building
Fortran intrinsics for building a Fortran compiler.

This property is off by default and should be turned only on projects
that build a Fortran compiler. It should not be turned on for projects
that use a Fortran compiler.

Turning this property on will correctly add dependencies for building
Fortran intrinsic modules whereas turning the property off will ignore
Fortran intrinsic modules in the dependency graph as they are supplied
by the compiler itself.


code:
Fortran_FORMAT
--------------

Set to ``FIXED`` or ``FREE`` to indicate the Fortran source layout.

This property tells CMake whether the Fortran source files in a target
use fixed-format or free-format.  CMake will pass the corresponding
format flag to the compiler.  Use the source-specific ``Fortran_FORMAT``
property to change the format of a specific source file.  If the
variable :variable:`CMAKE_Fortran_FORMAT` is set when a target is created its
value is used to initialize this property.


code:
Fortran_MODULE_DIRECTORY
------------------------

Specify output directory for Fortran modules provided by the target.

If the target contains Fortran source files that provide modules and
the compiler supports a module output directory 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_Fortran_MODULE_DIRECTORY` is set when a target is created its
value is used to initialize this property.

When using one of the :ref:`Visual Studio Generators` with the Intel Fortran
plugin installed in Visual Studio, a subdirectory named after the
configuration will be appended to the path where modules are created.
For example, if ``Fortran_MODULE_DIRECTORY`` is set to ``C:/some/path``,
modules will end up in ``C:/some/path/Debug`` (or
``C:/some/path/Release`` etc.) when an Intel Fortran ``.vfproj`` file is
generated, and in ``C:/some/path`` when any other generator is used.

Note that some compilers will automatically search the module output
directory for modules USEd during compilation but others will not.  If
your sources USE modules their location must be specified by
:prop_tgt:`INCLUDE_DIRECTORIES` regardless of this property.


code:
Fortran_PREPROCESS
------------------

.. versionadded:: 3.18

Control whether the Fortran source file should be unconditionally
preprocessed.

If unset or empty, rely on the compiler to determine whether the file
should be preprocessed. If explicitly set to ``OFF`` then the file does not
need to be preprocessed. If explicitly set to ``ON``, then the file does
need to be preprocessed as part of the compilation step.

When using the :generator:`Ninja` generator, all source files are
first preprocessed in order to generate module dependency
information. Setting this property to ``OFF`` will make ``Ninja``
skip this step.

Use the source-specific :prop_sf:`Fortran_PREPROCESS` property if a single
file needs to be preprocessed. If the variable
:variable:`CMAKE_Fortran_PREPROCESS` is set when a target is created its
value is used to initialize this property.

.. note:: For some compilers, ``NAG``, ``PGI`` and ``Solaris Studio``,
          setting this to ``OFF`` will have no effect.


code:
GENERATOR_FILE_NAME
-------------------

Generator's file for this target.

An internal property used by some generators to record the name of the
project or dsp file associated with this target.  Note that at
configure time, this property is only set for targets created by
:command:`include_external_msproject`.


code:
GHS_INTEGRITY_APP
-----------------

.. versionadded:: 3.14

``ON`` / ``OFF`` boolean to determine if an executable target should
be treated as an `Integrity Application`.

If no value is set and if a ``.int`` file is added as a source file to the
executable target it will be treated as an `Integrity Application`.

Supported on :generator:`Green Hills MULTI`.


code:
GHS_NO_SOURCE_GROUP_FILE
------------------------

.. versionadded:: 3.14

``ON`` / ``OFF`` boolean to control if the project file for a target should
be one single file or multiple files.

The default behavior or when the property is ``OFF`` is to generate a project
file for the target and then a sub-project file for each source group.

When this property is ``ON`` or if :variable:`CMAKE_GHS_NO_SOURCE_GROUP_FILE`
is ``ON`` then only a single project file is generated for the target.

Supported on :generator:`Green Hills MULTI`.


code:
GNUtoMS
-------

Convert GNU import library (``.dll.a``) to MS format (``.lib``).

When linking a shared library or executable that exports symbols using
GNU tools on Windows (MinGW/MSYS) with Visual Studio installed convert
the import library (``.dll.a``) from GNU to MS format (``.lib``).  Both import
libraries will be installed by :command:`install(TARGETS)` and exported by
:command:`install(EXPORT)` and  :command:`export` to be linked
by applications with either GNU- or MS-compatible tools.

If the variable ``CMAKE_GNUtoMS`` is set when a target is created its
value is used to initialize this property.  The variable must be set
prior to the first command that enables a language such as :command:`project`
or :command:`enable_language`.  CMake provides the variable as an option to the
user automatically when configuring on Windows with GNU tools.


code:
HAS_CXX
-------

Link the target using the C++ linker tool (obsolete).

This is equivalent to setting the :prop_tgt:`LINKER_LANGUAGE`
property to ``CXX``.


code:
HEADER_DIRS
-----------

.. versionadded:: 3.23

Semicolon-separated list of base directories of the target's default
header set (i.e. the file set with name and type ``HEADERS``). The property
supports :manual:`generator expressions <cmake-generator-expressions(7)>`.

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

See :prop_tgt:`HEADER_DIRS_<NAME>` for the list of base directories in
other header sets.


code:
HEADER_DIRS_<NAME>
------------------

.. versionadded:: 3.23

Semicolon-separated list of base directories of the target's ``<NAME>``
header set, which has the set type ``HEADERS``. The property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`.

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

See :prop_tgt:`HEADER_DIRS` for the list of base directories in the
default header set. See :prop_tgt:`HEADER_SETS` for the file set names of all
header sets.


code:
HEADER_SET
----------

.. versionadded:: 3.23

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

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

See :prop_tgt:`HEADER_SET_<NAME>` for the list of files in other header sets.


code:
HEADER_SETS
-----------

.. versionadded:: 3.23

Read-only list of the target's ``PRIVATE`` and ``PUBLIC`` header sets (i.e.
all file sets with the type ``HEADERS``). Files listed in these file sets are
treated as source files for the purpose of IDE integration. The files also
have their :prop_sf:`HEADER_FILE_ONLY` property set to ``TRUE``.

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

See also :prop_tgt:`HEADER_SET_<NAME>`, :prop_tgt:`HEADER_SET` and
:prop_tgt:`INTERFACE_HEADER_SETS`.