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
Selecting a configure preset applies on the worker thread, but Configure
and Generate stayed enabled and could snapshot the stale cache model
first. Tokenize preset application, disable the dependent actions until
the completion lands, and accept only the latest request.
Fixes: #28085
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
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.