16d8b65bc0 VS/Android: Use safe API level when detecting the NDK directory
f7af10100c VS/Android: Detect full NDK root instead of sysroot
850ee280e0 VS/Android: Set API level explicitly during compiler identification
5d5b6c741d VS/Android: Do not specify Windows Runtime library type during compiler id
e78abf94e3 VS/Android: Use ApplicationTypeRevision 3.0 in VS2022
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8426
Teach `ExternalProject_Add` and `FetchContent_Declare` to resolve
relative remote URLs provided via `GIT_REPOSITORY`. Add policy
CMP0150 to maintain compatibility.
Fixes: #24211
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
Visual Studio always uses a complete NDK and not a standalone toolchain.
Let CMake handle the NDK and related logic correctly, avoid trying to
find the standalone toolchain version from the unified clang toolchain
in newer NDKs.
The VS2022 Clang toolchain adds some windows libraries to the linked
library list if RuntimeLibrary is set, even if the Project is targeting
Android. This causes an unexpected linker failure.
Visual Studio 17 (Marketing name: Visual Studio 2022) still ships with
"3.0" as most recent Variant of the Android application type.
Use this revision.
The previously-used `-Werror all-warnings` is not supported by
the NVHPC suite of compilers. This previously worked since `-Werror`
was being used and `all-warnings` was being excluded.
We thought this was the correct syntax due to incorrect documentation
about `-Werror`, which stated the argument should be space-separated,
while it should actually be separated with `=` or `,`.
Issue: #24665
* Avoid searching in the `Program Files` folder because the official
OpenSSL is built for the MSVC ABI, and so is not compatible with MinGW.
* Static libraries on MinGW has `.a` extension.
The Ninja generator preprocesses Fortran separately in order to scan for
module dependencies. NVHPC's `nvfortran` does not support its `-Werror`
flag while preprocessing with `-E`, so filter it out.
Fixes: #24665
Previously we tried to match output from `xcodebuild` to detect the
path to the `swiftc` tool. This approach is used for C and CXX
for historical reasons, but is unnecessary for Swift. We know the
name of the tool, so we can just ask `xcrun --find swiftc`.
Fixes: #24666
Refactoring in commit d00d8537f6 (Modules: Use new keyword-dispatched
try_compile signature, 2022-09-16, v3.25.0-rc1~115^2) accidentally
left one of the old signature arguments behind, causing a warning.
The `FindPythonInterp` and `FindPythonLibs` modules have been deprecated
since CMake 3.12. Add a policy to pretend they do not exist in order to
encourage projects to port to `FindPython` or `FindPython{2,3}`.
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we prefer `llvm-strip` over
`strip` when using Clang. However, `llvm-strip` seems to produce
unusable binaries in cases involving chained fixups. Prefer Apple's
`strip` over `llvm-strip` on `APPLE` platforms.
We still need to consider `llvm-strip` as a fallback as explained for
`llvm-ar` by commit fee36b7a78 (BinUtils: Restore llvm-ar fallback on
Apple platforms, 2022-03-15, v3.23.0-rc4~12^2).
Issue: #24601
Some HDF5 compiler wrappers do not support source file paths that
contain spaces. Pass source files to them using a file name in the
current working directory to avoid spaces.
The `-wmo` flag added by commit 6063428de7 (Swift: Update default build
flags, 2022-10-03, v3.26.0-rc1~585^2~1) behaves differently with the old
driver. Detect when the old driver is being used, and avoid adding that
flag.
Fixes: #24641
