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
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
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
61d0bdf6b7 macOS: Avoid relying on sw_vers when cross-compiling from another OS
d9d65ab54f macOS: Remove outdated condition for CMAKE_OSX_DEPLOYMENT_TARGET
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11340
61d0bdf6b7 macOS: Avoid relying on sw_vers when cross-compiling from another OS
d9d65ab54f macOS: Remove outdated condition for CMAKE_OSX_DEPLOYMENT_TARGET
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11340
We have a few code paths needed only to support builds hosted on
macOS 10.4. Update the conditions to work when cross-compiling
to macOS from another platform.
This backports commit eb8facd396 (macOS: Avoid relying on sw_vers
when cross-compiling from another OS, 2025-04-28, v4.1.0-rc1~260^2)
to CMake 4.0.
Fixes: #26814
Revert commit 2853326e7a (BUG: Only set CMAKE_OSX_DEPLOYMENT_TARGET on
Mac OSX 10.4 or later, 2009-01-27, v2.8.0~1169). AFAIK no one is using
macOS versions older than 10.4 anymore.
This backports commit 476b2a386f (macOS: Remove outdated condition
for CMAKE_OSX_DEPLOYMENT_TARGET, 2025-04-28, v4.1.0-rc1~260^2~1)
to CMake 4.0.
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
Since commit 13c7bb5b0c (cmGeneratorExpression: Update strip function to
collect parsed expressions, 2025-04-08, v4.1.0-rc1~361^2~1), the logic
to strip generator expressions would error if the stripped expressions
were being collected and an expression without a `:` was found inside an
expression with a `:`. This resulted in an error when exporting a target
that contained such a generator expression in its link libraries or
compile definitions.
Address the error by checking whether the latest `$<` proceeded the
latest `:`.
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
Brad King