Revise the version check from commit e14300816b (librhash: aligned_alloc
is not available with glibc < 2.15, 2024-02-14, v3.29.0-rc2~30^2).
Issue: #25679
10abd2ac5a FindPython: ensure a usable environment is set for the free threaded Python
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9775
Define the `Python_DEFINITIONS` variable for the support of free
threaded Python developments on Windows.
This is a complement to commit 9a0dee7257 (FindPython: Add support for
free threaded python, 2024-05-30).
Fix commit df551ee538 (FindPython: fix NumPy detection when Intel MKL
library is installed, 2024-03-20, v3.30.0-rc1~361^2) by setting
`MKL_ENABLE_INSTRUCTIONS` to `SSE4_2`, but only if
`MKL_ENABLE_INSTRUCTIONS` is not set in the calling environment.
Fixes: #26240
`NDK_PROC_*_ABI` and `NDK_ARCH_*_ABI` were removed in the Android
NDK 27 but will be reintroduced in the Android NDK 27b:
* https://github.com/android/ndk/issues/2049
* https://android-review.googlesource.com/c/platform/ndk/+/3196345
Both are only used when `CMAKE_ANDROID_ARCH_ABI` is NOT given. But
currently the existence is also checked when `CMAKE_ANDROID_ARCH_ABI`
is given. So we move the checks to the position they are required.
"Console" unexpectedly matches the reserved name regex. This revealed
that `cmCPackNSISGenerator::CreateComponentDescription()` needs to use
the name returned by `GetSanitizedDirOrFileName()` for the component
file glob.
Fix the change from commit a1af593291 (CPack: Support arbitrary
component name when packaging, 2024-05-01, v3.30.0-rc1~151^2~1) to
address these issues and add related checks to the `CPackNSISGenerator`
test case.
Issue: #23612
Improve the changes from:
* commit efa0e2ddaf (FindJNI: Update for Xcode greater than 12.1 on macOS,
2023-08-06, v3.27.2~5^2)
* commit 597139b853 (FindJNI: Restore support for macOS without Xcode,
2023-08-11, v3.27.3~8^2)
to avoid leaking `xcodebuild`'s stderr.
Issue: #26229
Formerly only the "client" and "server" variant directories are being
checked for libjvm.so, but according to a 2021 OpenJDK upstream change
present in OpenJDK >= 18, there can be "minimal" and "zero" variants as
well. In particular, formerly (OpenJDK <= 17) the Zero variant had its
libjvm.so in "server/", but "zero/" in newer versions, which regressed
downstream CMake project builds running on systems with OpenJDK Zero VM.
Fix it by checking all 4 variant directories for libjvm.so.
Link: https://bugs.openjdk.org/browse/JDK-8273494
Link: https://github.com/openjdk/jdk/pull/5440
Link: 8fbcc8239a
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078446
If CMake is linked to a system-provided curl shared library, the version
at run-time may not match the `LIBCURL_VERSION` at build time. Look up
the run-time curl version to populate the User-Agent string.
This is particularly important since commit d3cbee99e3 (macOS: Prefer
building with system-provided curl, 2024-05-09, v3.30.0-rc1~130^2~1)
switched to building our official binaries on macOS against the system
provided curl shared library.
Fixes: #26209
Setting `CMAKE_INSTALL_NAME_DIR` or the `INSTALL_NAME_DIR` on Swift
targets had no effect when CMP0157 was set to `NEW`. This was a result
of missing the `<TARGET_INSTALLNAME_DIR>` before the `<TARGET_SONAME>`.
Fix that and add a test to verify that the install name directory is
included in the install name.
Fixes: #26175
In commit 40fa2c1c90 (Tests: Cleanup CMake_TEST_XCODE_VERSION code,
2024-04-29, v3.30.0-rc1~183^2) we accidentally stopped capturing the
stderr from `xcodebuild`, causing it to appear in cmake's output.
The error is incidental and tolerated, so do not let the user see it.
