Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8) we have not
actually terminated child processes on an `execute_process` timeout.
Similarly for other migrations from cmsysProcess to cmUVProcessChain.
Teach cmUVProcessChain clients that implement timeouts to actually
terminate remaining child processes when the timeout is reached.
Fixes: #27378
Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8) we have not
actually terminated child processes on an `execute_process` timeout.
Similarly for other migrations from cmsysProcess to cmUVProcessChain.
Teach cmUVProcessChain clients that implement timeouts to actually
terminate remaining child processes when the timeout is reached.
Fixes: #27378
f357fc27e5 CPack: Backport "correctly perform querytags on old versions of RPM"
1803eda9f7 CPack/RPM: Backport "Fix detection of RPM support for weak dependencies"
d2404872b2 CPack/RPM: Backport "Remove redundant conditions for presence of rpmbuild"
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11400
Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8) we've
occasionally observed immediate timeouts on processes that take longer
than the timeout to start, even though we only start the timer after the
child processes start. The problem is that:
* `uv_loop_init` initializes `uv_loop_t`'s cached "now" time.
* Starting processes takes time but does not update the "now" time.
* `uv_timer_start` computes expiry relative the cached "now" time,
so short timers may be expired as soon as they are started.
* `uv_run` invokes expired timer callbacks before polling for I/O
or process completion, so we "timeout" immediately.
Fix this by updating the cached "now" time via `uv_update_time` just
before starting timers. This is needed only for timers that start
before the `uv_run` event loop. Update our `uv_timer_ptr` wrapper
to make all callers consider the choice when calling `start()`.
Restore commit 4cb616fed6 (Tutorial: Provide a source archive when
published on cmake.org, 2022-04-27, v3.23.2~22^2). Its effects were
accidentally reverted by commit 9784834b4c (Help: Use `*.rst` extension
for included files, 2025-04-07, v4.1.0-rc1~354^2).
Reported-by: Vito Gamberini <vito.gamberini@kitware.com>
When CPS export fails due to a dependency on an improperly named
external target, reiterate the "canonical namespace" in the error
message for clarity.
When given the name of a project that doesn't exist, report it as an
"unknown project" rather than an "invalid project". This is more
consistent with other, similar reporting.
Xcode by default targets the SDK's macOS version rather than the host's
macOS version. In commit 7b19531291 (macOS: Do not pass any
SDK/-isysroot to compilers by default, 2024-11-06, v4.0.0-rc1~511^2) we
reverted commit 24aafbde11 (Xcode: Adjust deployment target SDK version
to host version, 2015-10-11, v3.4.0-rc2~6^2), but it is still needed for
Xcode. Restore the behavior so binaries run on the host by default.
Fixes: #27309
Since commit 965a12cb8a (ci: update macOS jobs to use Xcode 26.0,
2025-09-18, v4.1.2~9^2) and commit 9d302ecd47 (ci: update macOS jobs to
use Xcode 26.0 in CMake 3.31 branch, 2025-10-07) our macOS 10.13+
packages are built using the macOS 26 SDK, with which Qt 5.15.2 does not
render buttons in `cmake-gui` correctly. Revert to an older macOS SDK
to avoid the problem until we update our Qt version.
Fixes: #27325
With Xcode 16.4, run
env SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk \
.gitlab/ci/repackage/macos.sh
and host `MacOSX15.5.sdk.tar.bz2` ourselves.
7f628ea04b FindPython: Add support for Python 3.15
5b78983813 Tests/FindBoost/TestPython: Improve python version list formatting
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11350
Brad King