53019cd2e6 install(TARGETS): Add option to install runtime deps built as other targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12483
Follow the approach from commit 92320466dd (try_compile: Restore
platform-default link flags in pre-CMP0210 projects, 2026-08-22)
to make the CMP0181 policy setting available in `try_compile`
projects before the toolchain file is loaded.
Fixes: #28108
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
cmake_path(IS_PREFIX) and $<PATH:IS_PREFIX> treated an empty path as a
prefix of every path, including another empty path, following
std::filesystem::path. A prefix that is empty because a variable was
set to an empty value, or because a generator expression argument
expanded to nothing, therefore satisfied a check meant to reject it.
Return false for an empty prefix, in cmCMakePath::IsPrefix so that every
caller shares one implementation and both the plain and NORMALIZE forms
are covered. Normalizing an empty path leaves it empty, so no separate
handling of NORMALIZE is needed. Unlike the component comparison, which
follows std::filesystem::path deliberately, IsPrefix has no counterpart
in the standard: it borrows path iteration but the predicate itself is
defined by CMake, so an empty prefix is a gap to fill rather than a
standard answer to override.
Add policy CMP0223 and restore the old result behind it at the two
released surfaces. The other callers of IsPrefix, source_group() and
the Makefile generator's source classification, take the new behavior
ungated: source_group() rejects an empty TREE argument before reaching
it, and the generator passes the source and binary directories.
The if(PATH_IS_PREFIX) operator, new in this same release, follows the
policy too rather than simply taking the new behavior, so that it agrees
with cmake_path(IS_PREFIX) in every policy state and the parity
assertions in its test hold unconditionally.
Fixes: #28077
Adjust documentation of `install(CODE|SCRIPT)` to more understandably
reflect how the subcommand actually operates. Adjust argument parsing of
the same to "accept" the `COMPONENT` argument being given more than
once, consistent with how single-valued arguments are usually parsed.
Evaluate the XCODE_EMBED_<type> target property through the generator
expression evaluator before building the copy-files phase. Xcode shares
one copy-files build phase across all configurations, so the embedded set
cannot vary by configuration. Reject any expression whose result depends
on the configuration, matching the existing per-source diagnostic.
Fixes#28082
f1b6b3a6f0 devcontainer: Run local customization hooks through the container's life
3cfbea10e4 devcontainer: Name the workspace path explicitly
f8f4dc7f43 gitlab-ci: add a job to verify the devcontainer in CI
ea0667e779 ci: add scripts to run and verify the devcontainer
9c17332601 devcontainer: Add `clang-tidy`, `clang-tools`, and `clazy`
a8872df649 devcontainer: Add `clang`, `gfortran`, and `valgrind`
8bd053379f devcontainer: Reword the comment on caching package downloads
7ae5c3cfb2 devcontainer: Add the Kitware APT repository
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12423
Process C++ module interface and partition units that are members of a
FILE_SET of type CXX_MODULES. moc is run on such units and its
generated output is compiled as a module implementation unit of the same
module, as its own scanned translation unit rather than folded into
mocs_compilation.cpp. Macro-less units get an empty placeholder; module
units and their dependencies are tracked in the autogen depfile and as
byproducts for correct incremental rebuilds.
This requires Qt 6.13, whose moc supports C++ module units. With older
Qt nothing can be generated for a module unit, so a meta-object macro
found in one is reported as an error rather than left to fail later in
the compiler or the linker. Such a unit is no longer handled as an
ordinary source, which also means its moc include directives are not
honored and AUTOUIC does not process it.
moc rejects a meta-object macro in a module implementation unit or a
private module fragment, and AUTOMOC does not work around that.
Testing whether one path is a prefix of another is possible today with
cmake_path(IS_PREFIX), but the idiom needs a separate statement plus a
scratch variable and takes the prefix as a variable name, so projects
reach for if(path MATCHES "^${prefix}") instead. That is wrong whenever
the prefix contains a regex metacharacter, and it accepts siblings,
because '^/a/b' matches '/a/bc'.
Add a binary operator where the left operand is the candidate prefix and
the right is the path, matching the operand order of cmake_path(IS_PREFIX)
and $<PATH:IS_PREFIX> so that the same operation reads the same way on all
three surfaces. Neither operand is normalized, matching the default of
cmake_path(IS_PREFIX) and the existing PATH_EQUAL operator, so '.' and
'..' are compared as ordinary components. The test is non-strict, purely
lexical, and applies no relative-to-absolute reconciliation.
Add policy CMP0222 for compatibility, modeled on CMP0139. The keyword
is consumed as an operator only when it appears in the second argument
slot, so a variable named PATH_IS_PREFIX keeps working in unary and
left-operand position. What the policy covers is such a variable
appearing after another token, as in if(NOT PATH_IS_PREFIX AND other),
which becomes a configure error under NEW.
Since the operator is an if() spelling of cmake_path(IS_PREFIX) and shares
its implementation, test it by asserting the two agree over a corpus of
inputs rather than by restating expected values. Those are pinned by the
cmake_path(IS_PREFIX) test, so the operator's tests stay limited to what
has no command equivalent, and no platform branching is needed because
parity holds whatever the host path model answers.
Fixes: #28040
The container ran a developer's own `hooks/root.sh` and `hooks/user.sh`
while the image was built, and nothing of theirs afterwards. A
customization that has to start something, or to reach the source tree,
had nowhere to run: the tree is not mounted during the build, and the one
lifecycle command the configuration used was spoken for by the status
report.
Run an optional script per phase through `run-hooks.sh`, and offer five:
`initialize` on the host, `build` in the image, and `post-create`,
`post-start` and `post-attach` in the container. A failing `build` hook
fails the image build, because an image whose customizations did not
apply is quietly wrong; the rest are reported and otherwise ignored, so
that a typo in a personal hook cannot leave its author unable to open the
container in order to fix it.
The two build hooks become one, running as the container user, who may
`sudo`: one hook that reaches either user is simpler to write against
than two that each reach one. Every hook is told where it lives, and
every hook but the build one is given a directory to keep state in,
beside the hooks rather than among them because state is written by
whatever they start rather than by hand. `.dockerignore` keeps that
directory out of the build context, which state written as `root` would
otherwise make unreadable.
Provide the analysis tools our CI images carry: `clang-tidy` to run the
checks in `.clang-tidy`, `clang-tools` for `scan-build`, and `clazy`, the
compiler our Clazy job builds with.
Name the version of `clang-tidy` our checks are written against rather
than install Ubuntu's unversioned package, which is a release behind and
reports `cmake-use-cmsys-fstream` where it should not. `CMakeLists.txt`
searches for `clang-tidy` only under the unversioned name, so link the
version installed by name to it, as we already do for `clang-format`.
`clazy` and `clang-tools` remain whatever versions Ubuntu carries rather
than the ones the CI image does, so expect their diagnostics to differ
from those jobs'. CMake's own clang-tidy checks are not available either
way: `CMake_USE_CLANG_TIDY_MODULE` needs `Utilities/ClangTidyModule` built
against Clang's development files, which are not installed here.
Suggested-by: Tyler Yankee <tyler.yankee@kitware.com>
Provide `clang` for developers who prefer to build with it rather than
with the default `g++`, and `valgrind` to run CMake and its tests under a
memory checker. The sanitizer runtimes already come with both
compilers, so building with `-fsanitize=` needs nothing installed.
Name `gfortran` as well, without which Clang cannot link at all. Ubuntu
26.04 carries a Fortran-only `gcc-16` build that provides no C++ standard
library, `libopenmpi-dev` lists `gfortran-16` first among the
alternatives it accepts, and Clang selects the newest GCC installation it
finds. Naming `gfortran` lets `apt` satisfy that dependency with
`gfortran-15` instead, so the GCC 16 installation never appears.
Suggested-by: Tyler Yankee <tyler.yankee@kitware.com>
Configure `apt.kitware.com` in the development container so that `cmake`
is the latest CMake release rather than the older one Ubuntu carries, and
so that developers reach each further release through `apt-get` alone.
Fetch the repository's signing key, verified against the hash the
`Dockerfile` pins, and trust it just long enough to install
`kitware-archive-keyring`, which then provides the key, so that `apt`
follows the rotations Kitware makes to it. Interpolating the hash into
the step that fetches the key also busts the build cache when the hash
changes, so a rotation is picked up rather than served from an old layer.
Reaching either the key or the repository needs `curl` and a certificate
store, neither of which the base image carries, so install them first.
Install `glab`, the GitLab CLI, and `glab-axi`, an agent-ergonomic
wrapper around it, in the development container.
Default `GITLAB_HOST` to `gitlab.kitware.com` so that both address our
GitLab instance without further configuration, persist the `glab`
configuration directory on a volume so that a credential need be created
only once, and pass a `GITLAB_TOKEN` or `GITLAB_CLIENT_ID` from the host
through to the container.
Neither tool can authenticate on its own, so check for a working
credential each time a tool attaches to the container and print what
remains to be set up if there is none.
Provide a `.devcontainer` definition, following the Dev Container
Specification, to give contributors a ready-made Linux environment with
the tools needed to build CMake, run its test suite, build its
documentation, and satisfy its style rules.
Base the container on Ubuntu, which offers the broadest ecosystem of
packages and tooling for development, including a recent `cmake` and the
`clang-format` version our style rules require, exactly. Mirror the
package lists of the Debian image our CI infrastructure uses, section by
section, so that the dependencies available closely match the ones
against which merge requests are tested. Build the image the way the
images under `.gitlab/ci/docker/` are built: bind mount the package
lists and the installation script rather than copying them in, and cache
the package lists and downloaded archives so that a rebuild fetches only
what has changed.
Run optional `.devcontainer/hooks/root.sh` and
`.devcontainer/hooks/user.sh` scripts, both ignored by Git, so that
developers may customize the container without modifying tracked files.
Document usage in a new `Help/dev/devcontainer.rst`.
Fixes: #28043
Brad King
Stepanov Igor
Tyler Yankee
Martin Duffy
Marc Chevrier
Taylor Braun-JonesandTyler Yankee
Mickaël Germain
Matthew Woehlke
Tor Arne Vestbø
Joerg Bornemann