A step with a custom command shouldn't be seen as out-of-date
just because the user re-runs configure with a different log level.
Previously, the log level was written directly to the step scripts,
but that meant the script changes if the user specifies a different
effective log level to the previous configure. Now we move the
log level detection into the script so that the script remains the
same no matter what log level the user asks for.
This was most noticeable with the PATCH step, since that always
uses a custom command when present. Changing the log level
would cause the PATCH step to re-run, which usually results in
an error because PATCH typically only expects to run once after
a DOWNLOAD. But the underlying problem would affect any step
with a custom command, not just PATCH.
Fixes: #28055
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
21cc5937c1 install(TARGETS): Factor out reusable helpers with config-specific support
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12496
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
Use Levenshtein distance to track when the user may have made a typo in
an argument to `cmake -E` (i.e., an invalid mode; mode sub-arguments
are not tracked).
Use Levenshtein distance to track when the user may have made a typo in
an argument to `cmake`, `cmake --build`, `cmake --install`, or
`cmake --workflow`.
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 IS_PREFIX test asserted four cases: duplicate separators collapsing,
a non-normalized '..' in the prefix, and two NORMALIZE cases. None of
the rules a caller is most likely to get wrong were covered.
Add assertions for the non-strict self-prefix, trailing separators on
either operand, '.' components, the sibling-prefix trap, the absence of
relative-to-absolute reconciliation including the root directory, and
the empty path. Add a host-path-model block covering backslashes, case
sensitivity of both ordinary components and the root-name, drive-
relative paths, and UNC root-names.
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.
A tool that opens the container picks a workspace path of its own when
the configuration names none, and `.gitlab/ci/devcontainer-run.sh` mounts
the source tree at a path it spells itself. The two disagreed: an editor
opened the tree at `/workspaces/cmake` while CI used the
`/home/cmake-dev/workspace` that `create_user.sh` prepares for it. Say
which one it is, so that a path means the same thing everywhere.
d8ade0500e Find{BLAS,LAPACK}: Provide full paths in `{BLAS,LAPACK}_LIBRARIES` with NVPL
cdf4234bc4 Find{BLAS,LAPACK}: Only search for the needed components of NVPL
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12484
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>
The sentence packed the two purposes of the mounts and their effect into
one clause chain, which was hard to follow. Split it in two.
Suggested-by: Tyler Yankee <tyler.yankee@kitware.com>
Brad King
Kitware Robot
Craig Scott
Robert Maynard
Tor Arne Vestbø
Stepanov Igor
Tyler Yankee
Joerg Bornemann
Mickaël Germain
Taylor Braun-Jones
Ben Boeckel