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()`.
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
Backport commit 79a83ddb08 (Apple: Enable linking during
iOS/tvOS/visionOS/watchOS toolchain inspection, 2024-11-14,
v4.0.0-rc1~471^2) to 3.31.
Since commit 11da882a12 (Apple: Introduce separate system name for iOS,
tvOS, and watchOS, 2018-01-15, v3.14.0-rc1~14^2~1) our toolchain
inspection steps, like ABI detection, tell `try_compile` to use a
`STATIC_LIBRARY` instead of an `EXECUTABLE`. This was needed at the
time to avoid codesign requirements. However, commit d3a64c4e3f (Xcode:
Explicitly turn off signing in try_compile projects, 2020-07-16,
v3.19.0-rc1~483^2) introduced a more general solution to that problem.
Restore linking during toolchain inspection so that we can detect and
identify the linker.
Suggested-by: Marc Chevrier <marc.chevrier@gmail.com>
Fixes: #26443
9d302ecd47 ci: update macOS jobs to use Xcode 26.0 in CMake 3.31 branch
f6f1c5ca1f Tests: Teach RunCMake to ignore Xcode an IDERunDestination warning
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11292
On some Xcode versions, `xcodebuild` may warn:
... xcodebuild[...] IDERunDestination: ...
Teach RunCMake to drop such incidental lines before matching against
expected output.
Backport commit edaa6ed06a (Tests: Teach RunCMake to ignore Xcode an
IDERunDestination warning, 2025-09-19, v4.1.2~9^2~1) to CMake 3.31.
Since upstream curl commit `1a12663d06` (CURLOPT: bump `CURLPROXY_*`
enums to `long`, drop casts, 2025-07-28), the `CURLPROXY_*` constants
are integer literals instead of `enum curl_proxytype`. It turns out
that `curl_easy_setopt` has always expected a `long` anyway, and that
`curl_proxytype` is not documented for public use.
Fixes: #27178
3ff777de12 CUDA: Update CUDA tests to handle CUDA 13 deprecations
bbf732525a CUDA: Add CUDA 13.0 support to 'all' and 'all-major' architecture tables
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11015
Curl 8.15 removed support for Secure Transport and deprecated the
corresponding `CURLSSLBACKEND_SECURETRANSPORT` constant. We still need
the constant in a workaround for a runtime-checked range of older curl
versions. Suppress the deprecation warning at compile time.
Fixes: #27086
Upcoming versions of nvcc are adding support for `SYSTEM_INCLUDES`
which contain includes that are implicitly used with `-isystem`
instead of `-I`.
Support of this is needed in CMake as some CUDA Toolkit releases will
start to have a different include directory layout and using only the
output from `INCLUDES` will be insufficient to find all headers.
Clang before 20.1 does not recognize sm_100 and newer. Revise:
* commit b2251e0deb (CUDA/Clang: Update architectures supported by
CUDA 12.8, 2025-02-04, v4.0.2~4^2~1^2)
* commit a1b4c30f24 (CUDA: Add CUDA 12.9 new architectures and family
syntax, 2025-04-21, v4.0.2~3^2^2)
e37a40442a ci: Update Windows builds to MSVC 14.44 toolset
c955d5c31f ci: Tie Intel 2024.1 jobs on Windows to MSVC 14.43 toolset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10802
41a4a32135 FindPython: Avoid implicit link library on Windows
811f00f9ad FindPython: rely on ABIFLAGS on Windows for ABI profile
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10800
