077a1d5769 libuv: win/spawn: optionally run executable paths with no file extension
f02ac51150 libuv: Revert "win/spawn: run executables with no file extension"
58a271e60b cmUVProcessChain: Implement no-extension-on-Windows support with libuv 1.48
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9238
077a1d5769 libuv: win/spawn: optionally run executable paths with no file extension
f02ac51150 libuv: Revert "win/spawn: run executables with no file extension"
58a271e60b cmUVProcessChain: Implement no-extension-on-Windows support with libuv 1.48
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9238
Backport libuv commit `3f7191e5` (win/spawn: optionally run executable
paths with no file extension, 2024-02-05, v1.48.0~8) to add the
`UV_PROCESS_WINDOWS_FILE_PATH_EXACT_NAME` option we now use.
Issue: #25450
This reverts commit fc6231bee5 (libuv: win/spawn: run executables with
no file extension, 2023-12-04, v3.28.0~9^2) to make room for the
corresponding fix from upstream libuv 1.48.
Record this as a merge from the last-imported upstream libuv snapshot
branch so that future `git blame` points to the upstream for the
original code instead of this commit.
Issue: #25450
Partially revert commit dc9d9589e4 (FindMatlab:WIN32: return full Matlab
version when found via registry, 2023-09-14, v3.28.0-rc1~82^2~2). It
changed `matlab_extract_all_installed_versions_from_registry` behavior
to query `VersionInfo.xml` for version information. However, the
function documentation states that it only uses the registry. It's also
not needed since commit c608adc236 (FindMatlab: Fix major.minor version
lookups in Windows Registry, 2024-01-11, v3.28.2~13^2~1), which added
the same lookup to `matlab_get_all_valid_matlab_roots_from_registry`.
`find_package_check_version()` would use variable `_FOUND_VERSION` set
by `find_package_handle_standard_args()` in a single branch when doing
exact matching, causing empty version messages if it was instead called
directly.
This was missed in commit 6bfc442fde (FPHSA: add support of version
range, 2020-09-22, v3.19.0-rc1~122^2~1) when the version check was moved
into its own function.
Since commit LLVM/Clang commit `5523fefb01c2` ([clang][lex] Use
preferred path separator in includer-relative lookup, 2023-09-08), part
of the upcoming 18.x release, the output format of the showIncludes flag
has changed, where it now prints paths with double backslashes:
Note: including file: .\\foo.h
Previously, we expected to see the path name in the form "./foo.h".
Extend the regex to match a path name starting with `.\`, in addition to
the existing matched patterns.
ba6f3f25ee Configure CMake itself with policies through CMake 3.28
c432365e10 export: Increase maximum policy version in exported files to 3.28
9c5e981e60 Add deprecation warnings for policies CMP0128 and below
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9224
The files generated by `install(EXPORT)`, `export()`, and
`install_jar_exports()` commands are known to work with policies
as of CMake 3.28, so enable them in sufficiently new CMake versions.
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.22 and below to encourage projects to port
away from setting policies to OLD.
Brad King