Use the same flags Xcode adds for `XROS_DEPLOYMENT_TARGET`. They are
`-target arm64-apple-xros1.0` and `-target arm64-apple-xros1.0-simulator`,
where `1.0` is the deployment target version.
Fixes: #25188
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
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.
Replace commit 76b5383123 (cmGlobalGenerator: add unity sources after
computing target compile features, 2024-01-01, v3.28.2~17^2~1) with an
alternative change. This merge commit resolves conflicts such that
future `git blame` calls will follow the second parent for the relevant
lines and pretend the replaced commit never existed.
Fixes: #25650
Sources that will be scanned for C++ module dependencies need to be
excluded from unity builds. We need to compute compile features in
order to know which sources will be scanned. Unity build and PCH
sources can be added afterward without changing the compile features.
This re-implements commit 76b5383123 (cmGlobalGenerator: add unity
sources after computing target compile features, 2024-01-01,
v3.28.2~17^2~1) using a simpler approach that also preserves support for
PCH with Unity builds.
Issue: #25650
Co-authored-by: Ben Boeckel <ben.boeckel@kitware.com>
When CMake is built against the MSYS runtime library, `uname()` returns
a name that depends on the `MSYSTEM` environment variable. Previously
we truncated `MSYS_...` to just `MSYS`, but outside `MSYSTEM=MSYS`
environments, names like `MINGW64_NT-10.0-22000` were reported.
The latter causes CMake to report an unsupported-platform error, which
users report as an issue when the real problem is that they should be
using a `MSYSTEM=MSYS` environment or a CMake that is not built against
the MSYS runtime.
For our purposes, if CMake is built against the MSYS runtime, the host
platform is always `MSYS`. Similarly for `CYGWIN`.
d0bedb2170 Autogen: Forward dependencies when both Makefile and DEPFILE are used
4deb9c41b8 cmQtAutoGenInitializer: Improve Const-correctness
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9190
339ae33e55 CPack: Change CPACK_PRODUCTBUILD_DOMAINS default to true (CMP0161)
4e7f2397e4 CPack: Clear temporary variable after it is no longer needed
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9197
Evaluate generator expressions in these properties, as they apply to
`add_test`, `add_custom_command`, and `add_custom_target`.
The `CMAKE_CROSSCOMPILING_EMULATOR` variable's `try_run` behavior occurs
at configure time and so cannot support generator expressions.
Brad King