5cced02b9d CTest: Repeat test fixtures with the tests that require them
4fcf3dd296 CTest: Ignore a checkpoint entry for a test that is not pending
32b25b94d6 CTest: Track one run number for a repeating test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !11638
When ctest repeats tests with its --repeat option, it repeats each test
on its own. A fixture's setup and cleanup tests therefore run all of
their repetitions back to back, and the tests they bracket repeat inside
a single setup/cleanup pair:
setup -> setup -> test -> test -> cleanup -> cleanup
Add a FIXTURE_REPEAT_MODE test property to select how a fixture behaves
when its tests are repeated:
* AROUND_ALL_REPEATS: the fixture runs once, around all repetitions of
the tests requiring it.
* AROUND_EACH_REPEAT: the fixture and the tests requiring it repeat
together, so every repetition gets a fresh setup and its own cleanup.
* EACH_TEST_SEPARATELY: every test repeats on its own, as before.
The property describes the fixture rather than the test carrying it, so
setting it on any one of a fixture's setup or cleanup tests is enough.
In AROUND_EACH_REPEAT mode the tests of a fixture form a repeat group that
ctest re-queues as a whole once every test in it has finished. The --repeat
condition then applies to the group the way it applies to an individual
test: until-fail repeats while the whole group passes, until-pass repeats
while any of it does not, and after-timeout repeats while any of it times
out. Fixtures that share a test repeat together, so a test requiring two of
them still runs once per repetition.
A group is recorded the way a repeating test is: only once it stops
repeating, and with the results of its last repetition. A group that
until-pass makes pass therefore reports a pass rather than the failure that
made it repeat, a test that DEPENDS on one of the group's tests waits for
the last repetition rather than the first, and `ctest -F` resumes an
interrupted group by running it again from the beginning.
Fixtures that repeat together have to agree on the mode: a test cannot
repeat with one fixture but not with another it takes part in, and a fixture
whose setup and cleanup tests disagree has no coherent behavior. Report an
error and run nothing in those cases rather than pick an order in which a
test repeats after a fixture it requires has been cleaned up.
Add policy CMP0224 to select AROUND_EACH_REPEAT as the default for fixtures
whose setup and cleanup tests choose no mode themselves. Record the mode
the policy chose in the generated test file under its own
_CMAKE_DEFAULT_FIXTURE_REPEAT_MODE keyword, so that ctest reads a mode
rather than the policy settings behind it, and so that a mode requested on
one of a fixture's tests wins over the default recorded for its siblings.
Only NEW needs recording: with nothing recorded, ctest already uses the
behavior of CMake 4.4 and below. Fixtures are common, and the choice of
mode matters only to those who run ctest --repeat, so warn about the unset
policy only when the CMAKE_POLICY_WARNING_CMP0224 variable asks for it.
discover_tests() and gtest_discover_tests() create their tests while ctest
runs or at build time, too late for the policy to reach them, so carry the
setting in effect at their call sites through to the tests they create.
Report the repetition a grouped test belongs to in the "(run N/M)" suffix
of its "Start" line, as ctest already does for a test repeating on its own.
Co-authored-by: Tyler Yankee <tyler.yankee@kitware.com>
Fixes: #21438
Reapply the implementation in commits commits 77312cc6 (CUDA: Add
support for [CMAKE_]CUDA_LINKER_LAUNCHER, 2025-05-30,
v4.1.0-rc1~80^2~1) and cdf2a36f (HIP: Add support for
[CMAKE_]HIP_LINKER_LAUNCHER, 2025-05-30, v4.1.0-rc1~80^2).
Add a special case to expand the correct rule placeholder for these
languages, which is spelled `CMAKE_<LANG>_HOST_LINK_LAUNCHER`. Enable
the tests for these languages correctly. Re-document support under
CMake 4.5.
Fixes: #26967
The implementation in commits 77312cc6 (CUDA: Add support for
[CMAKE_]CUDA_LINKER_LAUNCHER, 2025-05-30, v4.1.0-rc1~80^2~1) and
cdf2a36f (HIP: Add support for [CMAKE_]HIP_LINKER_LAUNCHER, 2025-05-30,
v4.1.0-rc1~80^2) is broken, and the tests are wrongly configured
so as to never actually run. Revert the entire feature to avoid future
confusion, including documented support.
Enable the test for Fortran, which was added but untested by commit
d176a8c5ce (Fortran: Add support for [CMAKE_]Fortran_LINKER_LAUNCHER,
2025-05-26, v4.1.0-rc1~96^2), and whose implementation works.
Issue: #26967
The `arm64ec` value was added by commit 7f0f382c55 (Provide
CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID on more compilers, 2025-03-24,
v4.1.0-rc1~499^2) but not documented.
Note that the Clang `-marm64x` flag can produce `aarch64;arm64ec`.
Issue: #28067
Both architectures appear in object files, so add both of them to
`CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID` too. We already do this for
multiple `CMAKE_OSX_ARCHITECTURES` on Apple platforms.
Fixes: #28067
Commit 680fbb112a (Autogen: Enable depfile support for Visual Studio and
Xcode generators) disabled the PRE_BUILD optimization when a depfile is
used, because a PRE_BUILD event cannot carry depfile dependencies. Since
then, every target with AUTOMOC or AUTOUIC enabled gains an
'<ORIGIN>_autogen' and an '<ORIGIN>_autogen_timestamp_deps' target,
which the Visual Studio generators turn into two extra projects per
target in the generated solution.
Attach the autogen custom command to the origin target instead. The
custom command still carries the depfile, and the dependencies of the
origin target provide the ordering that
'<ORIGIN>_autogen_timestamp_deps' provides otherwise, because MSBuild
builds all referenced projects before any step of the referencing
project.
Use the conditions of the PRE_BUILD event, so that the
'<ORIGIN>_autogen' target keeps existing wherever it existed before
depfiles were enabled for the Visual Studio generators. In particular,
projects that name the target in add_dependencies() keep working.
Ninja and the Makefile generators keep the separate targets. Extra
targets have no cost for them, and '<ORIGIN>_autogen' has always existed
there.
The Xcode generator gained the same two targets per origin target in
4.4, but attaching the custom command there needs some more thoughts on
the per-config timestamp file first: Xcode rejects targets whose sources
vary by configuration, and with AUTOGEN_BETTER_GRAPH_MULTI_CONFIG the
timestamp file is per configuration.
Fixes: #28034Fixes: #28033
Propagates variables set in enable_language() logic up variable scopes
so that the language can be used by targets in the ancestor directories.
Works through block() and function() scopes as well. The
add_subdirectory() call can be thought of as the effective call site for
enabling the language. The same holds for endblock() and the actual
function call.
Adds a policy CMP0220 to control this behavior. As the language is
"enabled" at each ancestor scope, the policy is checked. If OLD, the
language is not enabled at this scope and the ones above.
Closes: #27881#27508#27389
Related: #26751#27564
They don't support setting compiler via this variable, they use the
toolsets, so you could switch the compiler by choosing another toolset.
Closes: #21644
Extend the test_prep/<test> and test_prep/all build targets, generated
from add_test(BUILD_DEPENDS) when CMAKE_TEST_BUILD_DEPENDS is enabled, to
the Makefile generators. Previously only the Ninja and FASTBuild
generators provided them.
Resolve each test's dependencies in a shared layer so all command-line
generators consume one result. cmTestGenerator now filters target
dependencies to build-system targets and records, for each file
dependency, the single target that produces it as a primary
custom-command output (cmGlobalGenerator::FindOutputOwningTarget). The
Makefile generators emit phony rules in CMakeFiles/Makefile2 depending on
<target>.dir/all, with top-level forwarding rules. Sharing the
resolution also stops Ninja and FASTBuild from emitting a dead test_prep
edge for a non-buildable (e.g. INTERFACE) BUILD_DEPENDS target.
On the Makefile generators a file dependency that no single target
produces, and a test whose name contains ':', cannot be expressed as a
recursive-make rule and are reported with a warning and skipped.
Fixes: #27879
Rename the compiler id from commit ee76398d23 (IBMLLVMFlang: Add support
for this compiler, 2026-05-25) to mention only the direct vendor, IBM.
Issue: #27863
2e214f0a5b ctest: allow CTest Script variables to be set via the command-line
21b9c20592 ctest: extend config mapping to include script-only variables
68489471a6 ctest: refactor SetCMakeVariables to use a mapping table
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !12060
Add `test_prep/<test_name>` convenience targets to the ninja generator
to build dependencies of tests, and `test_prep/all` to build the dependencies
of all tests.
Build dependencies of a test include:
- Executables directly invoked by test `COMMAND`.
- Targets mentioned in generator expressionf os test `COMMAND`.
- Anything explicitly listed with the new `BUILD_DEPENDS` argument of `add_test`.
Issue: #27613
This was left out of commit b7a5f2732d (PellesC: Add minimal support for
this C compiler, 2026-04-03) because the implementation was not usable
in general. It is now.
Closes: #21536
Co-authored-by: Serguei E. Leontiev <leo@sai.msu.ru>
72e7305c3e Diagnostics: Handle CMAKE_{WARN,ERROR}_DEPRECATED
be057c5a01 cmVariableWatch: Use enum for access type
cba542f32c cmake.cxx: Organize includes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11948
Update documentation for aforementioned variables, as their use is
deprecated under the new diagnostic system. Introduce a policy which
reintroduces their use to control specific deprecation diagnostics if
the policy is not NEW.
Note that this means there is NO synchronization between the variables
and the new diagnostic state.
Make diagnostics into Sphinx objects so that they can be more readily
cross-referenced. (This is also needed to enable --help-diagnostic.)
Update various places that can make use of the same. Significantly
expand the documentation on controlling diagnostics.
Add a `CTEST_TEST_COVERAGE_TOOL` variable to tell CTest to integrate
with `llvm-cov` source-based code coverage by setting the
`LLVM_PROFILE_FILE` environment variable for each test.
Issue: #26932
39a56136a3 Diagnostic: Add warn or error on absolute install paths
fd76089631 cmInstallFileSetGenerator: Only support per config Destination.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11882
Add `-Winstall-absolute-destination` diagnostic to warn or
error when an install command has an absolute destination.
This allow projects to enforce the best practice of not allowing
absolute install DESTINATIONS.
Add policy CMP0215 to emit `.swiftmodule` from a dedicated `-emit-module`
build edge for importable Swift targets in the Ninja generator.
Downstream targets can begin compiling as soon as the module interface
is ready, overlapping with upstream object compilation and linking.
When CMP0215 is NEW and CMP0157 is NEW, separate module emission is
enabled by default. The `Swift_SEPARATE_MODULE_EMISSION` target
property (initialized by the `CMAKE_Swift_SEPARATE_MODULE_EMISSION`
variable) can override this per target.
The compile edge still passes `-emit-module` so that swiftc continues
to produce `.swiftdoc`; only the `.swiftmodule` output moves to the new
edge.
Also fix swiftmodule dependency edges in cmNinjaNormalTargetGenerator
to use IsLanguageUsed instead of GetLinkerLanguage, so C/C++ targets
whose linker language propagated to Swift do not produce spurious
implicit dependencies.
Closes: #27748
99318e49b9 Help: Mention when diagnostics were added
daec98ba61 Diagnostics: Fix passing diagnostic state to try_compile
e0b0ac4295 Diagnostics: Overhaul warnings in cmake-gui
ca5d569524 Diagnostics: Switch state to new system
618c074a8c Diagnostics: Use categories for presets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !11855
Add an additional state to the cmake instance to track diagnostics. Use
this to initialize any new/reset states we create so that other contexts
will inherit the diagnostic state from presets / command-line options.
Modify the front-end to map presets and -W command-line options to
manipulation of this new diagnostic state. Remove old members for
storing diagnostic state. Rework how diagnostic state is persisted.
Deprecate old, non-standard spellings for manipulating diagnostics.
Deprecate old 'dev' spelling for CMD_AUTHOR.
Note that this is a work in progress. Messaging has not yet been
updated, so the new state is not yet being used to control diagnostics,
and some of the logic to update the old state has been stripped (and
will eventually be removed entirely). Backward compatibility support for
the deprecated CMAKE_{WARN,ERROR}_DEPRECATED variables is only partially
implemented. The GUI's interface for manipulating warnings is partially
broken and needs to be overhauled. These tasks are being done in
separate commits in order to minimize review burden and keep the changes
per commit / per merge request more manageable.
Brad King
Taylor Braun-JonesandTyler Yankee
15daksh-2003
Aiden Woodruff
Joerg Bornemann
Robert Maynard
Arha Gatram
Vito Gamberini
leha-bot
Martin Duffy
Kelvin Li
Zack Galbreath
Matthew Woehlke
Ben Boeckel
Joseph Snyder
Roman Lavrov
Marc Chevrier