f5a0f6478e Merge branch 'backport-instrumentation-data-version-minor' into instrumentation-data-version-minor
dcf146c34d instrumentation: Revise Data Version format
df36317176 instrumentation: Revise Data Version format
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12117
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
Give data version the new format <major>.<minor>, so that
the version can be incremented with the introduction of new
features without bumping the major version.
Add support for loading instrumentation JSON queries of unknown
data versions without error.
Issue: #27833
Add the --source-dir argument to ctest to allow it to perform an initial
configuration step for an empty binary directory when operating in
dashboard client mode.
Preserve backslashes in arguments passed to macros by re-escaping
them before substituting in the macro body, where they will be
parsed again.
Fixes: #19281, #22157, #23641, #25803, #27645, #20891
CMake writes ConfigureCommand and MakeCommand entries into
DartConfiguration.tcl when configuring a project that uses the CTest module.
These values prevented users from being able to use configure/build presets
in dashboard client mode from a pre-configured build directory.
This commit updates ctest_configure() and ctest_build() to ignore
CTEST_CONFIGURE_COMMAND / CTEST_BUILD_COMMAND when a preset is specified.
This allows the requested preset to be honored.
Commit 63b6e7d785 (ctest: allow dashboard clients to specify presets via
variables, 2026-05-26) added support for the CTEST_PRESET family of
variables that provide users with an additional method of defining what
preset to use (if any) for dashboard client steps.
However, these variables were not being honored properly when defined
on the command-line with ctest -D. This was caused by the fact that these
variables do not have a corresponding CTest configuration setting.
Instead, they are read directly using cmMakefile::GetDefinition().
To fix this, we now inject all variables defined with ctest -D into the
cmMakefile used by CTest in ProcessSteps(). This more closely matches the
existing behavior of cmCTestScriptHandler (ctest -S mode).
In addition to fixing the newly added CTEST_PRESET variables, this also
allow users to properly define CTEST_BUILD_CONFIGURATION and
CTEST_CONFIGURATION_TYPE from the command-line.
Commit 4f120beea9 (FILE_SET: relax file uniqueness for HEADERS type,
2026-05-10) relaxed the restriction on file uniqueness in file sets, but
did not correctly update all instances of the documentation. Change the
wording to be a bit clearer and update all instances.
18d5daa7f3 file(DOWNLOAD/UPLOAD): Restore support for curl built without a TLS backend
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12104
When a built-in cache variable is set via `-D <var>=<value>` with no
help text supplied, populate `HELPSTRING` from the built-in
documentation table (sourced from `Help/variable/*.rst` and the
per-language pattern manuals). Project-defined and unknown variables
continue to receive the legacy "No help, variable specified on the
command line." sentinel.
The cache entry's type and value are left untouched: type stays
`UNINITIALIZED` for bare `-D` and an explicit `-D <var>:TYPE=<value>`
is honored as before. The `cmCacheManager::LoadCache` path is not
modified, so reload of existing caches is a fixed point.
Fixes: #27830
Detect when the requested module name differs in case from the module
filename on disk. Emit an author warning on Windows and Apple
platforms, where case-insensitive lookup can hide portability problems
on case-sensitive filesystems.
Fixes: #27811
Since commit 38390245a2 (ctest: Require minimum TLS 1.2 by default,
2024-09-23, v3.31.0-rc1~47^2), our TLS-1.2 default fails with a curl
built without any TLS backend, causing even `file://` and `http://`
URLs to fail. Teach CMake to recognize both ways libcurl may report
that it was built without TLS support.
Fixes: #27849
Brad King
Kitware Robot
Zack Galbreath
Daksh Mamodiya
Marc Chevrier
Vito Gamberini
Daniel Pfeifer
Martin Duffy
Arha Gatram
Tom Osika
Alex Reinking
Matthew Woehlke
Richard