It is not uncommon for packages to install cmake's bash-completion
without depending on common bash-completion helper scripts. This commit
improves compatibility in those scenarios.
e4a37fbf15 Tests/RunCMake/Swift: Add CMP0195 behavior checks
b7a78568c3 CMP0215: Update NEW behavior to require CMP0157/CMP0195 to be NEW
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12407
e4a37fbf15 Tests/RunCMake/Swift: Add CMP0195 behavior checks
b7a78568c3 CMP0215: Update NEW behavior to require CMP0157/CMP0195 to be NEW
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12407
Code extracted from:
https://gitlab.kitware.com/utils/kwsys.git
at commit f87534bd3ddedb6428ca3155852cd8b65cf09f32 (master).
Upstream Shortlog
-----------------
Ben Boeckel (2):
3d74d809 SystemInformation: clean up memory allocated with `SymInitialize`
57792988 SystemInformation: avoid reporting unrelated symbols
Jaswant Panchumarti (1):
f22a3c0f SystemInformation: restore support for symbols without PDB files
Jeremy Nimmer (1):
fbc6ddc9 SystemTools: mark impl functions as `static`
Adding checks to ensure that CMP0195 has the desired effect. If the
Swift compiler is too old and does not include the module triple in the
emitted target info, we won't set `CMAKE_Swift_MODULE_TRIPLE` and end up
with the flat directory structure. In this case, these tests won't have
the expected layout.
Issue: #28021
Update CMP0215 to avoid attempting to iterate through the flags
looking for `-emit-module-path` ins the user-specified flags. We don't
do this anywhere else in the code. The existing implementation didn't
handle correctly parsing the flag so `-I blah/my-emit-module-path/` and
`-Xcc -emit-module-path ...` would both trigger it, result in the
compiler not emitting any module. Furthermore, it didn't include the
user-specified module path as part of the build graph resulting in an
incorrect build graph that would never resolve.
The only two appropriate layouts for the module are either the flat
binary module file with the name `<module-name>.swiftmodule`, or the
nested form with
`<module-name>.swiftmodule/<module-triple>.swiftmodule`. The noted
Swift-Syntax situation passes the explicit `-emit-module-path` to get to
the latter form. This form is automatically emitted by CMake when
CMP0195 is `NEW`, removing the need for the flag. The Swift project
generally recommends the nested directory structure since it gathers all
of the generated interface outputs from the compiler (textual swift
interfaces, swiftdoc, sourceinfo, and the binary swiftmodule file) in a
single place, and since it uses the module triple in the filename,
cleanly allows fat mach-o binaries on Apple platforms.
Fixes: #28021
e420259ecc libarchive: Restore compilation of archive_parse_date within CMakeLib
5b530ba347 libarchive: Set build options the way we need for CMake
dbcd6402c3 Utilities: Update hard-coded try_compile results for libarchive 3.8.9
357710687f Merge branch 'upstream-LibArchive' into update-libarchive
94ae161ab5 LibArchive 2026-07-28 (27cbc782)
46ccf27ae3 libarchive: Update script to get 3.8.9
16984b0124 ctest: Fix STOP_TIME for vendored archive_parse_date from libarchive 3.8.8+
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !12398
Follow up commit ed48feeae8 (clang-cl: Add support for C++ modules,
2026-03-27, v4.4.0-rc1~428^2). Prevent clang-cl from interpreting
absolute source paths as flags.
Fixes: #28036
libarchive commit `422aae80ae` (Date parsing: reject date components
with numbers of more than 4 digits, 2026-05-07), backported to version
3.8.8 by libarchive commit `8cf7393f98` (Merge pull request `#3010`...,
2026-05-07, `v3.8.8~142`), disallows our non-standard hyphen-free date
format. Convert to a standard format.
Upstream libuv no longer supports these versions.
Follow up commit abac34eda2 (libuv: Restore support for macOS 10.x,
2026-03-05, v4.4.0-rc1~571^2~3). This leaves out macOS 10.4, since
a) it needs a lot more invasive changes, b) neither MacPorts nor my
PPCPorts support 10.4 anymore.
Signed-off-by: Sergey Fedorov <vital.had@gmail.com>
The TRANSFORM action registry held one live action instance per action for
the whole process, and each instance carried per-call state: a raw Selector
pointer, REPLACE's helper, APPEND/PREPEND's operands. That was harmless
while every action ran to completion uninterrupted, but commit c7af6e94d8
(list(TRANSFORM): Add PREDICATE selector, 2026-04-08, v4.4.0-rc1) added a
selector that runs a user function once per element, interleaved with the
transform. User code reentering list(TRANSFORM) with the same action now
rebinds the shared instance mid-flight. That produces silently wrong
results, and a use-after-free once any element is transformed after the
reentering one. It needs no unusual code to hit: a predicate calling
find_package(Python) reaches list(TRANSFORM ... REPLACE) inside FindPython's
own module.
Make action objects immutable and per-call. Operands and the selector become
constructor arguments, Initialize is deleted, and the registry becomes a
constexpr table of metadata with a MakeTransformAction factory. The
InSelection guard, duplicated in all eight actions, moves into the base class.
This also closes a second hole in the same machinery. TransformActionApply
overrode only the vector form of Initialize, so transform(APPLY, "f",
selector) dispatched to the empty two-argument virtual in the base, left
Selector null, and dereferenced it. With no virtual Initialize left to
inherit, an APPLY action without a cmMakefile is no longer constructible, so
the throwing stub that guarded the vector form is no longer needed.
Close a third, from commit 651f82642c (Add APPLY action for list(TRANSFORM),
2026-04-08, v4.4.0-rc1): the cmMakefile overload performs APPLY
unconditionally but validated only the arity of the action passed to it.
APPEND, PREPEND and APPLY all take one argument, so transform(APPEND, "x",
makefile) passed validation and then silently ran APPLY, calling "x" as a
function instead of appending it. Reject any action but APPLY up front.
That path is unreachable from CMake code, since HandleTransformCommand only
selects the overload for APPLY, and Tests/CMakeLib has no cmMakefile to drive
it with, so it carries no test.
Document the predicate's evaluation order while here. It runs once per
element, immediately before that element would be transformed. The manual
did not state the timing, which matters precisely because a predicate that
reenters list(TRANSFORM) observes the outer call mid-flight.
Fixes: #28031
Aiden Woodruff
Kitware Robot
Brad King
Evan Wilde
libuv upstream
Tyler Yankee
Tom Osika
huangqinjin
LibArchive Upstream
Sergey Fedorov
Mickaël Germain