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
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`.
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.
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>
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
Since commit ebc9e448b3 (Autogen: Add depfile support for Makefiles,
2023-09-07, v3.28.0-rc1~101^2~1) CMake does not generate the correct
dependency graph when both `Makefile` and `DEPFILE` are used.
The build of `<target_name>_autogen_timestamp_deps` fails due to
missing dependencies. To tackle that problem, forward target
dependencies to both `<target_name>_autogen_timestamp_deps` and
`<target_name>_autogen` instead of just `<target_name>_autogen`.
Fixes: #25600
The upstream freetype cmake package uses generator expressions and
imported target to express its dependencies. That's fine on its own.
However, our use of it since commit d83d925045 (FindFreetype: use
`freetype-config.cmake` if available, 2023-09-06, v3.28.0-rc1~130^2)
causes the `FREETYPE_LIBRARIES` result variable to reference those
imported targets and create a package-level dependency for clients that
did not exist previously. Revert that change for now, along with its
follow-up fixes. Further investigation will be needed to solve the
motivating use case another way.
Fixes: #25635
The previous code used `char **` and `const char **`` types as if they
were the same. But they are distinct types in C, so when passing
these pointers as function arguments, their types have to match.
Future C compilers will treat this as an error, similar to what
C++ compilers do today.
Wide use of CMake 3.28.{1,0[-rcN]} has uncovered some hangs and crashes
in libuv SIGCHLD handling on some platforms, particularly in virtualization
environments on macOS hosts. Although the bug does not seem to be in CMake,
we can restore stability in the CMake 3.28 release series for users of such
platforms by reverting our new uses of libuv for process execution.
Revert implementation changes merged by commit 4771544386 (Merge topic
'replace-cmsysprocess-with-cmuvprocesschain', 2023-09-06, v3.28.0-rc1~138),
but keep test suite updates.
Issue: #25414, #25500, #25562, #25589
On Windows, in a GUI process without a console, the `std{in,out,err}`
standard FILE streams may not be open. Avoid passing an invalid file
descriptor to the child process, and let libuv attach NUL instead.
Fixes: #25625
b8665d44ba FindMatlab: Fix error message from function
44d2cf3ed4 FindMatlab: Document all registry paths for version lookup
363a7d4693 FindMatlab: matlab_get_release_name_from_version is a function now
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Merge-request: !9175
