code:
FIXTURES_REQUIRED
-----------------

.. versionadded:: 3.7

Specifies a list of fixtures the test requires. Fixture names are case
sensitive and they are not required to have any similarity to test names.

Fixtures are a way to attach setup and cleanup tasks to a set of tests. If a
test requires a given fixture, then all tests marked as setup tasks for that
fixture will be executed first (once for the whole set of tests, not once per
test requiring the fixture). After all tests requiring a particular fixture
have completed, CTest will ensure all tests marked as cleanup tasks for that
fixture are then executed. Tests are marked as setup tasks with the
:prop_test:`FIXTURES_SETUP` property and as cleanup tasks with the
:prop_test:`FIXTURES_CLEANUP` property. If any of a fixture's setup tests fail,
all tests listing that fixture in their ``FIXTURES_REQUIRED`` property will not
be executed. The cleanup tests for the fixture will always be executed, even if
some setup tests fail.

When CTest is asked to execute only a subset of tests (e.g. by the use of
regular expressions or when run with the :option:`--rerun-failed <ctest --rerun-failed>`
command line option), it will automatically add any setup or cleanup tests for
fixtures required by any of the tests that are in the execution set. This
behavior can be overridden with the :option:`-FS <ctest -FS>`,
:option:`-FC <ctest -FC>` and :option:`-FA <ctest -FA>` command line options to
:manual:`ctest(1)` if desired.

Since setup and cleanup tasks are also tests, they can have an ordering
specified by the :prop_test:`DEPENDS` test property just like any other tests.
This can be exploited to implement setup or cleanup using multiple tests for a
single fixture to modularise setup or cleanup logic.

The concept of a fixture is different to that of a resource specified by
:prop_test:`RESOURCE_LOCK`, but they may be used together. A fixture defines a
set of tests which share setup and cleanup requirements, whereas a resource
lock has the effect of ensuring a particular set of tests do not run in
parallel. Some situations may need both, such as setting up a database,
serializing test access to that database and deleting the database again at the
end. For such cases, tests would populate both ``FIXTURES_REQUIRED`` and
:prop_test:`RESOURCE_LOCK` to combine the two behaviors. Names used for
:prop_test:`RESOURCE_LOCK` have no relationship with names of fixtures, so note
that a resource lock does not imply a fixture and vice versa.

Consider the following example which represents a database test scenario
similar to that mentioned above:

.. code-block:: cmake

  add_test(NAME testsDone   COMMAND emailResults)
  add_test(NAME fooOnly     COMMAND testFoo)
  add_test(NAME dbOnly      COMMAND testDb)
  add_test(NAME dbWithFoo   COMMAND testDbWithFoo)
  add_test(NAME createDB    COMMAND initDB)
  add_test(NAME setupUsers  COMMAND userCreation)
  add_test(NAME cleanupDB   COMMAND deleteDB)
  add_test(NAME cleanupFoo  COMMAND removeFoos)

  set_tests_properties(setupUsers PROPERTIES DEPENDS createDB)

  set_tests_properties(createDB   PROPERTIES FIXTURES_SETUP    DB)
  set_tests_properties(setupUsers PROPERTIES FIXTURES_SETUP    DB)
  set_tests_properties(cleanupDB  PROPERTIES FIXTURES_CLEANUP  DB)
  set_tests_properties(cleanupFoo PROPERTIES FIXTURES_CLEANUP  Foo)
  set_tests_properties(testsDone  PROPERTIES FIXTURES_CLEANUP  "DB;Foo")

  set_tests_properties(fooOnly    PROPERTIES FIXTURES_REQUIRED Foo)
  set_tests_properties(dbOnly     PROPERTIES FIXTURES_REQUIRED DB)
  set_tests_properties(dbWithFoo  PROPERTIES FIXTURES_REQUIRED "DB;Foo")

  set_tests_properties(dbOnly dbWithFoo createDB setupUsers cleanupDB
                       PROPERTIES RESOURCE_LOCK DbAccess)

Key points from this example:

- Two fixtures are defined: ``DB`` and ``Foo``. Tests can require a single
  fixture as ``fooOnly`` and ``dbOnly`` do, or they can depend on multiple
  fixtures like ``dbWithFoo`` does.

- A ``DEPENDS`` relationship is set up to ensure ``setupUsers`` happens after
  ``createDB``, both of which are setup tests for the ``DB`` fixture and will
  therefore be executed before the ``dbOnly`` and ``dbWithFoo`` tests
  automatically.

- No explicit ``DEPENDS`` relationships were needed to make the setup tests run
  before or the cleanup tests run after the regular tests.

- The ``Foo`` fixture has no setup tests defined, only a single cleanup test.

- ``testsDone`` is a cleanup test for both the ``DB`` and ``Foo`` fixtures.
  Therefore, it will only execute once regular tests for both fixtures have
  finished (i.e. after ``fooOnly``, ``dbOnly`` and ``dbWithFoo``). No
  ``DEPENDS`` relationship was specified for ``testsDone``, so it is free to
  run before, after or concurrently with other cleanup tests for either
  fixture.

- The setup and cleanup tests never list the fixtures they are for in their own
  ``FIXTURES_REQUIRED`` property, as that would result in a dependency on
  themselves and be considered an error.


code:
FIXTURES_SETUP
--------------

.. versionadded:: 3.7

Specifies a list of fixtures for which the test is to be treated as a setup
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 setup tests are ordinary tests with all of the usual test
functionality. Setting the ``FIXTURES_SETUP`` property for a test has two
primary effects:

- CTest will ensure the test executes before any other test which lists the
  fixture name(s) 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 setup 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_SETUP``.

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

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

.. code-block:: cmake

  # Ok: dependent fixture is different to setup
  set_tests_properties(setupFoo PROPERTIES
    FIXTURES_SETUP    Foo
    FIXTURES_REQUIRED Bar
  )

  # Error: cannot require same fixture as setup
  set_tests_properties(setupFoo PROPERTIES
    FIXTURES_SETUP    Foo
    FIXTURES_REQUIRED Foo
  )

If any of a fixture's setup tests fail, none of the tests listing that fixture
in its :prop_test:`FIXTURES_REQUIRED` property will be run. Cleanup tests will,
however, still be executed.

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

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
GENERATED_RESOURCE_SPEC_FILE
----------------------------

.. versionadded:: 3.28

Path to the :ref:`dynamically-generated resource spec file
<ctest-resource-dynamically-generated-spec-file>` generated by this test.


code:
LABELS
------

Specify a list of text labels associated with a test.  The labels are
reported in both the :program:`ctest` output summary and in dashboard submissions.
They can also be used to filter the set of tests to be executed (see the
:option:`ctest -L` and :option:`ctest -LE` options).

See :ref:`Additional Labels` for adding labels to a test dynamically during
test execution.


code:
MEASUREMENT
-----------

Specify a ``CDASH`` measurement and value to be reported for a test.

If set to a name then that name will be reported to ``CDASH`` as a named
measurement with a value of ``1``.  You may also specify a value by
setting ``MEASUREMENT`` to ``measurement=value``.


code:
PASS_REGULAR_EXPRESSION
-----------------------

The test output (stdout or stderr) must match this regular expression
for the test to pass. The process exit code is ignored. Tests that exceed
the timeout specified by :prop_test:`TIMEOUT` still fail regardless of
``PASS_REGULAR_EXPRESSION``. System-level test failures including
segmentation faults, signal abort, or heap errors may fail the test even
if ``PASS_REGULAR_EXPRESSION`` is matched.

Example:

.. code-block:: cmake

  add_test(NAME mytest COMMAND ${CMAKE_COMMAND} -E echo "Passed this test")

  set_property(TEST mytest PROPERTY
    PASS_REGULAR_EXPRESSION "pass;Passed"
  )

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

To run a test that may have a system-level failure, but still pass if
``PASS_REGULAR_EXPRESSION`` matches, use a CMake command to wrap the
executable run. Note that this will prevent automatic handling of the
:prop_tgt:`CROSSCOMPILING_EMULATOR` and :prop_tgt:`TEST_LAUNCHER`
target property.

.. code-block:: cmake

    add_executable(main main.c)

    add_test(NAME sigabrt COMMAND ${CMAKE_COMMAND} -E env $<TARGET_FILE:main>)

    set_property(TEST sigabrt PROPERTY PROPERTY_REGULAR_EXPRESSION "pass;Passed")

.. code-block:: c

    #include <signal.h>
    #include <stdio.h>

    int main(void){
        fprintf(stdout, "Passed\n");
        fflush(stdout);  /* ensure the output buffer is seen */
        raise(SIGABRT);
        return 0;
    }

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


code:
PROCESSORS
----------

Set to specify how many process slots this test requires.
If not set, the default is ``1`` processor.

Denotes the number of processors that this test will require.  This is
typically used for MPI tests, and should be used in conjunction with
the :command:`ctest_test` ``PARALLEL_LEVEL`` option.

This will also be used to display a weighted test timing result in label and
subproject summaries in the command line output of :manual:`ctest(1)`. The wall
clock time for the test run will be multiplied by this property to give a
better idea of how much cpu resource CTest allocated for the test.

See also the :prop_test:`PROCESSOR_AFFINITY` test property.


code:
PROCESSOR_AFFINITY
------------------

.. versionadded:: 3.12

Set to a true value to ask CTest to launch the test process with CPU affinity
for a fixed set of processors.  If enabled and supported for the current
platform, CTest will choose a set of processors to place in the CPU affinity
mask when launching the test process.  The number of processors in the set is
determined by the :prop_test:`PROCESSORS` test property or the number of
processors available to CTest, whichever is smaller.  The set of processors
chosen will be disjoint from the processors assigned to other concurrently
running tests that also have the ``PROCESSOR_AFFINITY`` property enabled.


code:
REQUIRED_FILES
--------------

List of files required to run the test.  The filenames are relative to the
test :prop_test:`WORKING_DIRECTORY` unless an absolute path is specified.

If set to a list of files, the test will not be run unless all of the
files exist.

Examples
~~~~~~~~

Suppose that ``test.txt`` is created by test ``baseTest`` and ``none.txt``
does not exist:

.. code-block:: cmake

  add_test(NAME baseTest ...)   # Assumed to create test.txt
  add_test(NAME fileTest ...)

  # The following ensures that if baseTest is successful, test.txt will
  # have been created before fileTest is run
  set_tests_properties(fileTest PROPERTIES
    DEPENDS baseTest
    REQUIRED_FILES test.txt
  )

  add_test(NAME notRunTest ...)

  # The following makes notRunTest depend on two files. Nothing creates
  # the none.txt file, so notRunTest will fail with status "Not Run".
  set_tests_properties(notRunTest PROPERTIES
    REQUIRED_FILES "test.txt;none.txt"
  )

The above example demonstrates how ``REQUIRED_FILES`` works, but it is not the
most robust way to implement test ordering with failure detection.  For that,
test fixtures are a better alternative (see :prop_test:`FIXTURES_REQUIRED`).


code:
RESOURCE_GROUPS
---------------

.. versionadded:: 3.16

Specify resources required by a test, grouped in a way that is meaningful to
the test.  See :ref:`resource allocation <ctest-resource-allocation>`
for more information on how this property integrates into the CTest resource
allocation feature.

The ``RESOURCE_GROUPS`` property is a :ref:`semicolon-separated list <CMake
Language Lists>` of group descriptions. Each entry consists of an optional
number of groups using the description followed by a series of resource
requirements for those groups. These requirements (and the number of groups)
are separated by commas. The resource requirements consist of the name of a
resource type, followed by a colon, followed by an unsigned integer
specifying the number of slots required on one resource of the given type.

The ``RESOURCE_GROUPS`` property tells CTest what resources a test expects
to use grouped in a way meaningful to the test.  The test itself must read
the :ref:`environment variables <ctest-resource-environment-variables>` to
determine which resources have been allocated to each group.  For example,
each group may correspond to a process the test will spawn when executed.

Consider the following example:

.. code-block:: cmake

  add_test(NAME MyTest COMMAND MyExe)
  set_property(TEST MyTest PROPERTY RESOURCE_GROUPS
    "2,gpus:2"
    "gpus:4,crypto_chips:2")

In this example, there are two group descriptions (implicitly separated by a
semicolon.) The content of the first description is ``2,gpus:2``. This
description specifies 2 groups, each of which requires 2 slots from a single
GPU. The content of the second description is ``gpus:4,crypto_chips:2``. This
description does not specify a group count, so a default of 1 is assumed.
This single group requires 4 slots from a single GPU and 2 slots from a
single cryptography chip. In total, 3 resource groups are specified for this
test, each with its own unique requirements.

Note that the number of slots following the resource type specifies slots from
a *single* instance of the resource. If the resource group can tolerate
receiving slots from different instances of the same resource, it can indicate
this by splitting the specification into multiple requirements of one slot. For
example:

.. code-block:: cmake

  add_test(NAME MyTest COMMAND MyExe)
  set_property(TEST MyTest PROPERTY RESOURCE_GROUPS
    "gpus:1,gpus:1,gpus:1,gpus:1")

In this case, the single resource group indicates that it needs four GPU slots,
all of which may come from separate GPUs (though they don't have to; CTest may
still assign slots from the same GPU.)

When CTest sets the :ref:`environment variables
<ctest-resource-environment-variables>` for a test, it assigns a group number
based on the group description, starting at 0 on the left and the number of
groups minus 1 on the right. For example, in the example above, the two
groups in the first description would have IDs of 0 and 1, and the single
group in the second description would have an ID of 2.

Both the ``RESOURCE_GROUPS`` and :prop_test:`RESOURCE_LOCK` properties serve
similar purposes, but they are distinct and orthogonal. Resources specified by
``RESOURCE_GROUPS`` do not affect :prop_test:`RESOURCE_LOCK`, and vice versa.
Whereas :prop_test:`RESOURCE_LOCK` is a simpler property that is used for
locking one global resource, ``RESOURCE_GROUPS`` is a more advanced property
that allows multiple tests to simultaneously use multiple resources of the
same type, specifying their requirements in a fine-grained manner.


code:
RESOURCE_LOCK
-------------

Specify a list of resources that are locked by this test.

If multiple tests specify the same resource lock, they are guaranteed
not to run concurrently.

See also :prop_test:`FIXTURES_REQUIRED` if the resource requires any setup or
cleanup steps.

Both the :prop_test:`RESOURCE_GROUPS` and ``RESOURCE_LOCK`` properties serve
similar purposes, but they are distinct and orthogonal. Resources specified by
:prop_test:`RESOURCE_GROUPS` do not affect ``RESOURCE_LOCK``, and vice versa.
Whereas ``RESOURCE_LOCK`` is a simpler property that is used for locking one
global resource, :prop_test:`RESOURCE_GROUPS` is a more advanced property
that allows multiple tests to simultaneously use multiple resources of the
same type, specifying their requirements in a fine-grained manner.


code:
RUN_SERIAL
----------

Do not run this test in parallel with any other test.

Use this option in conjunction with the ctest_test ``PARALLEL_LEVEL``
option to specify that this test should not be run in parallel with
any other tests.


code:
SKIP_REGULAR_EXPRESSION
-----------------------

.. versionadded:: 3.16

If the test output (stderr or stdout) matches this regular expression the test
will be marked as skipped, regardless of the process exit code. Tests that
exceed the timeout specified by :prop_test:`TIMEOUT` still fail regardless of
``SKIP_REGULAR_EXPRESSION``. System-level test failures including segmentation
faults, signal abort, or heap errors may fail the test even if the regular
expression matches.

Example:

.. code-block:: cmake

  add_test(NAME mytest COMMAND ${CMAKE_COMMAND} -E echo "Skipped this test")

  set_property(TEST mytest PROPERTY
    SKIP_REGULAR_EXPRESSION "[^a-z]Skip" "SKIP" "Skipped"
  )

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

To run a test that may have a system-level failure, but still skip if
``SKIP_REGULAR_EXPRESSION`` matches, use a CMake command to wrap the
executable run. Note that this will prevent automatic handling of the
:prop_tgt:`CROSSCOMPILING_EMULATOR` and :prop_tgt:`TEST_LAUNCHER`
target property.

.. code-block:: cmake

    add_executable(main main.c)

    add_test(NAME sigabrt COMMAND ${CMAKE_COMMAND} -E env $<TARGET_FILE:main>)

    set_property(TEST sigabrt PROPERTY SKIP_REGULAR_EXPRESSION "SIGABRT;[aA]bort")

.. code-block:: c

    #include <signal.h>

    int main(void){ raise(SIGABRT); return 0; }

See also the :prop_test:`SKIP_RETURN_CODE`,
:prop_test:`PASS_REGULAR_EXPRESSION`, and :prop_test:`FAIL_REGULAR_EXPRESSION`
test properties.


code:
SKIP_RETURN_CODE
----------------

Return code to mark a test as skipped.

Sometimes only a test itself can determine if all requirements for the
test are met. If such a situation should not be considered a hard failure
a return code of the process can be specified that will mark the test as
``Not Run`` if it is encountered. Valid values are in the range of
0 to 255, inclusive.

Tests that exceed the timeout specified by :prop_test:`TIMEOUT` still fail
regardless of ``SKIP_RETURN_CODE``.
System-level test failures including segmentation faults,
signal abort, or heap errors may fail the test even if the return code matches.

.. code-block:: cmake

    # cmake (1) defines this to return code 1
    add_test(NAME r1 COMMAND ${CMAKE_COMMAND} -E false)

    set_tests_properties(r1 PROPERTIES SKIP_RETURN_CODE 1)

To run a test that may have a system-level failure, but still skip if
``SKIP_RETURN_CODE`` matches, use a CMake command to wrap the executable run.
Note that this will prevent automatic handling of the
:prop_tgt:`CROSSCOMPILING_EMULATOR` and :prop_tgt:`TEST_LAUNCHER` target
property.

.. code-block:: cmake

    add_executable(main main.c)

    # cmake -E env <command> returns 1 if the command fails in any way
    add_test(NAME sigabrt COMMAND ${CMAKE_COMMAND} -E env $<TARGET_FILE:main>)

    set_property(TEST sigabrt PROPERTY SKIP_RETURN_CODE 1)

.. code-block:: c

    #include <signal.h>

    int main(void){ raise(SIGABRT); return 0; }

To handle multiple types of cases that may need to be skipped, consider the
:prop_test:`SKIP_REGULAR_EXPRESSION` property.


code:
TIMEOUT
-------

How many seconds to allow for this test.

This property if set will limit a test to not take more than the
specified number of seconds to run.  If it exceeds that the test
process will be killed and ctest will move to the next test.  This
setting takes precedence over :variable:`CTEST_TEST_TIMEOUT`.

An explicit ``0`` value means the test has no timeout, except as
necessary to honor :option:`ctest --stop-time`.

See also :prop_test:`TIMEOUT_AFTER_MATCH` and
:prop_test:`TIMEOUT_SIGNAL_NAME`.


code:
TIMEOUT_AFTER_MATCH
-------------------

.. versionadded:: 3.6

Change a test's timeout duration after a matching line is encountered
in its output.

Usage
^^^^^

.. code-block:: cmake

 add_test(mytest ...)
 set_property(TEST mytest PROPERTY TIMEOUT_AFTER_MATCH "${seconds}" "${regex}")

Description
^^^^^^^^^^^

Allow a test ``seconds`` to complete after ``regex`` is encountered in
its output.

When the test outputs a line that matches ``regex`` its start time is
reset to the current time and its timeout duration is changed to
``seconds``.  Prior to this, the timeout duration is determined by the
:prop_test:`TIMEOUT` property or the :variable:`CTEST_TEST_TIMEOUT`
variable if either of these are set.  Because the test's start time is
reset, its execution time will not include any time that was spent
waiting for the matching output.

``TIMEOUT_AFTER_MATCH`` is useful for avoiding spurious
timeouts when your test must wait for some system resource to become
available before it can execute.  Set :prop_test:`TIMEOUT` to a longer
duration that accounts for resource acquisition and use
``TIMEOUT_AFTER_MATCH`` to control how long the actual test
is allowed to run.

If the required resource can be controlled by CTest you should use
:prop_test:`RESOURCE_LOCK` instead of ``TIMEOUT_AFTER_MATCH``.
This property should be used when only the test itself can determine
when its required resources are available.

See also :prop_test:`TIMEOUT_SIGNAL_NAME`.


code:
TIMEOUT_SIGNAL_GRACE_PERIOD
---------------------------

.. versionadded:: 3.27

If the :prop_test:`TIMEOUT_SIGNAL_NAME` test property is set, this property
specifies the number of seconds to wait for a test process to terminate after
sending the custom signal.  Otherwise, this property has no meaning.

The grace period may be any real value greater than ``0.0``, but not greater
than ``60.0``.  If this property is not set, the default is ``1.0`` second.

This is available only on platforms supporting POSIX signals.
It is not available on Windows.


code:
TIMEOUT_SIGNAL_NAME
-------------------

.. versionadded:: 3.27

Specify a custom signal to send to a test process when its timeout is reached.
This is available only on platforms supporting POSIX signals.
It is not available on Windows.

The name must be one of the following:

  ``SIGINT``
    Interrupt.

  ``SIGQUIT``
    Quit.

  ``SIGTERM``
    Terminate.

  ``SIGUSR1``
    User defined signal 1.

  ``SIGUSR2``
    User defined signal 2.

The custom signal is sent to the test process to give it a chance
to exit gracefully during a grace period:

* If the test process created any children, it is responsible for
  terminating them too.

* The grace period length is determined by the
  :prop_test:`TIMEOUT_SIGNAL_GRACE_PERIOD` test property.

* If the test process does not terminate before the grace period ends,
  :manual:`ctest(1)` will force termination of its entire process tree
  via ``SIGSTOP`` and ``SIGKILL``.

See also :variable:`CTEST_TEST_TIMEOUT`,
:prop_test:`TIMEOUT`, and :prop_test:`TIMEOUT_AFTER_MATCH`.


code:
WILL_FAIL
---------

If ``true``, inverts the pass / fail test criteria. Tests for which
``WILL_FAIL`` is ``true`` fail with return code 0 and pass with non-zero
return code. Tests that exceed the timeout specified by :prop_test:`TIMEOUT`
still fail regardless of ``WILL_FAIL``.
System-level test failures including segmentation faults,
signal abort, or heap errors may fail the test even if ``WILL_FAIL`` is true.

Example of a test that would ordinarily pass, but fails because ``WILL_FAIL``
is ``true``:

.. code-block:: cmake

    add_test(NAME failed COMMAND ${CMAKE_COMMAND} -E true)
    set_property(TEST failed PROPERTY WILL_FAIL true)

To run a test that may have a system-level failure, but still pass if
``WILL_FAIL`` is set, use a CMake command to wrap the executable run.
Note that this will prevent automatic handling of the
:prop_tgt:`CROSSCOMPILING_EMULATOR` and :prop_tgt:`TEST_LAUNCHER`
target property.

.. code-block:: cmake

    add_executable(main main.c)

    add_test(NAME sigabrt COMMAND ${CMAKE_COMMAND} -E env $<TARGET_FILE:main>)

    set_property(TEST sigabrt PROPERTY WILL_FAIL TRUE)

.. code-block:: c

    #include <signal.h>

    int main(void){ raise(SIGABRT); return 0; }


code:
WORKING_DIRECTORY
-----------------

The directory from which the test executable will be called.

If this is not set, the test will be run with the working directory set to the
binary directory associated with where the test was created (i.e. the
:variable:`CMAKE_CURRENT_BINARY_DIR` for where :command:`add_test` was
called).


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 can be used to specify
files and directories that are generated as part of building the target or
that are directly associated with the target in some way (e.g. created as a
result of running the target).

For custom targets, if such files can be captured as outputs or byproducts
instead, then that should be preferred over adding them to this property.
If an additional clean file is used by multiple targets or isn't
target-specific, then the :prop_dir:`ADDITIONAL_CLEAN_FILES` directory
property may be the more appropriate property to use.

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

.. versionadded:: 3.17

On AIX, CMake automatically exports all symbols from shared libraries, and
from executables with the :prop_tgt:`ENABLE_EXPORTS` target property set.
Explicitly disable this boolean property to suppress the behavior and
export no symbols by default.  In this case it is expected that the project
will use other means to export some symbols.

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


code:
ALIASED_TARGET
--------------

Name of target aliased by this target.

If this is an :ref:`Alias Target <Alias Targets>`, this property contains
the name of the target aliased.


code:
ALIAS_GLOBAL
------------

.. versionadded:: 3.18

Read-only property indicating of whether an :ref:`ALIAS target <Alias Targets>`
is globally visible.

The boolean value of this property is ``TRUE`` for aliases to
:ref:`IMPORTED targets <Imported Targets>` created
with the ``GLOBAL`` options to :command:`add_executable()` or
:command:`add_library()`, ``FALSE`` otherwise. It is undefined for
targets built within the project.

.. note::

  Promoting an :ref:`IMPORTED target <Imported Targets>` from ``LOCAL``
  to ``GLOBAL`` scope by changing the value or :prop_tgt:`IMPORTED_GLOBAL`
  target property do not change the scope of local aliases.


code:
ANDROID_ANT_ADDITIONAL_OPTIONS
------------------------------

.. versionadded:: 3.4

Set the additional options for Android Ant build system. This is
a string value containing all command line options for the Ant build.
This property is initialized by the value of the
:variable:`CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS` variable if it is
set when a target is created.


code:
ANDROID_API
-----------

.. versionadded:: 3.1

When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
Edition`, this property sets the Android target API version (e.g. ``15``).
The version number must be a positive decimal integer.  This property is
initialized by the value of the :variable:`CMAKE_ANDROID_API` variable if
it is set when a target is created.


code:
ANDROID_API_MIN
---------------

.. versionadded:: 3.2

Set the Android MIN API version (e.g. ``9``).  The version number
must be a positive decimal integer.  This property is initialized by
the value of the :variable:`CMAKE_ANDROID_API_MIN` variable if it is set
when a target is created.  Native code builds using this API version.


code:
ANDROID_ARCH
------------

.. versionadded:: 3.4

When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
Edition`, this property sets the Android target architecture.

This is a string property that could be set to the one of
the following values:

* ``armv7-a``: "ARMv7-A (armv7-a)"
* ``armv7-a-hard``: "ARMv7-A, hard-float ABI (armv7-a)"
* ``arm64-v8a``: "ARMv8-A, 64bit (arm64-v8a)"
* ``x86``: "x86 (x86)"
* ``x86_64``: "x86_64 (x86_64)"

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


code:
ANDROID_ASSETS_DIRECTORIES
--------------------------

.. versionadded:: 3.4

Set the Android assets directories to copy into the main assets
folder before build. This a string property that contains the
directory paths separated by semicolon.
This property is initialized by the value of the
:variable:`CMAKE_ANDROID_ASSETS_DIRECTORIES` variable if it is set when
a target is created.


code:
ANDROID_GUI
-----------

.. versionadded:: 3.1

When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
Edition`, this property specifies whether to build an executable as an
application package on Android.

When this property is set to true the executable when built for Android
will be created as an application package.  This property is initialized
by the value of the :variable:`CMAKE_ANDROID_GUI` variable if it is set
when a target is created.

Add the ``AndroidManifest.xml`` source file explicitly to the
target :command:`add_executable` command invocation to specify the
root directory of the application package source.


code:
ANDROID_JAR_DEPENDENCIES
------------------------

.. versionadded:: 3.4

Set the Android property that specifies JAR dependencies.
This is a string value property. This property is initialized
by the value of the :variable:`CMAKE_ANDROID_JAR_DEPENDENCIES`
variable if it is set when a target is created.


code:
ANDROID_JAR_DIRECTORIES
-----------------------

.. versionadded:: 3.4

Set the Android property that specifies directories to search for
the JAR libraries.

This a string property that contains the directory paths separated by
semicolons. This property is initialized by the value of the
:variable:`CMAKE_ANDROID_JAR_DIRECTORIES` variable if it is set when
a target is created.

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


code:
ANDROID_JAVA_SOURCE_DIR
-----------------------

.. versionadded:: 3.4

Set the Android property that defines the Java source code root directories.
This a string property that contains the directory paths separated by semicolon.
This property is initialized by the value of the
:variable:`CMAKE_ANDROID_JAVA_SOURCE_DIR` variable if it is set
when a target is created.


code:
ANDROID_NATIVE_LIB_DEPENDENCIES
-------------------------------

.. versionadded:: 3.4

Set the Android property that specifies the .so dependencies.
This is a string property.

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

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


code:
ANDROID_NATIVE_LIB_DIRECTORIES
------------------------------

.. versionadded:: 3.4

Set the Android property that specifies directories to search for the ``.so``
libraries.

This a string property that contains the directory paths separated
by semicolons.

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

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


code:
ANDROID_PROCESS_MAX
-------------------

.. versionadded:: 3.4

Set the Android property that defines the maximum number of a
parallel Android NDK compiler processes (e.g. ``4``).
This property is initialized by the value of the
:variable:`CMAKE_ANDROID_PROCESS_MAX` variable if it is set
when a target is created.


code:
ANDROID_PROGUARD
----------------

.. versionadded:: 3.4

When this property is set to true that enables the ProGuard tool to shrink,
optimize, and obfuscate the code by removing unused code and renaming
classes, fields, and methods with semantically obscure names.
This property is initialized by the value of the
:variable:`CMAKE_ANDROID_PROGUARD` variable if it is set
when a target is created.


code:
ANDROID_PROGUARD_CONFIG_PATH
----------------------------

.. versionadded:: 3.4

Set the Android property that specifies the location of the ProGuard
config file. Leave empty to use the default one.
This a string property that contains the path to ProGuard config file.
This property is initialized by the value of the
:variable:`CMAKE_ANDROID_PROGUARD_CONFIG_PATH` variable if it is set
when a target is created.


code:
ANDROID_SECURE_PROPS_PATH
-------------------------

.. versionadded:: 3.4

Set the Android property that states the location of the secure properties file.
This is a string property that contains the file path.
This property is initialized by the value of the
:variable:`CMAKE_ANDROID_SECURE_PROPS_PATH` variable
if it is set when a target is created.


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

.. versionadded:: 3.4

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


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

.. versionadded:: 3.4

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

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

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


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

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

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

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


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

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

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

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


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

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

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

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


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

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

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


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

.. versionadded:: 3.29

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

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

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

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


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

.. versionadded:: 3.9

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

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

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

By default ``AUTOGEN_BUILD_DIR`` is unset.

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


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

.. versionadded:: 3.29

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

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

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

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


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

.. versionadded:: 3.14

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

  .. note::

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

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

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

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

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

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

.. note::

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

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


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

.. versionadded:: 3.11

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

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

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

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

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


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

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

  .. note::

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

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

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

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

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

Use cases
^^^^^^^^^

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

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

it must be added to ``AUTOGEN_TARGET_DEPENDS``.


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

.. versionadded:: 3.27

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

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

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

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


code:
AUTOMOC
-------

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

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

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

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

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

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

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

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

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

  and adds these to the scan list.

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

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

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

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

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

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

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

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

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

.. code-block:: c++

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

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

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

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

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

.. code-block:: c++

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

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

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

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

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

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

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

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

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

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

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

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

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

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

which is added to the target's sources.

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

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

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

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

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

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

.. code-block:: cmake

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

Modifiers
^^^^^^^^^

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

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

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

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

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

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

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

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

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

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

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

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

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


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

.. versionadded:: 3.10

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

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

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

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

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

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


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

.. versionadded:: 3.9

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

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

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

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

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

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

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

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

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

Example 1
^^^^^^^^^

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

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

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

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

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

Example 2
^^^^^^^^^

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

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

::

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

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

  list(APPEND CMAKE_AUTOMOC_MACRO_NAMES "JSON_BASED_CLASS")

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

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

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

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


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

.. versionadded:: 3.14

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

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

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


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

.. versionadded:: 3.10

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

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

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

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

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

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

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

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

Example
^^^^^^^

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

.. code-block:: cmake

  set_property(TARGET tgt APPEND PROPERTY AUTOMOC_MACRO_NAMES "CUSTOM_MACRO")


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

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

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

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

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

EXAMPLE
^^^^^^^

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

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

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

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

    #ifndef Object_HPP
    #define Object_HPP

    #include <QObject>

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

      Object();

    };
    #endif

    #endif


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

.. versionadded:: 3.16

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

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

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

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

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

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

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


code:
AUTORCC
-------

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

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

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

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

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

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

Modifiers
^^^^^^^^^

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

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

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

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

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

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

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

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


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

.. versionadded:: 3.14

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

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

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


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

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

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

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

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

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

EXAMPLE
^^^^^^^

.. code-block:: cmake

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


code:
AUTOUIC
-------

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

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

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

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

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

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

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

.. code-block:: c++

  #include "ui_<ui_base>.h"

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

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

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

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

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

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

Modifiers
^^^^^^^^^

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

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

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

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

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

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

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

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

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


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

.. versionadded:: 3.14

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

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

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


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

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

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

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

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

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

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

EXAMPLE
^^^^^^^

.. code-block:: cmake

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


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

.. versionadded:: 3.9

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

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

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


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

.. versionadded:: 3.4

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


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

.. versionadded:: 3.8

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

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

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

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

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

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

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

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

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


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

.. versionadded:: 3.14

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

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

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

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

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


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

.. versionadded:: 3.9

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

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

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


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

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

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

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


code:
BUNDLE
------

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

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


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

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

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


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

.. versionadded:: 3.12

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

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

Not Set (default)

  Native C++.

``""`` (set but empty)

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

``netcore``
  .. versionadded:: 3.26

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

  This required VS 2019's v142 toolset or higher.

``pure``

  Managed C++.

``safe``

  Managed C++.

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

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

See also :prop_tgt:`IMPORTED_COMMON_LANGUAGE_RUNTIME`


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

Properties which must be compatible with their link interface

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

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

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


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

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

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

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


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

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

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

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


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

Properties which must be string-compatible with their link interface

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

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


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

Preprocessor definitions for compiling a target's sources.

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

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

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

.. include:: /include/COMPILE_DEFINITIONS_DISCLAIMER.txt

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

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


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

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

Per-configuration preprocessor definitions on a target.

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

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

Generator expressions should be preferred instead of setting this property.


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

.. versionadded:: 3.1

Compiler features enabled for this target.

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

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


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

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

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

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


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

List of options to pass to the compiler.

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

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

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

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

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


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

.. versionadded:: 3.1

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

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

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


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

.. versionadded:: 3.1

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

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

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


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


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

.. versionadded:: 3.1

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

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

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


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

.. versionadded:: 3.1

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

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

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


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

.. versionadded:: 3.24

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

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

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

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


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

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

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


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

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

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

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


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

.. versionadded:: 3.3

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

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

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

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


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

.. versionadded:: 3.18

List of architectures to generate device code for.

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

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

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

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

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

``all``
  .. versionadded:: 3.23

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

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

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

``native``
  .. versionadded:: 3.24

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

Examples
^^^^^^^^

.. code-block:: cmake

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

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

.. code-block:: cmake

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

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

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES OFF)

CMake will not pass any architecture flags to the compiler.


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

.. versionadded:: 3.27

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

For example:

.. code-block:: cmake

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


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

.. versionadded:: 3.8

Boolean specifying whether compiler specific extensions are requested.

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

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

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


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

.. versionadded:: 3.27

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

For example:

.. code-block:: cmake

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


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

.. versionadded:: 3.27

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

For example:

.. code-block:: cmake

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


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

.. versionadded:: 3.9

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

For example:

.. code-block:: cmake

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


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

.. versionadded:: 3.9

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

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

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

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

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

For instance:

.. code-block:: cmake

  set_property(TARGET mystaticlib PROPERTY CUDA_RESOLVE_DEVICE_SYMBOLS ON)


code:
``None``
  Link with ``-cudart=none`` or equivalent flag(s) to use no CUDA
  runtime library.
``Shared``
  Link with ``-cudart=shared`` or equivalent flag(s) to use a
  dynamically-linked CUDA runtime library.
``Static``
  Link with ``-cudart=static`` or equivalent flag(s) to use a
  statically-linked CUDA runtime library.


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

.. versionadded:: 3.17

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

The allowed case insensitive values are:

.. include:: CUDA_RUNTIME_LIBRARY-VALUES.txt

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

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

.. note::

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


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

.. versionadded:: 3.8

CUDA only: Enables separate compilation of device code

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

For instance:

.. code-block:: cmake

  set_property(TARGET myexe PROPERTY CUDA_SEPARABLE_COMPILATION ON)

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


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

.. versionadded:: 3.8

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

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

Supported values are:

``98``
  CUDA C++98. Note that this maps to the same as ``03`` internally.

``03``
  CUDA C++03

``11``
  CUDA C++11

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

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

``20``
  .. versionadded:: 3.12

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

``23``
  .. versionadded:: 3.20

  CUDA C++23

``26``
  .. versionadded:: 3.25

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

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

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY CUDA_STANDARD 11)

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

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

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


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

.. versionadded:: 3.8

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

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

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

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