422c1de564 libuv: macos: restore use of kqueue instead of posix poll
7e3519e705 libuv: macos: reap child processes more reliably when using kqueue
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9619
422c1de564 libuv: macos: restore use of kqueue instead of posix poll
7e3519e705 libuv: macos: reap child processes more reliably when using kqueue
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9619
Revert commit f54ec4e7f9 (libuv: macos: use posix poll instead of
kqueue, 2024-03-31, v3.29.1~7^2) and its parent. It is not necessary
after the kqueue-based implementation was fixed to reap child processes
more reliably.
Issue: #25839
Backport libuv commit `42cc412c4a` (darwin,process: feed kevent the
signal to reap children, 2023-02-01, `v1.45.0~55`) from libuv PR 3893.
Fixes: #25839
Upstream libuv supports passing file descriptors >= 3 to child processes
via `STARTUPINFOW` members reserved by the MSVC C run-time. However,
some programs use `GetStartupInfoW` to initialize a `STARTUPINFOW`
structure to pass to `CreateProcessW` without clearing the reserved
members. If we launch such programs with non-zero values in the
reserved members, the MSVC C run-time in *their* children may not
correctly associate the stdin/stdout/stderr streams' file descriptors
with the corresponding `HANDLE`s.
Patch our copy of libuv to avoid using the reserved members. This
restores `execute_process` support for the above-described programs as
we had prior to commit 5420639a8d (cmExecuteProcessCommand: Replace
cmsysProcess with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8).
It also enables support for such programs when launched by `ctest`.
Fixes: #25996Fixes: #25889
f54ec4e7f9 libuv: macos: use posix poll instead of kqueue
af330faaf1 libuv: darwin: group kqueue-specific definitions together
0db6402687 libuv: process: de-duplicate conditions for using kqueue
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9392
Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8) we've observed
spurious process hangs in `uv__io_poll` waiting for `kqueue` to deliver
events on macOS.
Issue: #25839
If the PATH modification choice has not been saved persistently by an
existing installation of CMake, default to modifying the system PATH
environment variable to make our command-line tools available for all
users. This is a common expectation.
Fixes: #21465
Our Windows installer provides an interactive dialog to choose whether
the PATH should be modified. It may also be specified on the `msiexec`
command-line as an `ADD_CMAKE_TO_PATH={0,1}` property. Save the choice
persistently in the Windows Registry and use the same choice by default
in future installations.
Issue: #21465
Add explicit support for passing a `ADD_CMAKE_TO_PATH={0,1}` property to
`msiexec` command-line installations to control the checkbox. Also
preserve compatibility with the old `ADD_CMAKE_TO_PATH={None,System}`
property, which previously controlled the radio button group, by mapping
the values to the checkbox.
Remove the "Add CMake to the system PATH for the current user" option.
It actually added CMake to the installing user's PATH, not the system
PATH, even though CMake is installed to a system location.
Also revise the wording of the desktop shortcut checkbox to match
the style of the PATH checkbox wording.
Issue: #21465
Brad King