code:
CMP0161
-------

.. versionadded:: 3.29

The :variable:`CPACK_PRODUCTBUILD_DOMAINS` variable defaults to true.

Before CMake 3.29, the :variable:`CPACK_PRODUCTBUILD_DOMAINS` variable is
unset by default.  When using the :cpack_gen:`CPack productbuild Generator`,
this disables the use of the ``domains`` attribute in the productbuild
Distribution XML, and falls back to the ``auth`` attribute instead.
These attributes control where a productbuild package is allowed to be
installed.  But the ``auth`` attribute has been deprecated by Apple,
so projects should migrate to using ``domains`` instead.

CMake 3.29 and above prefer to use a default value of true for
:variable:`CPACK_PRODUCTBUILD_DOMAINS`, which means ``domains`` will be used
by default unless the project explicitly sets
:variable:`CPACK_PRODUCTBUILD_DOMAINS` to false.
This policy provides compatibility with projects that enabled the
:cpack_gen:`CPack productbuild Generator`, but did not explicitly set
:variable:`CPACK_PRODUCTBUILD_DOMAINS`.

The ``OLD`` behavior for this policy is to leave
:variable:`CPACK_PRODUCTBUILD_DOMAINS` unset if it hasn't been set.
The ``NEW`` behavior for this policy is to use a default value of true for
:variable:`CPACK_PRODUCTBUILD_DOMAINS`.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.29
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt
Note that a warning will only be emitted if the
:variable:`CPACK_BINARY_PRODUCTBUILD <CPACK_BINARY_<GENNAME>>` variable is
set to true and the project is being built for an Apple platform.

.. include:: DEPRECATED.txt


code:
.. note::
  The ``OLD`` behavior of a policy is
  :manual:`deprecated by definition <cmake-policies(7)>`
  and may be removed in a future version of CMake.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
CMake >= |disallowed_version| prefer that this command never be called.
The ``OLD`` behavior for this policy is to allow the command to be called.
The ``NEW`` behavior for this policy is to issue a ``FATAL_ERROR`` when the
command is called.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: |disallowed_version|
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt


code:
This policy was introduced in CMake version |INTRODUCED_IN_CMAKE_VERSION|.
It may be set by :command:`cmake_policy` or :command:`cmake_minimum_required`.
If it is not set, CMake |WARNS_OR_DOES_NOT_WARN|, and uses ``OLD`` behavior.


code:
ADVANCED
--------

True if entry should be hidden by default in GUIs.

This is a boolean value indicating whether the entry is considered
interesting only for advanced configuration.  The :command:`mark_as_advanced`
command modifies this property.


code:
HELPSTRING
----------

Help associated with entry in GUIs.

This string summarizes the purpose of an entry to help users set it
through a CMake GUI.


code:
MODIFIED
--------

Internal management property.  Do not set or get.

This is an internal cache entry property managed by CMake to track
interactive user modification of entries.  Ignore it.


code:
STRINGS
-------

Enumerate possible ``STRING`` entry values for GUI selection.

For cache entries with type ``STRING``, this enumerates a set of values.
CMake GUIs may use this to provide a selection widget instead of a
generic string entry field.  This is for convenience only.  CMake does
not enforce that the value matches one of those listed.


code:
TYPE
----

Widget type for entry in GUIs.

Cache entry values are always strings, but CMake GUIs present widgets
to help users set values.  The GUIs use this property as a hint to
determine the widget type.  Valid ``TYPE`` values are:

::

  BOOL          = Boolean ON/OFF value.
  PATH          = Path to a directory.
  FILEPATH      = Path to a file.
  STRING        = Generic string value.
  INTERNAL      = Do not present in GUI at all.
  STATIC        = Value managed by CMake, do not change.
  UNINITIALIZED = Type not yet specified.

Generally the ``TYPE`` of a cache entry should be set by the command which
creates it ( :command:`set`, :command:`option`, :command:`find_library`, etc.).


code:
VALUE
-----

Value of a cache entry.

This property maps to the actual value of a cache entry.  Setting this
property always sets the value without checking, so use with care.


code:
ADDITIONAL_CLEAN_FILES
----------------------

.. versionadded:: 3.15

A :ref:`;-list <CMake Language Lists>` of files or directories that will be
removed as a part of the global ``clean`` target.  It is useful for
specifying generated files or directories that are used by multiple targets
or by CMake itself, or that are generated in ways which cannot be captured as
outputs or byproducts of custom commands.

If an additional clean file is specific to a single target only, then the
:prop_tgt:`ADDITIONAL_CLEAN_FILES` target property would usually be a better
choice than this directory property.

Relative paths are allowed and are interpreted relative to the
current binary directory.

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

This property only works for the :generator:`Ninja` and the Makefile
generators.  It is ignored by other generators.


code:
ADDITIONAL_MAKE_CLEAN_FILES
---------------------------

.. deprecated:: 3.15

  Use :prop_dir:`ADDITIONAL_CLEAN_FILES` instead.

Additional files to remove during the clean stage.

A :ref:`;-list <CMake Language Lists>` of files that will be removed as a
part of the ``make clean`` target.

Arguments to ``ADDITIONAL_MAKE_CLEAN_FILES`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.

This property only works for the Makefile generators.
It is ignored on other generators.


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

.. versionadded:: 3.7

This read-only directory property reports absolute path to the binary
directory corresponding to the source on which it is read.


code:
BUILDSYSTEM_TARGETS
-------------------

.. versionadded:: 3.7

This read-only directory property contains a
:ref:`semicolon-separated list <CMake Language Lists>` of buildsystem targets added in the
directory by calls to the :command:`add_library`, :command:`add_executable`,
and :command:`add_custom_target` commands.  The list does not include any
:ref:`Imported Targets` or :ref:`Alias Targets`, but does include
:ref:`Interface Libraries`.  Each entry in the list is the logical name
of a target, suitable to pass to the :command:`get_property` command
``TARGET`` option.

See also the :prop_dir:`IMPORTED_TARGETS` directory property.


code:
CACHE_VARIABLES
---------------

List of cache variables available in the current directory.

This read-only property specifies the list of CMake cache variables
currently defined.  It is intended for debugging purposes.


code:
CLEAN_NO_CUSTOM
---------------

Set to true to tell :ref:`Makefile Generators` not to remove the outputs of
custom commands for this directory during the ``make clean`` operation.
This is ignored on other generators because it is not possible to implement.


code:
CMAKE_CONFIGURE_DEPENDS
-----------------------

Tell CMake about additional input files to the configuration process.
If any named file is modified the build system will re-run CMake to
re-configure the file and generate the build system again.

Specify files as a semicolon-separated list of paths.  Relative paths
are interpreted as relative to the current source directory.


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

Preprocessor definitions for compiling a directory's sources.

This property specifies the list of options given so far to the
:command:`add_compile_definitions` (or :command:`add_definitions`) command.

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

This property will be initialized in each directory by its value in the
directory's parent.

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_dir:`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 in a directory.

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

This property will be initialized in each directory by its value in
the directory's parent.

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_OPTIONS
---------------

List of options to pass to the compiler.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>` of options
given so far to the :command:`add_compile_options` command.

This property is used to initialize the :prop_tgt:`COMPILE_OPTIONS` target
property when a target is created, which 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.


code:
DEFINITIONS
-----------

For CMake 2.4 compatibility only.  Use :prop_dir:`COMPILE_DEFINITIONS`
instead.

This read-only property specifies the list of flags given so far to
the :command:`add_definitions` command.  It is intended for debugging
purposes.  Use the :prop_dir:`COMPILE_DEFINITIONS` directory property
instead.

This built-in read-only property does not exist if policy
:policy:`CMP0059` is set to ``NEW``.


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

Set this directory property to a true value on a subdirectory to exclude
its targets from the "all" target of its ancestors.  If excluded, running
e.g. ``make`` in the parent directory will not build targets the
subdirectory by default.  This does not affect the "all" target of the
subdirectory itself.  Running e.g. ``make`` inside the subdirectory will
still build its targets.

If the :prop_tgt:`EXCLUDE_FROM_ALL` target property is set on a target
then its value determines whether the target is included in the "all"
target of this directory and its ancestors.


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

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

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

::

  MYDIR(%)=<mydir/%>

will convert lines of the form

::

  #include MYDIR(myheader.h)

to

::

  #include <mydir/myheader.h>

allowing the dependency to be followed.

This property applies to sources in all targets within a directory.
The property value is initialized in each directory by its value in
the directory's parent.


code:
IMPORTED_TARGETS
----------------

.. versionadded:: 3.21

This read-only directory property contains a
:ref:`semicolon-separated list <CMake Language Lists>` of
:ref:`Imported Targets` added in the directory by calls to the
:command:`add_library` and :command:`add_executable` commands.
Each entry in the list is the logical name of a target, suitable
to pass to the :command:`get_property` command ``TARGET`` option
when called in the same directory.

See also the :prop_dir:`BUILDSYSTEM_TARGETS` directory property.


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

List of preprocessor include file search directories.

This property specifies the list of directories given so far to the
:command:`include_directories` command.

This property is used to populate the :prop_tgt:`INCLUDE_DIRECTORIES`
target property, which is used by the generators to set the include
directories for the compiler.

In addition to accepting values from that command, values may be set
directly on any directory using the :command:`set_property` command, and can be
set on the current directory using the :command:`set_directory_properties`
command.  A directory gets its initial value from its parent directory if it has
one.  The initial value of the :prop_tgt:`INCLUDE_DIRECTORIES` target property
comes from the value of this property.  Both directory and target property
values are adjusted by calls to the :command:`include_directories` command.
Calls to :command:`set_property` or :command:`set_directory_properties`,
however, will update the directory property value without updating target
property values.  Therefore direct property updates must be made before
calls to :command:`add_executable` or :command:`add_library` for targets
they are meant to affect.

The target property values are used by the generators to set the
include paths for the compiler.

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


code:
INCLUDE_REGULAR_EXPRESSION
--------------------------

Include file scanning regular expression.

This property specifies the regular expression used during
dependency scanning to match include files that should be followed.
See the :command:`include_regular_expression` command for a high-level
interface to set this property.


code:
INTERPROCEDURAL_OPTIMIZATION
----------------------------

This directory property does not exist anymore.

See the target property :prop_tgt:`INTERPROCEDURAL_OPTIMIZATION` instead.


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

This directory property does not exist anymore.

See the target property :prop_tgt:`INTERPROCEDURAL_OPTIMIZATION_<CONFIG>` instead.


code:
LABELS
------

.. versionadded:: 3.10

Specify a list of text labels associated with a directory and all of its
subdirectories. This is equivalent to setting the :prop_tgt:`LABELS` target
property and the :prop_test:`LABELS` test property on all targets and tests in
the current directory and subdirectories. Note: Launchers must enabled to
propagate labels to targets.

The :variable:`CMAKE_DIRECTORY_LABELS` variable can be used to initialize this
property.

The list is reported in dashboard submissions.


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

List of linker search directories.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>` of directories
and is typically populated using the :command:`link_directories` command.
It gets its initial value from its parent directory, if it has one.

The directory property is used to initialize the :prop_tgt:`LINK_DIRECTORIES`
target property when a target is created.  That target property is used
by the generators to set the library search directories for the linker.

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


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

.. versionadded:: 3.13

List of options to use for the link step of shared library, module
and executable targets as well as the device link step.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>` of options
given so far to the :command:`add_link_options` command.

This property is used to initialize the :prop_tgt:`LINK_OPTIONS` target
property when a target is created, which is used by the generators to set
the options for the compiler.

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


code:
LISTFILE_STACK
--------------

The current stack of listfiles being processed.

This property is mainly useful when trying to debug errors in your
CMake scripts.  It returns a list of what list files are currently
being processed, in order.  So if one listfile does an
:command:`include` command then that is effectively pushing the
included listfile onto the stack.


code:
MACROS
------

List of macro commands available in the current directory.

This read-only property specifies the list of CMake macros currently
defined.  It is intended for debugging purposes.  See the :command:`macro`
command.


code:
PARENT_DIRECTORY
----------------

Source directory that added current subdirectory.

This read-only property specifies the source directory that added the
current source directory as a subdirectory of the build.  In the
top-level directory the value is the empty-string.


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

Specify a launcher for compile rules.

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

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


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

Specify a launcher for custom rules.

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


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

Specify a launcher for link rules.

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

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


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

.. versionadded:: 3.7

This read-only directory property reports absolute path to the source
directory on which it is read.


code:
SUBDIRECTORIES
--------------

.. versionadded:: 3.7

This read-only directory property contains a
:ref:`semicolon-separated list <CMake Language Lists>` of subdirectories processed so far by
the :command:`add_subdirectory` or :command:`subdirs` commands.  Each entry is
the absolute path to the source directory (containing the ``CMakeLists.txt``
file).  This is suitable to pass to the :command:`get_property` command
``DIRECTORY`` option.

.. note::

  The :command:`subdirs` command does not process its arguments until
  after the calling directory is fully processed.  Therefore looking
  up this property in the current directory will not see them.


code:
SYSTEM
------

.. versionadded:: 3.25

This directory property is used to initialize the :prop_tgt:`SYSTEM`
target property for non-imported targets created in that directory.
It is set to true by :command:`add_subdirectory` and
:command:`FetchContent_Declare` when the ``SYSTEM`` option is given
as an argument to those commands.


code:
TESTS
-----

.. versionadded:: 3.12

List of tests.

This read-only property holds a
:ref:`semicolon-separated list <CMake Language Lists>` of tests
defined so far, in the current directory, by the :command:`add_test` command.


code:
TEST_INCLUDE_FILE
-----------------

Deprecated.  Use :prop_dir:`TEST_INCLUDE_FILES` instead.

A cmake file that will be included when ctest is run.

If you specify ``TEST_INCLUDE_FILE``, that file will be included and
processed when ctest is run on the directory.


code:
TEST_INCLUDE_FILES
------------------

.. versionadded:: 3.10

A list of cmake files that will be included when ctest is run.

If you specify ``TEST_INCLUDE_FILES``, those files will be included and
processed when ctest is run on the directory.


code:
VARIABLES
---------

List of variables defined in the current directory.

This read-only property specifies the list of CMake variables
currently defined.  It is intended for debugging purposes.


code:
VS_GLOBAL_SECTION_POST_<section>
--------------------------------

Specify a postSolution global section in Visual Studio.

Setting a property like this generates an entry of the following form
in the solution file:

::

  GlobalSection(<section>) = postSolution
    <contents based on property value>
  EndGlobalSection

The property must be set to a semicolon-separated list of ``key=value``
pairs.  Each such pair will be transformed into an entry in the
solution global section.  Whitespace around key and value is ignored.
List elements which do not contain an equal sign are skipped.

This property only works for Visual Studio 9 and above; it is ignored
on other generators.  The property only applies when set on a
directory whose ``CMakeLists.txt`` contains a :command:`project` command.

Note that CMake generates postSolution sections ``ExtensibilityGlobals``
and ``ExtensibilityAddIns`` by default.  If you set the corresponding
property, it will override the default section.  For example, setting
``VS_GLOBAL_SECTION_POST_ExtensibilityGlobals`` will override the default
contents of the ``ExtensibilityGlobals`` section, while keeping
ExtensibilityAddIns on its default.  However, CMake will always
add a ``SolutionGuid`` to the ``ExtensibilityGlobals`` section
if it is not specified explicitly.


code:
VS_GLOBAL_SECTION_PRE_<section>
-------------------------------

Specify a preSolution global section in Visual Studio.

Setting a property like this generates an entry of the following form
in the solution file:

::

  GlobalSection(<section>) = preSolution
    <contents based on property value>
  EndGlobalSection

The property must be set to a semicolon-separated list of ``key=value``
pairs.  Each such pair will be transformed into an entry in the
solution global section.  Whitespace around key and value is ignored.
List elements which do not contain an equal sign are skipped.

This property only works for Visual Studio 9 and above; it is ignored
on other generators.  The property only applies when set on a
directory whose ``CMakeLists.txt`` contains a :command:`project` command.


code:
VS_STARTUP_PROJECT
------------------

.. versionadded:: 3.6

Specify the default startup project in a Visual Studio solution.

The :ref:`Visual Studio Generators` create a ``.sln`` file for each directory
whose ``CMakeLists.txt`` file calls the :command:`project` command.  Set this
property in the same directory as a :command:`project` command call (e.g. in
the top-level ``CMakeLists.txt`` file) to specify the default startup project
for the corresponding solution file.

The property must be set to the name of an existing target.  This
will cause that project to be listed first in the generated solution
file causing Visual Studio to make it the startup project if the
solution has never been opened before.

If this property is not specified, then the ``ALL_BUILD`` project
will be the default.


code:
ALLOW_DUPLICATE_CUSTOM_TARGETS
------------------------------

Allow duplicate custom targets to be created.

Normally CMake requires that all targets built in a project have
globally unique logical names (see policy :policy:`CMP0002`).
This is necessary to generate meaningful project file names in
:generator:`Xcode` and :ref:`Visual Studio Generators` IDE
generators.  It also allows the target names to be referenced
unambiguously.

Makefile generators are capable of supporting duplicate :command:`add_custom_target`
names.  For projects that care only about :ref:`Makefile Generators` and do
not wish to support :generator:`Xcode` or :ref:`Visual Studio Generators` IDE
generators, one may set this property to ``True``
to allow duplicate custom targets.  The property
allows multiple :command:`add_custom_target` command calls in different
directories to specify the same target name.  However, setting this
property will cause non-Makefile generators to produce an error and
refuse to generate the project.


code:
AUTOGEN_SOURCE_GROUP
--------------------

.. versionadded:: 3.9

Name of the  :command:`source_group` for :prop_tgt:`AUTOMOC`,
:prop_tgt:`AUTORCC` and :prop_tgt:`AUTOUIC` generated files.

Files generated by :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTORCC` and
:prop_tgt:`AUTOUIC` are not always known at configure time and therefore can't
be passed to :command:`source_group`.
``AUTOGEN_SOURCE_GROUP`` can be used instead to generate or select
a source group for :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTORCC` and
:prop_tgt:`AUTOUIC` generated files.

For :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTORCC` and :prop_tgt:`AUTOUIC` specific
overrides see :prop_gbl:`AUTOMOC_SOURCE_GROUP`, :prop_gbl:`AUTORCC_SOURCE_GROUP`
and :prop_gbl:`AUTOUIC_SOURCE_GROUP` respectively.


code:
AUTOGEN_TARGETS_FOLDER
----------------------

Name of :prop_tgt:`FOLDER` for ``*_autogen`` targets that are added
automatically by CMake for targets for which :prop_tgt:`AUTOMOC` is enabled.

If not set, CMake uses the :prop_tgt:`FOLDER` property of the parent target as a
default value for this property.  See also the documentation for the
:prop_tgt:`FOLDER` target property and the :prop_tgt:`AUTOMOC` target property.


code:
AUTOMOC_SOURCE_GROUP
--------------------

.. versionadded:: 3.9

Name of the  :command:`source_group` for :prop_tgt:`AUTOMOC` generated files.

When set this is used instead of :prop_gbl:`AUTOGEN_SOURCE_GROUP` for
files generated by :prop_tgt:`AUTOMOC`.


code:
AUTOMOC_TARGETS_FOLDER
----------------------

Name of :prop_tgt:`FOLDER` for ``*_autogen`` targets that are added automatically by
CMake for targets for which :prop_tgt:`AUTOMOC` is enabled.

This property is obsolete.  Use :prop_gbl:`AUTOGEN_TARGETS_FOLDER` instead.

If not set, CMake uses the :prop_tgt:`FOLDER` property of the parent target as a
default value for this property.  See also the documentation for the
:prop_tgt:`FOLDER` target property and the :prop_tgt:`AUTOMOC` target property.


code:
AUTORCC_SOURCE_GROUP
--------------------

.. versionadded:: 3.9

Name of the  :command:`source_group` for :prop_tgt:`AUTORCC` generated files.

When set this is used instead of :prop_gbl:`AUTOGEN_SOURCE_GROUP` for
files generated by :prop_tgt:`AUTORCC`.


code:
AUTOUIC_SOURCE_GROUP
--------------------

.. versionadded:: 3.21

Name of the  :command:`source_group` for :prop_tgt:`AUTOUIC` generated files.

When set this is used instead of :prop_gbl:`AUTOGEN_SOURCE_GROUP` for
files generated by :prop_tgt:`AUTOUIC`.


code:
CMAKE_CUDA_KNOWN_FEATURES
-------------------------

.. versionadded:: 3.17

List of CUDA features known to this version of CMake.

The features listed in this global property may be known to be available to the
CUDA compiler.  If the feature is available with the C++ compiler, it will
be listed in the :variable:`CMAKE_CUDA_COMPILE_FEATURES` variable.

The features listed here may be used with the :command:`target_compile_features`
command.  See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.

The features known to this version of CMake are:

``cuda_std_03``
  Compiler mode is at least CUDA/C++ 03.

``cuda_std_11``
  Compiler mode is at least CUDA/C++ 11.

``cuda_std_14``
  Compiler mode is at least CUDA/C++ 14.

``cuda_std_17``
  Compiler mode is at least CUDA/C++ 17.

``cuda_std_20``
  Compiler mode is at least CUDA/C++ 20.

``cuda_std_23``
  .. versionadded:: 3.20

  Compiler mode is at least CUDA/C++ 23.

``cuda_std_26``
  .. versionadded:: 3.25

  Compiler mode is at least CUDA/C++ 26.

.. include:: CMAKE_LANG_STD_FLAGS.txt


code:
CMAKE_CXX_KNOWN_FEATURES
------------------------

.. versionadded:: 3.1

List of C++ features known to this version of CMake.

The features listed in this global property may be known to be available to the
C++ compiler.  If the feature is available with the C++ compiler, it will
be listed in the :variable:`CMAKE_CXX_COMPILE_FEATURES` variable.

The features listed here may be used with the :command:`target_compile_features`
command.  See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.

The features known to this version of CMake are listed below.

High level meta features indicating C++ standard support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.8

The following meta features indicate general support for the associated
language standard.  It reflects the language support claimed by the compiler,
but it does not necessarily imply complete conformance to that standard.

``cxx_std_98``
  Compiler mode is at least C++ 98.

``cxx_std_11``
  Compiler mode is at least C++ 11.

``cxx_std_14``
  Compiler mode is at least C++ 14.

``cxx_std_17``
  Compiler mode is at least C++ 17.

``cxx_std_20``
  .. versionadded:: 3.12

  Compiler mode is at least C++ 20.

``cxx_std_23``
  .. versionadded:: 3.20

  Compiler mode is at least C++ 23.

``cxx_std_26``
  .. versionadded:: 3.25

  Compiler mode is at least C++ 26.

.. include:: CMAKE_LANG_STD_FLAGS.txt

Low level individual compile features
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For C++ 11 and C++ 14, compilers were sometimes slow to implement certain
language features.  CMake provided some individual compile features to help
projects determine whether specific features were available.  These individual
features are now less relevant and projects should generally prefer to use the
high level meta features instead.  Individual compile features are not provided
for C++ 17 or later.

See the :manual:`cmake-compile-features(7)` manual for further discussion of
the use of individual compile features.

Individual features from C++ 98
"""""""""""""""""""""""""""""""

``cxx_template_template_parameters``
  Template template parameters, as defined in ``ISO/IEC 14882:1998``.

Individual features from C++ 11
"""""""""""""""""""""""""""""""

``cxx_alias_templates``
  Template aliases, as defined in N2258_.

  .. _N2258: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf

``cxx_alignas``
  Alignment control ``alignas``, as defined in N2341_.

  .. _N2341: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf

``cxx_alignof``
  Alignment control ``alignof``, as defined in N2341_.

  .. _N2341: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf

``cxx_attributes``
  Generic attributes, as defined in N2761_.

  .. _N2761: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf

``cxx_auto_type``
  Automatic type deduction, as defined in N1984_.

  .. _N1984: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

``cxx_constexpr``
  Constant expressions, as defined in N2235_.

  .. _N2235: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf

``cxx_decltype_incomplete_return_types``
  Decltype on incomplete return types, as defined in N3276_.

  .. _N3276 : https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf

``cxx_decltype``
  Decltype, as defined in N2343_.

  .. _N2343: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf

``cxx_default_function_template_args``
  Default template arguments for function templates, as defined in DR226_

  .. _DR226: https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226

``cxx_defaulted_functions``
  Defaulted functions, as defined in N2346_.

  .. _N2346: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm

``cxx_defaulted_move_initializers``
  Defaulted move initializers, as defined in N3053_.

  .. _N3053: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3053.html

``cxx_delegating_constructors``
  Delegating constructors, as defined in N1986_.

  .. _N1986: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf

``cxx_deleted_functions``
  Deleted functions, as defined in N2346_.

  .. _N2346: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm

``cxx_enum_forward_declarations``
  Enum forward declarations, as defined in N2764_.

  .. _N2764: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf

``cxx_explicit_conversions``
  Explicit conversion operators, as defined in N2437_.

  .. _N2437: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf

``cxx_extended_friend_declarations``
  Extended friend declarations, as defined in N1791_.

  .. _N1791: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1791.pdf

``cxx_extern_templates``
  Extern templates, as defined in N1987_.

  .. _N1987: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm

``cxx_final``
  Override control ``final`` keyword, as defined in N2928_, N3206_ and N3272_.

  .. _N2928: https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm
  .. _N3206: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
  .. _N3272: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm

``cxx_func_identifier``
  Predefined ``__func__`` identifier, as defined in N2340_.

  .. _N2340: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2340.htm

``cxx_generalized_initializers``
  Initializer lists, as defined in N2672_.

  .. _N2672: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm

``cxx_inheriting_constructors``
  Inheriting constructors, as defined in N2540_.

  .. _N2540: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2540.htm

``cxx_inline_namespaces``
  Inline namespaces, as defined in N2535_.

  .. _N2535: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2535.htm

``cxx_lambdas``
  Lambda functions, as defined in N2927_.

  .. _N2927: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf

``cxx_local_type_template_args``
  Local and unnamed types as template arguments, as defined in N2657_.

  .. _N2657: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm

``cxx_long_long_type``
  ``long long`` type, as defined in N1811_.

  .. _N1811: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1811.pdf

``cxx_noexcept``
  Exception specifications, as defined in N3050_.

  .. _N3050: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html

``cxx_nonstatic_member_init``
  Non-static data member initialization, as defined in N2756_.

  .. _N2756: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm

``cxx_nullptr``
  Null pointer, as defined in N2431_.

  .. _N2431: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf

``cxx_override``
  Override control ``override`` keyword, as defined in N2928_, N3206_
  and N3272_.

  .. _N2928: https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm
  .. _N3206: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
  .. _N3272: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm

``cxx_range_for``
  Range-based for, as defined in N2930_.

  .. _N2930: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html

``cxx_raw_string_literals``
  Raw string literals, as defined in N2442_.

  .. _N2442: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm

``cxx_reference_qualified_functions``
  Reference qualified functions, as defined in N2439_.

  .. _N2439: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm

``cxx_right_angle_brackets``
  Right angle bracket parsing, as defined in N1757_.

  .. _N1757: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html

``cxx_rvalue_references``
  R-value references, as defined in N2118_.

  .. _N2118: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html

``cxx_sizeof_member``
  Size of non-static data members, as defined in N2253_.

  .. _N2253: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html

``cxx_static_assert``
  Static assert, as defined in N1720_.

  .. _N1720: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html

``cxx_strong_enums``
  Strongly typed enums, as defined in N2347_.

  .. _N2347: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf

``cxx_thread_local``
  Thread-local variables, as defined in N2659_.

  .. _N2659: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm

``cxx_trailing_return_types``
  Automatic function return type, as defined in N2541_.

  .. _N2541: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm

``cxx_unicode_literals``
  Unicode string literals, as defined in N2442_.

  .. _N2442: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm

``cxx_uniform_initialization``
  Uniform initialization, as defined in N2640_.

  .. _N2640: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2640.pdf

``cxx_unrestricted_unions``
  Unrestricted unions, as defined in N2544_.

  .. _N2544: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf

``cxx_user_literals``
  User-defined literals, as defined in N2765_.

  .. _N2765: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf

``cxx_variadic_macros``
  Variadic macros, as defined in N1653_.

  .. _N1653: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1653.htm

``cxx_variadic_templates``
  Variadic templates, as defined in N2242_.

  .. _N2242: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf

Individual features from C++ 14
"""""""""""""""""""""""""""""""

``cxx_aggregate_default_initializers``
  Aggregate default initializers, as defined in N3605_.

  .. _N3605: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3605.html

``cxx_attribute_deprecated``
  ``[[deprecated]]`` attribute, as defined in N3760_.

  .. _N3760: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html

``cxx_binary_literals``
  Binary literals, as defined in N3472_.

  .. _N3472: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf

``cxx_contextual_conversions``
  Contextual conversions, as defined in N3323_.

  .. _N3323: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3323.pdf

``cxx_decltype_auto``
  ``decltype(auto)`` semantics, as defined in N3638_.

  .. _N3638: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html

``cxx_digit_separators``
  Digit separators, as defined in N3781_.

  .. _N3781: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3781.pdf

``cxx_generic_lambdas``
  Generic lambdas, as defined in N3649_.

  .. _N3649: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html

``cxx_lambda_init_captures``
  Initialized lambda captures, as defined in N3648_.

  .. _N3648: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html

``cxx_relaxed_constexpr``
  Relaxed constexpr, as defined in N3652_.

  .. _N3652: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html

``cxx_return_type_deduction``
  Return type deduction on normal functions, as defined in N3386_.

  .. _N3386: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3386.html

``cxx_variable_templates``
  Variable templates, as defined in N3651_.

  .. _N3651: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf


code:
CMAKE_C_KNOWN_FEATURES
----------------------

.. versionadded:: 3.1

List of C features known to this version of CMake.

The features listed in this global property may be known to be available to the
C compiler.  If the feature is available with the C compiler, it will
be listed in the :variable:`CMAKE_C_COMPILE_FEATURES` variable.

The features listed here may be used with the :command:`target_compile_features`
command.  See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.

The features known to this version of CMake are listed below.

High level meta features indicating C standard support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.8

``c_std_90``
  Compiler mode is at least C 90.

``c_std_99``
  Compiler mode is at least C 99.

``c_std_11``
  Compiler mode is at least C 11.

``c_std_17``
  .. versionadded:: 3.21

  Compiler mode is at least C 17.

``c_std_23``
  .. versionadded:: 3.21

  Compiler mode is at least C 23.

.. include:: CMAKE_LANG_STD_FLAGS.txt

Low level individual compile features
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

``c_function_prototypes``
  Function prototypes, as defined in ``ISO/IEC 9899:1990``.

``c_restrict``
  ``restrict`` keyword, as defined in ``ISO/IEC 9899:1999``.

``c_static_assert``
  Static assert, as defined in ``ISO/IEC 9899:2011``.

``c_variadic_macros``
  Variadic macros, as defined in ``ISO/IEC 9899:1999``.


code:
.. note::

  If the compiler's default standard level is at least that
  of the requested feature, CMake may omit the ``-std=`` flag.
  The flag may still be added if the compiler's default extensions mode
  does not match the :prop_tgt:`<LANG>_EXTENSIONS` target property,
  or if the :prop_tgt:`<LANG>_STANDARD` target property is set.


code:
CMAKE_ROLE
----------

.. versionadded:: 3.14

Tells what mode the current running script is in. Could be one of several
values:

``PROJECT``
  Running in project mode (processing a ``CMakeLists.txt`` file).

``SCRIPT``
  Running in ``-P`` script mode.

``FIND_PACKAGE``
  Running in ``--find-package`` mode.

``CTEST``
  Running in CTest script mode.

``CPACK``
  Running in CPack.


code:
DEBUG_CONFIGURATIONS
--------------------

Specify which configurations are for debugging.

The value must be a semi-colon separated list of configuration names.
Currently this property is used only by the :command:`target_link_libraries`
command.  Additional uses may be defined in the future.

This property must be set at the top level of the project and before
the first :command:`target_link_libraries` command invocation.  If any entry in
the list does not match a valid configuration for the project the
behavior is undefined.


code:
DISABLED_FEATURES
-----------------

List of features which are disabled during the CMake run.

List of features which are disabled during the CMake run.  By default
it contains the names of all packages which were not found.  This is
determined using the ``<NAME>_FOUND`` variables.  Packages which are
searched ``QUIET`` are not listed.  A project can add its own features to
this list.  This property is used by the macros in
``FeatureSummary.cmake``.


code:
ECLIPSE_EXTRA_CPROJECT_CONTENTS
-------------------------------

.. versionadded:: 3.12

Additional contents to be inserted into the generated Eclipse cproject file.

The cproject file defines the CDT specific information. Some third party IDE's
are based on Eclipse with the addition of other information specific to that IDE.
Through this property, it is possible to add this additional contents to
the generated project.
It is expected to contain valid XML.

Also see the :prop_gbl:`ECLIPSE_EXTRA_NATURES` property.


code:
ECLIPSE_EXTRA_NATURES
---------------------

List of natures to add to the generated Eclipse project file.

Eclipse projects specify language plugins by using natures. This property
should be set to the unique identifier for a nature (which looks like a Java
package name).

Also see the :prop_gbl:`ECLIPSE_EXTRA_CPROJECT_CONTENTS` property.


code:
ENABLED_FEATURES
----------------

List of features which are enabled during the CMake run.

List of features which are enabled during the CMake run.  By default
it contains the names of all packages which were found.  This is
determined using the ``<NAME>_FOUND`` variables.  Packages which are
searched ``QUIET`` are not listed.  A project can add its own features to
this list.  This property is used by the macros in
``FeatureSummary.cmake``.


code:
ENABLED_LANGUAGES
-----------------

Read-only property that contains the list of currently enabled languages

Set to list of currently enabled languages.


code:
FIND_LIBRARY_USE_LIB32_PATHS
----------------------------

.. versionadded:: 3.7

Whether the :command:`find_library` command should automatically search
``lib32`` directories.

``FIND_LIBRARY_USE_LIB32_PATHS`` is a boolean specifying whether the
:command:`find_library` command should automatically search the ``lib32``
variant of directories called ``lib`` in the search path when building 32-bit
binaries.

See also the :variable:`CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable.


code:
FIND_LIBRARY_USE_LIB64_PATHS
----------------------------

Whether :command:`find_library` should automatically search lib64
directories.

FIND_LIBRARY_USE_LIB64_PATHS is a boolean specifying whether the
:command:`find_library` command should automatically search the lib64
variant of directories called lib in the search path when building
64-bit binaries.

See also the :variable:`CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable.


code:
FIND_LIBRARY_USE_LIBX32_PATHS
-----------------------------

.. versionadded:: 3.9

Whether the :command:`find_library` command should automatically search
``libx32`` directories.

``FIND_LIBRARY_USE_LIBX32_PATHS`` is a boolean specifying whether the
:command:`find_library` command should automatically search the ``libx32``
variant of directories called ``lib`` in the search path when building
x32-abi binaries.

See also the :variable:`CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable.


code:
FIND_LIBRARY_USE_OPENBSD_VERSIONING
-----------------------------------

Whether :command:`find_library` should find OpenBSD-style shared
libraries.

This property is a boolean specifying whether the
:command:`find_library` command should find shared libraries with
OpenBSD-style versioned extension: ".so.<major>.<minor>".  The
property is set to true on OpenBSD and false on other platforms.


code:
GENERATOR_IS_MULTI_CONFIG
-------------------------

.. versionadded:: 3.9

Read-only property that is true on multi-configuration generators.

True when using a multi-configuration generator such as:

* :generator:`Ninja Multi-Config`
* :ref:`Visual Studio Generators`
* :generator:`Xcode`

Multi-config generators use :variable:`CMAKE_CONFIGURATION_TYPES`
as the set of configurations and ignore :variable:`CMAKE_BUILD_TYPE`.


code:
GLOBAL_DEPENDS_DEBUG_MODE
-------------------------

Enable global target dependency graph debug mode.

CMake automatically analyzes the global inter-target dependency graph
at the beginning of native build system generation.  This property
causes it to display details of its analysis to stderr.


code:
GLOBAL_DEPENDS_NO_CYCLES
------------------------

Disallow global target dependency graph cycles.

CMake automatically analyzes the global inter-target dependency graph
at the beginning of native build system generation.  It reports an
error if the dependency graph contains a cycle that does not consist
of all STATIC library targets.  This property tells CMake to disallow
all cycles completely, even among static libraries.


code:
IN_TRY_COMPILE
--------------

Read-only property that is true during a try-compile configuration.

True when building a project inside a :command:`try_compile` or
:command:`try_run` command.


code:
JOB_POOLS
---------

Ninja only: List of available pools.

A pool is a named integer property and defines the maximum number
of concurrent jobs which can be started by a rule assigned to the pool.
The ``JOB_POOLS`` property is a semicolon-separated list of
pairs using the syntax ``NAME=integer`` (without a space after the equality sign).

For instance:

.. code-block:: cmake

  set_property(GLOBAL PROPERTY JOB_POOLS two_jobs=2 ten_jobs=10)

Defined pools could be used globally by setting
:variable:`CMAKE_JOB_POOL_COMPILE` and :variable:`CMAKE_JOB_POOL_LINK`
or per target by setting the target properties
:prop_tgt:`JOB_POOL_COMPILE` and :prop_tgt:`JOB_POOL_LINK`.
:command:`Custom commands <add_custom_command>` and
:command:`custom targets <add_custom_target>` can specify pools using the
option ``JOB_POOL``.
Using a pool that is not defined by ``JOB_POOLS`` causes
an error by ninja at build time.

If not set, this property uses the value of the :variable:`CMAKE_JOB_POOLS`
variable.

Build targets provided by CMake that are meant for individual interactive
use, such as ``install``, are placed in the ``console`` pool automatically.


code:
PACKAGES_FOUND
--------------

List of packages which were found during the CMake run.

List of packages which were found during the CMake run.  Whether a
package has been found is determined using the <NAME>_FOUND variables.


code:
PACKAGES_NOT_FOUND
------------------

List of packages which were not found during the CMake run.

List of packages which were not found during the CMake run.  Whether a
package has been found is determined using the <NAME>_FOUND variables.


code:
PREDEFINED_TARGETS_FOLDER
-------------------------

Name of FOLDER for targets that are added automatically by CMake.

If not set, CMake uses "CMakePredefinedTargets" as a default value for
this property.  Targets such as INSTALL, PACKAGE and RUN_TESTS will be
organized into this FOLDER.  See also the documentation for the
:prop_tgt:`FOLDER` target property.


code:
REPORT_UNDEFINED_PROPERTIES
---------------------------

If set, report any undefined properties to this file.

If this property is set to a filename then when CMake runs it will
report any properties or variables that were accessed but not defined
into the filename specified in this property.


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

Specify a launcher for compile rules.

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

:ref:`Makefile Generators` and the :generator:`Ninja` generator prefix
compiler commands with the given launcher command line.
This is intended to allow launchers to intercept build problems
with high granularity.  Other generators ignore this property
because their underlying build systems provide no hook to wrap
individual commands with a launcher.


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

Specify a launcher for custom rules.

:ref:`Makefile Generators` and the :generator:`Ninja` generator prefix
custom commands with the given launcher command line.
This is intended to allow launchers to intercept build problems
with high granularity.  Other generators ignore this property
because their underlying build systems provide no hook to wrap
individual commands with a launcher.


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

Specify a launcher for link rules.

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

:ref:`Makefile Generators` and the :generator:`Ninja` generator prefix
link and archive commands with the given launcher command line.
This is intended to allow launchers to intercept build problems
with high granularity.  Other generators ignore this property
because their underlying build systems provide no hook to wrap
individual commands with a launcher.


code:
RULE_MESSAGES
-------------

Specify whether to report a message for each make rule.

This property specifies whether Makefile generators should add a
progress message describing what each build rule does.  If the
property is not set the default is ON.  Set the property to OFF to
disable granular messages and report only as each target completes.
This is intended to allow scripted builds to avoid the build time cost
of detailed reports.  If a :variable:`CMAKE_RULE_MESSAGES` cache entry exists
its value initializes the value of this property.  Non-Makefile
generators currently ignore this property.


code:
TARGET_ARCHIVES_MAY_BE_SHARED_LIBS
----------------------------------

Set if shared libraries may be named like archives.

On AIX shared libraries may be named "lib<name>.a".  This property is
set to true on such platforms.


code:
TARGET_MESSAGES
---------------

.. versionadded:: 3.4

Specify whether to report the completion of each target.

This property specifies whether :ref:`Makefile Generators` should
add a progress message describing that each target has been completed.
If the property is not set the default is ``ON``.  Set the property
to ``OFF`` to disable target completion messages.

This option is intended to reduce build output when little or no
work needs to be done to bring the build tree up to date.

If a ``CMAKE_TARGET_MESSAGES`` cache entry exists its value
initializes the value of this property.

Non-Makefile generators currently ignore this property.

See the counterpart property :prop_gbl:`RULE_MESSAGES` to disable
everything except for target completion messages.


code:
TARGET_SUPPORTS_SHARED_LIBS
---------------------------

Does the target platform support shared libraries.

TARGET_SUPPORTS_SHARED_LIBS is a boolean specifying whether the target
platform supports shared libraries.  Basically all current general
general purpose OS do so, the exception are usually embedded systems
with no or special OSs.


code:
USE_FOLDERS
-----------

Controls whether to use the :prop_tgt:`FOLDER` target property to organize
targets into folders.  The value of ``USE_FOLDERS`` at the end of the top level
``CMakeLists.txt`` file is what determines the behavior.

.. versionchanged:: 3.26

  CMake treats this property as ``ON`` by default.
  See policy :policy:`CMP0143`.

Not all CMake generators support recording folder details for targets.
The :generator:`Xcode` and :ref:`Visual Studio <Visual Studio Generators>`
generators are examples of generators that do.  Similarly, not all IDEs
support presenting targets using folder hierarchies, even if the CMake
generator used provides the necessary information.


code:
XCODE_EMIT_EFFECTIVE_PLATFORM_NAME
----------------------------------

.. versionadded:: 3.8

Control emission of ``EFFECTIVE_PLATFORM_NAME`` by the :generator:`Xcode`
generator.

It is required for building the same target with multiple SDKs. A
common use case is the parallel use of ``iphoneos`` and
``iphonesimulator`` SDKs.

Three different states possible that control when the :generator:`Xcode`
generator emits the ``EFFECTIVE_PLATFORM_NAME`` variable:

- If set to ``ON`` it will always be emitted
- If set to ``OFF`` it will never be emitted
- If unset (the default) it will only be emitted when the project was
  configured for an embedded Xcode SDK like iOS, tvOS, visionOS, watchOS
  or any of the simulators.

.. note::

  When this behavior is enable for generated Xcode projects, the
  ``EFFECTIVE_PLATFORM_NAME`` variable will leak into
  :manual:`Generator expressions <cmake-generator-expressions(7)>`
  like ``TARGET_FILE`` and will render those mostly unusable.


code:
CPACK_DESKTOP_SHORTCUTS
-----------------------

.. versionadded:: 3.3

Species a list of shortcut names that should be created on the `Desktop`
for this file.

The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.


code:
CPACK_NEVER_OVERWRITE
---------------------

.. versionadded:: 3.1

Request that this file not be overwritten on install or reinstall.

The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.


code:
CPACK_PERMANENT
---------------

.. versionadded:: 3.1

Request that this file not be removed on uninstall.

The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.


code:
CPACK_STARTUP_SHORTCUTS
-----------------------

.. versionadded:: 3.3

Species a list of shortcut names that should be created in the `Startup` folder
for this file.

The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.


code:
CPACK_START_MENU_SHORTCUTS
--------------------------

.. versionadded:: 3.3

Species a list of shortcut names that should be created in the ``Start Menu``
for this file.

The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.


code:
CPACK_WIX_ACL
-------------

.. versionadded:: 3.1

Specifies access permissions for files or directories
installed by a WiX installer.

The property can contain multiple list entries,
each of which has to match the following format.

::

  <user>[@<domain>]=<permission>[,<permission>]

``<user>`` and ``<domain>`` specify the windows user and domain for which the
``<Permission>`` element should be generated.

``<permission>`` is any of the YesNoType attributes listed here::

 http://wixtoolset.org/documentation/manual/v3/xsd/wix/permission.html

The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.


code:
ABSTRACT
--------

Is this source file an abstract class.

A property on a source file that indicates if the source file
represents a class that is abstract.  This only makes sense for
languages that have a notion of an abstract class and it is only used
by some tools that wrap classes into other languages.


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.

By default it is empty.

The options set on the ``.qrc`` source file may override
:prop_tgt:`AUTORCC_OPTIONS` set on the target.

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set_property(SOURCE resources.qrc PROPERTY AUTORCC_OPTIONS "--compress;9")
  # ...


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.

By default it is empty.

The options set on the ``.ui`` source file may override
:prop_tgt:`AUTOUIC_OPTIONS` set on the target.

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set_property(SOURCE widget.ui PROPERTY AUTOUIC_OPTIONS "--no-protection")
  # ...


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

Preprocessor definitions for compiling a source file.

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).  This property may be set on a per-configuration basis using
the name ``COMPILE_DEFINITIONS_<CONFIG>`` where ``<CONFIG>`` is an upper-case
name (ex.  ``COMPILE_DEFINITIONS_DEBUG``).

CMake will automatically drop some definitions that are not supported
by the native build tool.  Xcode does not support per-configuration
definitions on source files.

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

.. include:: /include/COMPILE_DEFINITIONS_DISCLAIMER.txt

Contents of ``COMPILE_DEFINITIONS`` may use :manual:`cmake-generator-expressions(7)`
with the syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)`
manual for available expressions.  However, :generator:`Xcode`
does not support per-config per-source settings, so expressions
that depend on the build configuration are not allowed with that
generator.

Generator expressions should be preferred instead of setting the alternative per-configuration
property.


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

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

Per-configuration preprocessor definitions on a source file.

This is the configuration-specific version of :prop_tgt:`COMPILE_DEFINITIONS`.
Note that :generator:`Xcode` does not support per-configuration source
file flags so this property will be ignored by the :generator:`Xcode` generator.


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

Additional flags to be added when compiling this source file.

The ``COMPILE_FLAGS`` property, managed as a string, sets additional compiler
flags used that will be added to the list of compile flags when this source
file builds.  The flags will be added after target-wide flags (except in
some cases not supported by the :generator:`Visual Studio 9 2008` generator).

Use :prop_sf:`COMPILE_DEFINITIONS` to pass additional preprocessor definitions.

Contents of ``COMPILE_FLAGS`` may use "generator expressions"
with the syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)`
manual for available expressions.  However, :generator:`Xcode`
does not support per-config per-source settings, so expressions
that depend on the build configuration are not allowed with that
generator.

.. note::

  This property has been superseded by the :prop_sf:`COMPILE_OPTIONS` property.


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

.. versionadded:: 3.11

List of additional options to pass to the compiler.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>`
of options and will be added to the list of compile flags when this source
file builds.  The options will be added after target-wide options (except in
some cases not supported by the :generator:`Visual Studio 9 2008` generator).

Contents of ``COMPILE_OPTIONS`` may use "generator expressions" with the
syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)` manual
for available expressions.  However, :generator:`Xcode`
does not support per-config per-source settings, so expressions
that depend on the build configuration are not allowed with that
generator.

Usage example:

.. code-block:: cmake

  set_source_files_properties(foo.cpp PROPERTIES COMPILE_OPTIONS "-Wno-unused-parameter;-Wno-missing-field-initializer")

Related properties:

* Prefer this property over :prop_sf:`COMPILE_FLAGS`.
* Use :prop_sf:`COMPILE_DEFINITIONS` to pass additional preprocessor definitions.
* Use :prop_sf:`INCLUDE_DIRECTORIES` to pass additional include directories.

Related commands:

* :command:`add_compile_options` for directory-wide settings
* :command:`target_compile_options` for target-specific settings


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

.. versionadded:: 3.28

``CXX_SCAN_FOR_MODULES`` is a boolean specifying whether CMake will scan the
source for C++ module dependencies.  See also the
:prop_tgt:`CXX_SCAN_FOR_MODULES` for target-wide settings.

When this property is set ``ON``, CMake will scan the source 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 source at build time.  When
this property is unset, the :prop_tgt:`CXX_SCAN_FOR_MODULES` property is
consulted.

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


code:
EXTERNAL_OBJECT
---------------

If set to true then this is an object file.

If this property is set to ``True`` then the source file is really an
object file and should not be compiled.  It will still be linked into
the target though.


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

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

This property tells CMake whether a given Fortran source file uses
fixed-format or free-format.  CMake will pass the corresponding format flag
to the compiler.  Consider using the target-wide :prop_tgt:`Fortran_FORMAT`
property if all source files in a target share the same format.

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


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.

Consider using the target-wide :prop_tgt:`Fortran_PREPROCESS` property
if all source files in a target need to be preprocessed.


code:
GENERATED
---------

Is this source file generated as part of the build or CMake process.

.. versionchanged:: 3.20
  The GENERATED source file property is now visible in all directories.

Tells the internal CMake engine that a source file is generated by an outside
process such as another build step, or the execution of CMake itself.
This information is then used to exempt the file from any existence or
validity checks.

Any file that is

- created by the execution of commands such as
  :command:`add_custom_command` which run during the build
- listed as one of the ``BYPRODUCTS`` of an :command:`add_custom_command`
  or :command:`add_custom_target` command, or
- created by a CMake ``AUTOGEN`` operation such as :prop_tgt:`AUTOMOC`,
  :prop_tgt:`AUTORCC`, or :prop_tgt:`AUTOUIC`

will be marked with the ``GENERATED`` property.

When a generated file created as the ``OUTPUT`` of an
:command:`add_custom_command` command is explicitly listed as a source file
for any target in the same directory scope (which usually means the same
``CMakeLists.txt`` file), CMake will automatically create a dependency to
make sure the file is generated before building that target.

The :ref:`Makefile Generators` will remove ``GENERATED`` files during
``make clean``.

Generated sources may be hidden in some IDE tools, while in others they might
be shown. For the special case of sources generated by CMake's :prop_tgt:`AUTOMOC`,
:prop_tgt:`AUTORCC` or :prop_tgt:`AUTOUIC` functionality, the
:prop_gbl:`AUTOGEN_SOURCE_GROUP`, :prop_gbl:`AUTOMOC_SOURCE_GROUP`,
:prop_gbl:`AUTORCC_SOURCE_GROUP` and :prop_gbl:`AUTOUIC_SOURCE_GROUP` target
properties may influence where the generated sources are grouped in the project's
file lists.

.. note::

  Starting with CMake 3.20 the ``GENERATED`` source file property can be set
  and retrieved from any directory scope. It is an all-or-nothing property.
  It also can no longer be removed or unset if it was set to ``TRUE``. Policy
  :policy:`CMP0118` was introduced to allow supporting the ``OLD`` behavior
  for some time.


code:
HEADER_FILE_ONLY
----------------

Is this source file only a header file.

A property on a source file that indicates if the source file is a
header file with no associated implementation.  This is set
automatically based on the file extension and is used by CMake to
determine if certain dependency information should be computed.

By setting this property to ``ON``, you can disable compilation of
the given source file, even if it should be compiled because it is
part of the library's/executable's sources.

This is useful if you have some source files which you somehow
pre-process, and then add these pre-processed sources via
:command:`add_library` or :command:`add_executable`. Normally, in IDE,
there would be no reference of the original sources, only of these
pre-processed sources. So by setting this property for all the original
source files to ``ON``, and then either calling :command:`add_library`
or :command:`add_executable` while passing both the pre-processed
sources and the original sources, or by using :command:`target_sources`
to add original source files will do exactly what would one expect, i.e.
the original source files would be visible in IDE, and will not be built.


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

.. versionadded:: 3.11

List of preprocessor include file search directories.

This property holds a :ref:`semicolon-separated list <CMake Language Lists>` of paths
and will be added to the list of include directories when this
source file builds. These directories will take precedence over directories
defined at target level except for :generator:`Xcode` generator due to technical
limitations.

Relative paths should not be added to this property directly.

Contents of ``INCLUDE_DIRECTORIES`` may use "generator expressions" with
the syntax ``$<...>``.  See the :manual:`cmake-generator-expressions(7)` manual
for available expressions.  However, :generator:`Xcode` does not support
per-config per-source settings, so expressions that depend on the build
configuration are not allowed with that generator.


code:
KEEP_EXTENSION
--------------

Make the output file have the same extension as the source file.

If this property is set then the file extension of the output file
will be the same as that of the source file.  Normally the output file
extension is computed based on the language of the source file, for
example ``.cxx`` will go to a ``.o`` extension.


code:
LABELS
------

Specify a list of text labels associated with a source file.

This property has meaning only when the source file is listed in a
target whose ``LABELS`` property is also set.  No other semantics are
currently specified.


code:
LANGUAGE
--------

Specify the programming language in which a source file is written.

A property that can be set to indicate what programming language the
source file is.  If it is not set the language is determined based on
the file extension.  Typical values are ``CXX`` (i.e.  C++), ``C``,
``CSharp``, ``CUDA``, ``Fortran``, ``HIP``, ``ISPC``, and ``ASM``.  Setting
this property for a file means this file will be compiled, unless
:prop_sf:`HEADER_FILE_ONLY` is set.

.. versionchanged:: 3.20
  Setting this property causes the source file to be compiled as the
  specified language, using explicit flags if possible.  Previously it
  only caused the specified language's compiler to be used.
  See policy :policy:`CMP0119`.


code:
LOCATION
--------

The full path to a source file.

A read only property on a SOURCE FILE that contains the full path to
the source file.


code:
MACOSX_PACKAGE_LOCATION
-----------------------

Place a source file inside a Application Bundle
(:prop_tgt:`MACOSX_BUNDLE`), Core Foundation Bundle (:prop_tgt:`BUNDLE`),
or Framework Bundle (:prop_tgt:`FRAMEWORK`).  It is applicable for macOS
and iOS.

Executable targets with the :prop_tgt:`MACOSX_BUNDLE` property set are
built as macOS or iOS application bundles on Apple platforms.  Shared
library targets with the :prop_tgt:`FRAMEWORK` property set are built as
macOS or iOS frameworks on Apple platforms.  Module library targets with
the :prop_tgt:`BUNDLE` property set are built as macOS ``CFBundle`` bundles
on Apple platforms.  Source files listed in the target with this property
set will be copied to a directory inside the bundle or framework content
folder specified by the property value.  For macOS Application Bundles the
content folder is ``<name>.app/Contents``.  For macOS Frameworks the
content folder is ``<name>.framework/Versions/<version>``.  For macOS
CFBundles the content folder is ``<name>.bundle/Contents`` (unless the
extension is changed).  See the :prop_tgt:`PUBLIC_HEADER`,
:prop_tgt:`PRIVATE_HEADER`, and :prop_tgt:`RESOURCE` target properties for
specifying files meant for ``Headers``, ``PrivateHeaders``, or
``Resources`` directories.

If the specified location is equal to ``Resources``, the resulting location
will be the same as if the :prop_tgt:`RESOURCE` property had been used. If
the specified location is a sub-folder of ``Resources``, it will be placed
into the respective sub-folder. Note: For iOS Apple uses a flat bundle layout
where no ``Resources`` folder exist. Therefore CMake strips the ``Resources``
folder name from the specified location.


code:
OBJECT_DEPENDS
--------------

Additional files on which a compiled object file depends.

Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of full-paths to
files on which any object files compiled from this source file depend.
On :ref:`Makefile Generators` and the :generator:`Ninja` generator an
object file will be recompiled if any of the named files is newer than it.
:ref:`Visual Studio Generators` and the :generator:`Xcode` generator
cannot implement such compilation dependencies.

This property need not be used to specify the dependency of a source
file on a generated header file that it includes.  Although the
property was originally introduced for this purpose, it is no longer
necessary.  If the generated header file is created by a custom
command in the same target as the source file, the automatic
dependency scanning process will recognize the dependency.  If the
generated header file is created by another target, an inter-target
dependency should be created with the :command:`add_dependencies`
command (if one does not already exist due to linking relationships).


code:
OBJECT_OUTPUTS
--------------

Additional outputs for a :generator:`Ninja` or :ref:`Makefile Generators` rule.

Additional outputs created by compilation of this source file.  If any
of these outputs is missing the object will be recompiled.  This is
supported only on the :generator:`Ninja` and :ref:`Makefile Generators`
and will be ignored on other generators.

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


code:
SKIP_AUTOGEN
------------

.. versionadded:: 3.8

Exclude the source file from :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTOUIC` and
:prop_tgt:`AUTORCC` processing (for Qt projects).

For finer exclusion control see :prop_sf:`SKIP_AUTOMOC`,
:prop_sf:`SKIP_AUTOUIC` and :prop_sf:`SKIP_AUTORCC`.

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set_property(SOURCE file.h PROPERTY SKIP_AUTOGEN ON)
  # ...


code:
SKIP_AUTOMOC
------------

.. versionadded:: 3.8

Exclude the source file from :prop_tgt:`AUTOMOC` processing (for Qt projects).

For broader exclusion control see :prop_sf:`SKIP_AUTOGEN`.

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set_property(SOURCE file.h PROPERTY SKIP_AUTOMOC ON)
  # ...


code:
SKIP_AUTORCC
------------

.. versionadded:: 3.8

Exclude the source file from :prop_tgt:`AUTORCC` processing (for Qt projects).

For broader exclusion control see :prop_sf:`SKIP_AUTOGEN`.

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set_property(SOURCE file.qrc PROPERTY SKIP_AUTORCC ON)
  # ...


code:
SKIP_AUTOUIC
------------

.. versionadded:: 3.8

Exclude the source file from :prop_tgt:`AUTOUIC` processing (for Qt projects).

``SKIP_AUTOUIC`` can be set on C++ header and source files and on
``.ui`` files.

For broader exclusion control see :prop_sf:`SKIP_AUTOGEN`.

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set_property(SOURCE file.h PROPERTY SKIP_AUTOUIC ON)
  set_property(SOURCE file.cpp PROPERTY SKIP_AUTOUIC ON)
  set_property(SOURCE widget.ui PROPERTY SKIP_AUTOUIC ON)
  # ...


code:
SKIP_LINTING
------------

.. versionadded:: 3.27

This property allows you to exclude a specific source file
from the linting process. The linting process involves running
tools such as :prop_tgt:`<LANG>_CPPLINT`, :prop_tgt:`<LANG>_CLANG_TIDY`,
:prop_tgt:`<LANG>_CPPCHECK`, and :prop_tgt:`<LANG>_INCLUDE_WHAT_YOU_USE`
on the source files, as well as compiling header files as part of
:prop_tgt:`VERIFY_INTERFACE_HEADER_SETS`. By setting ``SKIP_LINTING`` on a
source file, the mentioned linting tools will not be executed for that
particular file.

Example
^^^^^^^

Consider a C++ project that includes multiple source files,
such as ``main.cpp``, ``things.cpp``, and ``generatedBindings.cpp``.
In this example, you want to exclude the ``generatedBindings.cpp``
file from the linting process. To achieve this, you can utilize
the ``SKIP_LINTING`` property with the :command:`set_source_files_properties`
command as shown below:

.. code-block:: cmake

  add_executable(MyApp main.cpp things.cpp generatedBindings.cpp)

  set_source_files_properties(generatedBindings.cpp PROPERTIES
      SKIP_LINTING ON
  )

In the provided code snippet, the ``SKIP_LINTING`` property is set to true
for the ``generatedBindings.cpp`` source file. As a result, when the linting
tools specified by :prop_tgt:`<LANG>_CPPLINT`, :prop_tgt:`<LANG>_CLANG_TIDY`,
:prop_tgt:`<LANG>_CPPCHECK`, or :prop_tgt:`<LANG>_INCLUDE_WHAT_YOU_USE`
are executed, they will skip analyzing the ``generatedBindings.cpp`` file.

By using the ``SKIP_LINTING`` property, you can selectively exclude specific
source files from the linting process. This allows you to focus the
linting tools on the relevant parts of your project, enhancing the efficiency
and effectiveness of the linting workflow.


code:
SKIP_PRECOMPILE_HEADERS
-----------------------

.. versionadded:: 3.16

Is this source file skipped by :prop_tgt:`PRECOMPILE_HEADERS` feature.

This property helps with build problems that one would run into
when using the :prop_tgt:`PRECOMPILE_HEADERS` feature.

One example would be the usage of Objective-C (``*.m``) files, and
Objective-C++ (``*.mm``) files, which lead to compilation failure
because they are treated (in case of Ninja / Makefile generator)
as C, and CXX respectively. The precompile headers are not
compatible between languages.


code:
SKIP_UNITY_BUILD_INCLUSION
--------------------------

.. versionadded:: 3.16

Setting this property to true ensures the source file will be skipped by
unity builds when its associated target has its :prop_tgt:`UNITY_BUILD`
property set to true.  The source file will instead be compiled on its own
in the same way as it would with unity builds disabled.

This property helps with "ODR (One definition rule)" problems where combining
a particular source file with others might lead to build errors or other
unintended side effects.

Note that sources which are scanned for C++ modules (see
:manual:`cmake-cxxmodules(7)`) are not eligible for unity build inclusion and
will automatically be excluded.


code:
SYMBOLIC
--------

Is this just a name for a rule.

If ``SYMBOLIC`` (boolean) is set to ``True`` the build system will be informed
that the source file is not actually created on disk but instead used
as a symbolic name for a build rule.


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

.. versionadded:: 3.15

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


code:
Swift_DIAGNOSTICS_FILE
----------------------

.. versionadded:: 3.15

This property controls where the Swift diagnostics are serialized.


code:
UNITY_GROUP
-----------

.. versionadded:: 3.18

This property controls which *bucket* the source will be part of when
the :prop_tgt:`UNITY_BUILD_MODE` is set to ``GROUP``.


code:
VS_COPY_TO_OUT_DIR
------------------

.. versionadded:: 3.8

Sets the ``<CopyToOutputDirectory>`` tag for a source file in a
Visual Studio project file. Valid values are ``Never``, ``Always``
and ``PreserveNewest``.


code:
VS_CSHARP_<tagname>
-------------------

.. versionadded:: 3.8

Visual Studio and CSharp source-file-specific configuration.

Tell the :manual:`Visual Studio generators <cmake-generators(7)>`
to set the source file tag ``<tagname>``
to a given value in the generated Visual Studio CSharp
project. Ignored on other generators and languages. This property
can be used to define dependencies between source files or set any
other Visual Studio specific parameters.

Example usage:

.. code-block:: cmake

  set_source_files_properties(<filename>
           PROPERTIES
           VS_CSHARP_DependentUpon <other file>
           VS_CSHARP_SubType "Form")


code:
VS_DEPLOYMENT_CONTENT
---------------------

.. versionadded:: 3.1

Mark a source file as content for deployment with a Windows Phone or
Windows Store application when built with a
:manual:`Visual Studio generators <cmake-generators(7)>`.
The value must evaluate to either ``1`` or ``0`` and may use
:manual:`generator expressions <cmake-generator-expressions(7)>`
to make the choice based on the build configuration.
The ``.vcxproj`` file entry for the source file will be
marked either ``DeploymentContent`` or ``ExcludedFromBuild``
for values ``1`` and ``0``, respectively.


code:
VS_DEPLOYMENT_LOCATION
----------------------

.. versionadded:: 3.1

Specifies the deployment location for a content source file with a Windows
Phone or Windows Store application when built
with a :manual:`Visual Studio generators <cmake-generators(7)>`.
This property is only applicable when using :prop_sf:`VS_DEPLOYMENT_CONTENT`.
The value represent the path relative to the app package and applies to all
configurations.


code:
VS_INCLUDE_IN_VSIX
------------------

.. versionadded:: 3.8

Boolean property to specify if the file should be included within a
VSIX (Visual Studio Integration Extension) extension package.
This is needed for development of Visual Studio extensions.


code:
VS_RESOURCE_GENERATOR
---------------------

.. versionadded:: 3.8

This property allows to specify the resource generator to be used
on this file. It defaults to ``PublicResXFileCodeGenerator`` if
not set.

This property only applies to C# projects.


code:
VS_SETTINGS
-----------

.. versionadded:: 3.18

Set any item metadata on a file.

.. versionadded:: 3.22

  This property is honored for all source file types.
  Previously it worked only for non-built files.

Takes a list of ``Key=Value`` pairs. Tells the Visual Studio generator to set
``Key`` to ``Value`` as item metadata on the file.

For example:

.. code-block:: cmake

  set_property(SOURCE file.hlsl PROPERTY VS_SETTINGS "Key=Value" "Key2=Value2")

will set ``Key`` to ``Value`` and ``Key2`` to ``Value2`` on the
``file.hlsl`` item as metadata.

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


code:
VS_SHADER_DISABLE_OPTIMIZATIONS
-------------------------------

.. versionadded:: 3.11

Disable compiler optimizations for an ``.hlsl`` source file.  This adds the
``-Od`` flag to the command line for the FxCompiler tool.  Specify the value
``true`` for this property to disable compiler optimizations.


code:
VS_SHADER_ENABLE_DEBUG
----------------------

.. versionadded:: 3.11

Enable debugging information for an ``.hlsl`` source file.  This adds the
``-Zi`` flag to the command line for the FxCompiler tool.  Specify the value
``true`` to generate debugging information for the compiled shader.


code:
VS_SHADER_ENTRYPOINT
--------------------

.. versionadded:: 3.1

Specifies the name of the entry point for the shader of a ``.hlsl`` source
file.


code:
VS_SHADER_FLAGS
---------------

.. versionadded:: 3.2

Set additional Visual Studio shader flags of a ``.hlsl`` source file.


code:
VS_SHADER_MODEL
---------------

.. versionadded:: 3.1

Specifies the shader model of a ``.hlsl`` source file. Some shader types can
only be used with recent shader models


code:
VS_SHADER_OBJECT_FILE_NAME
--------------------------

.. versionadded:: 3.12

Specifies a file name for the compiled shader object file for an ``.hlsl``
source file.  This adds the ``-Fo`` flag to the command line for the FxCompiler
tool.


code:
VS_SHADER_OUTPUT_HEADER_FILE
----------------------------

.. versionadded:: 3.10

Set filename for output header file containing object code of a ``.hlsl``
source file.


code:
VS_SHADER_TYPE
--------------

.. versionadded:: 3.1

Set the Visual Studio shader type of a ``.hlsl`` source file.


code:
VS_SHADER_VARIABLE_NAME
-----------------------

.. versionadded:: 3.10

Set name of variable in header file containing object code of a ``.hlsl``
source file.


code:
VS_TOOL_OVERRIDE
----------------

.. versionadded:: 3.7

Override the default Visual Studio tool that will be applied to the source file
with a new tool not based on the extension of the file.


code:
VS_XAML_TYPE
------------

.. versionadded:: 3.3

Mark a Extensible Application Markup Language (XAML) source file
as a different type than the default ``Page``.
The most common usage would be to set the default ``App.xaml`` file as
``ApplicationDefinition``.


code:
WRAP_EXCLUDE
------------

Exclude this source file from any code wrapping techniques.

Some packages can wrap source files into alternate languages to
provide additional functionality.

For example, C++ code can be wrapped into Java or Python, using SWIG.
If ``WRAP_EXCLUDE`` is set to ``True``, that indicates that this
source file should not be wrapped.


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

.. versionadded:: 3.1

Set the :generator:`Xcode` ``explicitFileType`` attribute on its reference to a
source file.  CMake computes a default based on file extension but
can be told explicitly with this property.

See also :prop_sf:`XCODE_LAST_KNOWN_FILE_TYPE`.


code:
XCODE_FILE_ATTRIBUTES
---------------------

.. versionadded:: 3.7

Add values to the :generator:`Xcode` ``ATTRIBUTES`` setting on its reference to a
source file.  Among other things, this can be used to set the role on
a ``.mig`` file::

  set_source_files_properties(defs.mig
      PROPERTIES
          XCODE_FILE_ATTRIBUTES "Client;Server"
  )


code:
XCODE_LAST_KNOWN_FILE_TYPE
--------------------------

.. versionadded:: 3.1

Set the :generator:`Xcode` ``lastKnownFileType`` attribute on its reference to
a source file.  CMake computes a default based on file extension but
can be told explicitly with this property.

See also :prop_sf:`XCODE_EXPLICIT_FILE_TYPE`, which is preferred
over this property if set.


code:
ATTACHED_FILES
--------------

Attach a list of files to a dashboard submission.

Set this property to a list of files that will be encoded and
submitted to the dashboard as an addition to the test result.


code:
ATTACHED_FILES_ON_FAIL
----------------------

Attach a list of files to a dashboard submission if the test fails.

Same as :prop_test:`ATTACHED_FILES`, but these files will only be
included if the test does not pass.


code:
COST
----

This property describes the cost of a test.  When parallel testing is
enabled, tests in the test set will be run in descending order of cost.
Projects can explicitly define the cost of a test by setting this property
to a floating point value.

When the cost of a test is not defined by the project,
:manual:`ctest <ctest(1)>` will initially use a default cost of ``0``.
It computes a weighted average of the cost each time a test is run and
uses that as an improved estimate of the cost for the next run.  The more
a test is re-run in the same build directory, the more representative the
cost should become.


code:
DEPENDS
-------

Specifies that this test should only be run after the specified list of tests.

Set this to a list of tests that must finish before this test is run. The
results of those tests are not considered, the dependency relationship is
purely for order of execution (i.e. it is really just a *run after*
relationship). Consider using test fixtures with setup tests if a dependency
with successful completion is required (see :prop_test:`FIXTURES_REQUIRED`).

Examples
~~~~~~~~

.. code-block:: cmake

  add_test(NAME baseTest1 ...)
  add_test(NAME baseTest2 ...)
  add_test(NAME dependsTest12 ...)

  set_tests_properties(dependsTest12 PROPERTIES DEPENDS "baseTest1;baseTest2")
  # dependsTest12 runs after baseTest1 and baseTest2, even if they fail


code:
DISABLED
--------

.. versionadded:: 3.9

If set to ``True``, the test will be skipped and its status will be 'Not Run'. A
``DISABLED`` test will not be counted in the total number of tests and its
completion status will be reported to CDash as ``Disabled``.

A ``DISABLED`` test does not participate in test fixture dependency resolution.
If a ``DISABLED`` test has fixture requirements defined in its
:prop_test:`FIXTURES_REQUIRED` property, it will not cause setup or cleanup
tests for those fixtures to be added to the test set.

If a test with the :prop_test:`FIXTURES_SETUP` property set is ``DISABLED``,
the fixture behavior will be as though that setup test was passing and any test
case requiring that fixture will still run.


code:
ENVIRONMENT
-----------

Specify environment variables that should be defined for running a test.

Set to a :ref:`semicolon-separated list <CMake Language Lists>` list
of environment variables and values of the form ``MYVAR=value``.
Those environment variables will be defined while running the test.
The environment changes from this property do not affect other tests.


code:
ENVIRONMENT_MODIFICATION
------------------------

.. versionadded:: 3.22

Specify environment variables that should be modified for running a test. Note
that the operations performed by this property are performed after the
:prop_test:`ENVIRONMENT` property is already applied.

Set to a :ref:`semicolon-separated list <CMake Language Lists>` of
environment variables and values of the form ``MYVAR=OP:VALUE``,
where ``MYVAR`` is the case-sensitive name of an environment variable
to be modified.  Entries are considered in the order specified in the
property's value.  The ``OP`` may be one of:

  - ``reset``: Reset to the unmodified value, ignoring all modifications to
    ``MYVAR`` prior to this entry. Note that this will reset the variable to
    the value set by :prop_test:`ENVIRONMENT`, if it was set, and otherwise
    to its state from the rest of the CTest execution.
  - ``set``: Replaces the current value of ``MYVAR`` with ``VALUE``.
  - ``unset``: Unsets the current value of ``MYVAR``.
  - ``string_append``: Appends singular ``VALUE`` to the current value of
    ``MYVAR``.
  - ``string_prepend``: Prepends singular ``VALUE`` to the current value of
    ``MYVAR``.
  - ``path_list_append``: Appends singular ``VALUE`` to the current value of
    ``MYVAR`` using the host platform's path list separator (``;`` on Windows
    and ``:`` elsewhere).
  - ``path_list_prepend``: Prepends singular ``VALUE`` to the current value of
    ``MYVAR`` using the host platform's path list separator (``;`` on Windows
    and ``:`` elsewhere).
  - ``cmake_list_append``: Appends singular ``VALUE`` to the current value of
    ``MYVAR`` using ``;`` as the separator.
  - ``cmake_list_prepend``: Prepends singular ``VALUE`` to the current value of
    ``MYVAR`` using ``;`` as the separator.

Unrecognized ``OP`` values will result in the test failing before it is
executed. This is so that future operations may be added without changing
valid behavior of existing tests.

The environment changes from this property do not affect other tests.


code:
FAIL_REGULAR_EXPRESSION
-----------------------

If the test output (stdout or stderr) matches this regular expression the test
will fail, regardless of the process exit code. Tests that exceed the timeout
specified by :prop_test:`TIMEOUT` fail regardless of
``FAIL_REGULAR_EXPRESSION``. Any non-zero return code or system-level test
failures including segmentation faults, signal abort, or heap errors fail the
test even if the regular expression does not match.

If set, if the output matches one of specified regular expressions, the test
will fail.  Example:

.. code-block:: cmake

  # test would pass, except for FAIL_REGULAR_EXPRESSION
  add_test(NAME mytest COMMAND ${CMAKE_COMMAND} -E echo "Failed")

  set_property(TEST mytest PROPERTY
    FAIL_REGULAR_EXPRESSION "[^a-z]Error;ERROR;Failed"
  )

``FAIL_REGULAR_EXPRESSION`` expects a list of regular expressions.

See also the :prop_test:`PASS_REGULAR_EXPRESSION` and
:prop_test:`SKIP_REGULAR_EXPRESSION` test properties.


code:
FIXTURES_CLEANUP
----------------

.. versionadded:: 3.7

Specifies a list of fixtures for which the test is to be treated as a cleanup
test. These fixture names are distinct from test case names and are not
required to have any similarity to the names of tests associated with them.

Fixture cleanup tests are ordinary tests with all of the usual test
functionality. Setting the ``FIXTURES_CLEANUP`` property for a test has two
primary effects:

- CTest will ensure the test executes after all other tests which list any of
  the fixtures in its :prop_test:`FIXTURES_REQUIRED` property.

- If CTest is asked to run only a subset of tests (e.g. using regular
  expressions or the ``--rerun-failed`` option) and the cleanup test is not in
  the set of tests to run, it will automatically be added if any tests in the
  set require any fixture listed in ``FIXTURES_CLEANUP``.

A cleanup test can have multiple fixtures listed in its ``FIXTURES_CLEANUP``
property. It will execute only once for the whole CTest run, not once for each
fixture. A fixture can also have more than one cleanup test defined. If there
are multiple cleanup tests for a fixture, projects can control their order with
the usual :prop_test:`DEPENDS` test property if necessary.

A cleanup test is allowed to require other fixtures, but not any fixture listed
in its ``FIXTURES_CLEANUP`` property. For example:

.. code-block:: cmake

  # Ok: Dependent fixture is different to cleanup
  set_tests_properties(cleanupFoo PROPERTIES
    FIXTURES_CLEANUP  Foo
    FIXTURES_REQUIRED Bar
  )

  # Error: cannot require same fixture as cleanup
  set_tests_properties(cleanupFoo PROPERTIES
    FIXTURES_CLEANUP  Foo
    FIXTURES_REQUIRED Foo
  )

Cleanup tests will execute even if setup or regular tests for that fixture fail
or are skipped.

See :prop_test:`FIXTURES_REQUIRED` for a more complete discussion of how to use
test fixtures.