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
In debug builds, we assert and abort to give more useful crashes for
development (i.e., instead of triggering UB). Otherwise, we get the
optimization benefits of `unreachable()` (or the older
platform-specific fallbacks per `cm/utility`).
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
Save original input value of CMAKE_TOOLCHAIN_FILE also before
normalization or relative searching to avoid reconfiguring because the
full path doesn't match the input. Tests correct behavior avoiding
reconfigures and ensuring reconfigure on toolchain change from preset.
Fixes: #24942
Prior to commit 243462fafe (try_compile: Tolerate compile features from
non-enabled languages, 2026-05-18, v4.4.0-rc1~84^2) we accidentally
tolerated toolchain files setting `CMAKE_<LANG>_COMPILER_LOADED`.
Meson accidentally relied on this, so restore toleration of it.
Fixes: #27971
Replace __CMAKE_DELETE_CACHE_CHANGE_VARS_ with a set of changed
variables in cmState to avoid interference from scripts and simplify
handling of changed variables.
Errors during configure step will block re-configure when the toolchain
file has changed. Downstream errors can be caused by failing in
EnableLanguage without an error, behavior introduced in 7a989ed58a
(CMAKE_TOOLCHAIN_FILE: Detect path changes and reset cache, 2026-06-24).
Errors directly related to a changed toolchain file should be fixed by
using the new one.
Trigger a fatal error when the toolchain file change is detected to
avoid wasteful configure that will be reset anyway, then re-configure
only for that specific case. Avoid re-configuring multiple times.
Fixes: #27867
Move some target related enumeration types from `cmStateTypes.h` to a
new header, as these really aren't "state" types. Also, make
`TargetType` a strongly-typed enumeration.
Add an --out-of-date option to ctest which runs only those tests with
recorded build dependencies whose timestamps are newer than the timestamp
at which the test last finished.
Fixes: #27614
If the path to the toolchain file changes then anything in the cache
that's derived from the toolchain may need to be recomputed. Detect
this case and start a fresh build.
Issue: #27867
Signed-off-by: Aiden Woodruff <aiden.woodruff@kitware.com>
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
Usage effects describe the relationship between a provider and a
consumer of C++ module interface units. They encompass the flags and
features used to construct BMIs for those units. If the usage effects of
a provider and consumer match, then the provider's BMI may be reused
as-is. If they do not match, then a synthetic target describing the
interface units with the consumer's usage effects applied must be
created.
This commit makes three major changes to how usage effects are reified
in CMake. The first is simple, usage effect hashes now use compile
options and features as the input to their hash instead of the consumer
name. A simply warning flag filter is also applied, mostly to
demonstrate the mechanism. This is the "correct calculation" for usage
effects.
The second is more impactful, usage effects now entirely replace the
compile options of providers with those of consumers if unmatched.
Compile definitions, includes, and links remain unchanged. This is
necessary to ensure successful builds, but is a tricky semantic change.
The third is mostly source-facing, the discovery model for CxxModule
synthetic targets is no longer the global target namespace. Instead,
non-synthetic targets manage their synthetic derivatives. Every target
maintains a usage effect-keyed cache of synthetic targets. When
determining if a synthetic target is necessary, a given provider checks
for compatibility with itself, then for presence in the cache, and if
the cache misses a new synthetic target is created.
Fixes: #27597
243462fafe try_compile: Tolerate compile features from non-enabled languages
bbab63839b cmGlobalGenerator: Clarify name of try_compile-specific member
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12083
575c3dd990 builddb: support builds with empty configuration
3469cc0a46 Tests/CXXModulesCompile: add a test for builddb with empty config
bf442e9deb Tests/CXXModulesCompile: fix `exp-builddb` name references in check scripts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !12101
Add and use a couple helper functions for issuing policy warnings. This
improves consistency and allows some simplification of many call sites.
(One or two instances in particular are greatly simplified.)
Add new diagnostic categories CMD_POLICY and CMD_EXPERIMENTAL, both as
children of CMD_AUTHOR. Use the former when issuing policy warnings. Use
the latter when issuing experimental feature warnings.
Issue a warning message rather than a deprecation diagnostic when 'extra
generators' are used. This prevents `-Wno-author` suppressing the
message, which really isn't a diagnostic for authors as it relates to
how CMake was invoked.
When issuing the policy warning that `codegen` is a reserved target
name, use the diagnostic context in which the target was declared,
rather than the root context (which cannot be affected in script).
Modify `cmInstallGenerator` to have a `cmDiagnosticContext` instead of
just a `cmListFileBacktrace`. Create helpers to obtain a state capture
that includes `CMD_INSTALL_ABSOLUTE_DESTINATION`. Modify most subclasses
(namely, ones that have a `DESTINATION`) to use this new state capture.
This fixes a limitation identified when 39a56136a3 (Diagnostic: Add warn
or error on absolute install paths, 2026-03-25) added the aforementioned
diagnostic, that the install generator(s) no longer have access to the
diagnostic state as of the `install` invocation which ultimately caused
the diagnostic if that scope is not the top-most scope of the current
subdirectory.
Note that some of the generators which capture context have not actually
implemented the diagnostic yet.
Find places that are currently relying on diagnostic-specific message
types to issue diagnostics and replace these with calls to the new
diagnostic methods.
Each Rust source file given to a target is considered a separate crate
root. There's a concept of a "main crate root", which is the `.rs` file
that is given to the final linker phase in CMake. Other Rust source file
in a target are built as rlib separately.
The project can still build `.rs` files into object files by setting the
Rust_EMIT property on the desired source file.