mirror of
https://github.com/crystalidea/qt-build-tools.git
synced 2025-07-02 15:35:22 +08:00
qt 6.5.3
This commit is contained in:
kleuter
@ -0,0 +1,7 @@
|
||||
ATTACHED_FILES
|
||||
--------------
|
||||
|
||||
Attach a list of files to a dashboard submission.
|
||||
|
||||
Set this property to a list of files that will be encoded and
|
||||
submitted to the dashboard as an addition to the test result.
|
||||
@ -0,0 +1,7 @@
|
||||
ATTACHED_FILES_ON_FAIL
|
||||
----------------------
|
||||
|
||||
Attach a list of files to a dashboard submission if the test fails.
|
||||
|
||||
Same as :prop_test:`ATTACHED_FILES`, but these files will only be
|
||||
included if the test does not pass.
|
||||
14
6.5.3/_tools/cmake/share/cmake-3.27/Help/prop_test/COST.rst
Normal file
14
6.5.3/_tools/cmake/share/cmake-3.27/Help/prop_test/COST.rst
Normal file
@ -0,0 +1,14 @@
|
||||
COST
|
||||
----
|
||||
|
||||
This property describes the cost of a test. When parallel testing is
|
||||
enabled, tests in the test set will be run in descending order of cost.
|
||||
Projects can explicitly define the cost of a test by setting this property
|
||||
to a floating point value.
|
||||
|
||||
When the cost of a test is not defined by the project,
|
||||
:manual:`ctest <ctest(1)>` will initially use a default cost of ``0``.
|
||||
It computes a weighted average of the cost each time a test is run and
|
||||
uses that as an improved estimate of the cost for the next run. The more
|
||||
a test is re-run in the same build directory, the more representative the
|
||||
cost should become.
|
||||
@ -0,0 +1,22 @@
|
||||
DEPENDS
|
||||
-------
|
||||
|
||||
Specifies that this test should only be run after the specified list of tests.
|
||||
|
||||
Set this to a list of tests that must finish before this test is run. The
|
||||
results of those tests are not considered, the dependency relationship is
|
||||
purely for order of execution (i.e. it is really just a *run after*
|
||||
relationship). Consider using test fixtures with setup tests if a dependency
|
||||
with successful completion is required (see :prop_test:`FIXTURES_REQUIRED`).
|
||||
|
||||
Examples
|
||||
~~~~~~~~
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_test(NAME baseTest1 ...)
|
||||
add_test(NAME baseTest2 ...)
|
||||
add_test(NAME dependsTest12 ...)
|
||||
|
||||
set_tests_properties(dependsTest12 PROPERTIES DEPENDS "baseTest1;baseTest2")
|
||||
# dependsTest12 runs after baseTest1 and baseTest2, even if they fail
|
||||
@ -0,0 +1,17 @@
|
||||
DISABLED
|
||||
--------
|
||||
|
||||
.. versionadded:: 3.9
|
||||
|
||||
If set to ``True``, the test will be skipped and its status will be 'Not Run'. A
|
||||
``DISABLED`` test will not be counted in the total number of tests and its
|
||||
completion status will be reported to CDash as ``Disabled``.
|
||||
|
||||
A ``DISABLED`` test does not participate in test fixture dependency resolution.
|
||||
If a ``DISABLED`` test has fixture requirements defined in its
|
||||
:prop_test:`FIXTURES_REQUIRED` property, it will not cause setup or cleanup
|
||||
tests for those fixtures to be added to the test set.
|
||||
|
||||
If a test with the :prop_test:`FIXTURES_SETUP` property set is ``DISABLED``,
|
||||
the fixture behavior will be as though that setup test was passing and any test
|
||||
case requiring that fixture will still run.
|
||||
@ -0,0 +1,9 @@
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
Specify environment variables that should be defined for running a test.
|
||||
|
||||
Set to a :ref:`semicolon-separated list <CMake Language Lists>` list
|
||||
of environment variables and values of the form ``MYVAR=value``.
|
||||
Those environment variables will be defined while running the test.
|
||||
The environment changes from this property do not affect other tests.
|
||||
@ -0,0 +1,41 @@
|
||||
ENVIRONMENT_MODIFICATION
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 3.22
|
||||
|
||||
Specify environment variables that should be modified for running a test. Note
|
||||
that the operations performed by this property are performed after the
|
||||
:prop_test:`ENVIRONMENT` property is already applied.
|
||||
|
||||
Set to a :ref:`semicolon-separated list <CMake Language Lists>` of
|
||||
environment variables and values of the form ``MYVAR=OP:VALUE``,
|
||||
where ``MYVAR`` is the case-sensitive name of an environment variable
|
||||
to be modified. Entries are considered in the order specified in the
|
||||
property's value. The ``OP`` may be one of:
|
||||
|
||||
- ``reset``: Reset to the unmodified value, ignoring all modifications to
|
||||
``MYVAR`` prior to this entry. Note that this will reset the variable to
|
||||
the value set by :prop_test:`ENVIRONMENT`, if it was set, and otherwise
|
||||
to its state from the rest of the CTest execution.
|
||||
- ``set``: Replaces the current value of ``MYVAR`` with ``VALUE``.
|
||||
- ``unset``: Unsets the current value of ``MYVAR``.
|
||||
- ``string_append``: Appends singular ``VALUE`` to the current value of
|
||||
``MYVAR``.
|
||||
- ``string_prepend``: Prepends singular ``VALUE`` to the current value of
|
||||
``MYVAR``.
|
||||
- ``path_list_append``: Appends singular ``VALUE`` to the current value of
|
||||
``MYVAR`` using the host platform's path list separator (``;`` on Windows
|
||||
and ``:`` elsewhere).
|
||||
- ``path_list_prepend``: Prepends singular ``VALUE`` to the current value of
|
||||
``MYVAR`` using the host platform's path list separator (``;`` on Windows
|
||||
and ``:`` elsewhere).
|
||||
- ``cmake_list_append``: Appends singular ``VALUE`` to the current value of
|
||||
``MYVAR`` using ``;`` as the separator.
|
||||
- ``cmake_list_prepend``: Prepends singular ``VALUE`` to the current value of
|
||||
``MYVAR`` using ``;`` as the separator.
|
||||
|
||||
Unrecognized ``OP`` values will result in the test failing before it is
|
||||
executed. This is so that future operations may be added without changing
|
||||
valid behavior of existing tests.
|
||||
|
||||
The environment changes from this property do not affect other tests.
|
||||
@ -0,0 +1,19 @@
|
||||
FAIL_REGULAR_EXPRESSION
|
||||
-----------------------
|
||||
|
||||
If the output matches this regular expression the test will fail,
|
||||
regardless of the process exit code.
|
||||
|
||||
If set, if the output matches one of specified regular expressions,
|
||||
the test will fail. Example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
set_tests_properties(mytest PROPERTIES
|
||||
FAIL_REGULAR_EXPRESSION "[^a-z]Error;ERROR;Failed"
|
||||
)
|
||||
|
||||
``FAIL_REGULAR_EXPRESSION`` expects a list of regular expressions.
|
||||
|
||||
See also the :prop_test:`PASS_REGULAR_EXPRESSION` and
|
||||
:prop_test:`SKIP_REGULAR_EXPRESSION` test properties.
|
||||
@ -0,0 +1,49 @@
|
||||
FIXTURES_CLEANUP
|
||||
----------------
|
||||
|
||||
.. versionadded:: 3.7
|
||||
|
||||
Specifies a list of fixtures for which the test is to be treated as a cleanup
|
||||
test. These fixture names are distinct from test case names and are not
|
||||
required to have any similarity to the names of tests associated with them.
|
||||
|
||||
Fixture cleanup tests are ordinary tests with all of the usual test
|
||||
functionality. Setting the ``FIXTURES_CLEANUP`` property for a test has two
|
||||
primary effects:
|
||||
|
||||
- CTest will ensure the test executes after all other tests which list any of
|
||||
the fixtures in its :prop_test:`FIXTURES_REQUIRED` property.
|
||||
|
||||
- If CTest is asked to run only a subset of tests (e.g. using regular
|
||||
expressions or the ``--rerun-failed`` option) and the cleanup test is not in
|
||||
the set of tests to run, it will automatically be added if any tests in the
|
||||
set require any fixture listed in ``FIXTURES_CLEANUP``.
|
||||
|
||||
A cleanup test can have multiple fixtures listed in its ``FIXTURES_CLEANUP``
|
||||
property. It will execute only once for the whole CTest run, not once for each
|
||||
fixture. A fixture can also have more than one cleanup test defined. If there
|
||||
are multiple cleanup tests for a fixture, projects can control their order with
|
||||
the usual :prop_test:`DEPENDS` test property if necessary.
|
||||
|
||||
A cleanup test is allowed to require other fixtures, but not any fixture listed
|
||||
in its ``FIXTURES_CLEANUP`` property. For example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
# Ok: Dependent fixture is different to cleanup
|
||||
set_tests_properties(cleanupFoo PROPERTIES
|
||||
FIXTURES_CLEANUP Foo
|
||||
FIXTURES_REQUIRED Bar
|
||||
)
|
||||
|
||||
# Error: cannot require same fixture as cleanup
|
||||
set_tests_properties(cleanupFoo PROPERTIES
|
||||
FIXTURES_CLEANUP Foo
|
||||
FIXTURES_REQUIRED Foo
|
||||
)
|
||||
|
||||
Cleanup tests will execute even if setup or regular tests for that fixture fail
|
||||
or are skipped.
|
||||
|
||||
See :prop_test:`FIXTURES_REQUIRED` for a more complete discussion of how to use
|
||||
test fixtures.
|
||||
@ -0,0 +1,99 @@
|
||||
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.
|
||||
@ -0,0 +1,50 @@
|
||||
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.
|
||||
@ -0,0 +1,10 @@
|
||||
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.
|
||||
@ -0,0 +1,8 @@
|
||||
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``.
|
||||
@ -0,0 +1,20 @@
|
||||
PASS_REGULAR_EXPRESSION
|
||||
-----------------------
|
||||
|
||||
The output must match this regular expression for the test to pass.
|
||||
The process exit code is ignored.
|
||||
|
||||
If set, the test output will be checked against the specified regular
|
||||
expressions and at least one of the regular expressions has to match,
|
||||
otherwise the test will fail. Example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
set_tests_properties(mytest PROPERTIES
|
||||
PASS_REGULAR_EXPRESSION "TestPassed;All ok"
|
||||
)
|
||||
|
||||
``PASS_REGULAR_EXPRESSION`` expects a list of regular expressions.
|
||||
|
||||
See also the :prop_test:`FAIL_REGULAR_EXPRESSION` and
|
||||
:prop_test:`SKIP_REGULAR_EXPRESSION` test properties.
|
||||
@ -0,0 +1,16 @@
|
||||
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.
|
||||
@ -0,0 +1,13 @@
|
||||
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.
|
||||
@ -0,0 +1,38 @@
|
||||
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`).
|
||||
@ -0,0 +1,72 @@
|
||||
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.
|
||||
@ -0,0 +1,18 @@
|
||||
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.
|
||||
@ -0,0 +1,8 @@
|
||||
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.
|
||||
@ -0,0 +1,21 @@
|
||||
SKIP_REGULAR_EXPRESSION
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 3.16
|
||||
|
||||
If the output matches this regular expression the test will be marked as skipped.
|
||||
|
||||
If set, if the output matches one of specified regular expressions,
|
||||
the test will be marked as skipped. Example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
set_property(TEST mytest PROPERTY
|
||||
SKIP_REGULAR_EXPRESSION "[^a-z]Skip" "SKIP" "Skipped"
|
||||
)
|
||||
|
||||
``SKIP_REGULAR_EXPRESSION`` expects a list of regular expressions.
|
||||
|
||||
See also the :prop_test:`SKIP_RETURN_CODE`,
|
||||
:prop_test:`PASS_REGULAR_EXPRESSION`, and :prop_test:`FAIL_REGULAR_EXPRESSION`
|
||||
test properties.
|
||||
@ -0,0 +1,12 @@
|
||||
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.
|
||||
|
||||
See also the :prop_test:`SKIP_REGULAR_EXPRESSION` property.
|
||||
@ -0,0 +1,15 @@
|
||||
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`.
|
||||
@ -0,0 +1,43 @@
|
||||
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`.
|
||||
@ -0,0 +1,14 @@
|
||||
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.
|
||||
@ -0,0 +1,41 @@
|
||||
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`.
|
||||
@ -0,0 +1,8 @@
|
||||
WILL_FAIL
|
||||
---------
|
||||
|
||||
If set to true, this will invert the pass/fail flag of the test.
|
||||
|
||||
This property can be used for tests that are expected to fail and return a
|
||||
non-zero return code. Note that system-level test failures such as segmentation
|
||||
faults or heap errors will still fail the test even if ``WILL_FALL`` is true.
|
||||
@ -0,0 +1,9 @@
|
||||
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).
|
||||
Reference in New Issue
Block a user