Custom command dependencies are followed for each target's source files
and add their transitive closure to the corresponding target. This
means that when a custom command in one target has a dependency on a
custom command in another target, both will appear in the dependent
target's sources. For the Makefile, VS IDE, and Xcode generators this
is not a problem because each target gets its own independent build
system that is evaluated in target dependency order. By the time the
dependent target is built the custom command that belongs to one of its
dependencies will already have been brought up to date.
For the Ninja generator we need to generate a monolithic build system
covering all targets so we can have only one copy of a custom command.
This means that we need to reconcile the target-level ordering
dependencies from its appearance in multiple targets to include only the
least-dependent common set. This is done by computing the set
intersection of the dependencies of all the targets containing a custom
command. However, we previously included only the direct dependencies
so any target-level dependency not directly added to all targets into
which a custom command propagates was discarded.
Fix this by computing the transitive closure of dependencies for each
target and then intersecting those sets. That will get the common set
of dependencies. Also add a test to cover a case in which the
incorrectly dropped target ordering dependencies would fail.
This directory contains tests that run CMake to configure a project
but do not actually build anything. To add a test:
1. Add a subdirectory named for the test, say ``<Test>/``.
2. In ``./CMakeLists.txt`` call ``add_RunCMake_test`` and pass the
test directory name ``<Test>``.
3. Create script ``<Test>/RunCMakeTest.cmake`` in the directory containing::
include(RunCMake)
run_cmake(SubTest1)
...
run_cmake(SubTestN)
where ``SubTest1`` through ``SubTestN`` are sub-test names each
corresponding to an independent CMake run and project configuration.
One may also add calls of the form::
run_cmake_command(SubTestI ${CMAKE_COMMAND} ...)
to fully customize the test case command-line.
Alternatively, if the test is to cover running ``ctest -S`` then use::
include(RunCTest)
run_ctest(SubTest1)
...
run_ctest(SubTestN)
and create ``test.cmake.in``, ``CTestConfig.cmake.in``, and
``CMakeLists.txt.in`` files to be configured for each case.
4. Create file ``<Test>/CMakeLists.txt`` in the directory containing::
cmake_minimum_required(...)
project(${RunCMake_TEST} NONE) # or languages needed
include(${RunCMake_TEST}.cmake)
where ``${RunCMake_TEST}`` is literal. A value for ``RunCMake_TEST``
will be passed to CMake by the ``run_cmake`` macro when running each
sub-test.
5. Create a ``<Test>/<SubTest>.cmake`` file for each sub-test named
above containing the actual test code. Optionally create files
containing expected test results:
``<SubTest>-result.txt``
Process result expected if not "0"
``<SubTest>-stdout.txt``
Regex matching expected stdout content
``<SubTest>-stderr.txt``
Regex matching expected stderr content, if not "^$"
``<SubTest>-check.cmake``
Custom result check.
Note that trailing newlines will be stripped from actual and expected
test output before matching against the stdout and stderr expressions.
The code in ``<SubTest>-check.cmake`` may use variables
``RunCMake_TEST_SOURCE_DIR``
Top of test source tree
``RunCMake_TEST_BINARY_DIR``
Top of test binary tree
and an failure must store a message in ``RunCMake_TEST_FAILED``.
1296a0eada