Add a 3.30.3 release note for commit c1ece78d11 (project: non cache
<project> prefix variables are also created, 2024-08-27, v3.30.3~2^2).
Prepare a 3.30.4 release note for commit 86ad7cc886 (project: Only
define non-cache vars if already defined, 2024-09-15).
86ad7cc886 project: Only define non-cache vars if already defined
4c152752da Help: State valid scopes for using proj_SOURCE_DIR and proj_BINARY_DIR
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9820
In c1ece78d11 (project: non cache <project> prefix variables are
also created, 2024-08-27), we started explicitly setting the non-cache
variable for <projectName>_SOURCE_DIR, <projectName>_BINARY_DIR,
and <projectName>_IS_TOP_LEVEL in addition to setting them as
cache variables. This changed the behavior when a project name
was used more than once, and the second project call happens in
the same scope or a child scope of the first. Previously, the first
project call would set cache variables, and the second project call
would not overwrite those cache variables. With the change in
c1ece78d11, after the second project call the non-cache variables
would mask the cache variables and the project code would see
a different value to what it did before.
Setting the non-cache variable was added to handle the case where
a call to FetchContent_MakeAvailable() would set some non-cache
variables, and it just so happened those matched the same cache
variables that the project() command would set in the project being
fetched. The fetched project would then see a different set of
project-specific variables compared to when it was built standalone.
This commit here narrows the change from c1ece78d11 such that
the non-cache variable is only set by project() if there was already
a non-cache variable set. This still fixes the motivating problem
c1ece78d11 was intended to solve, but it avoids changing the variable
values seen by a project that re-uses the same project name in related scopes.
Issue: #26243, #25714Fixes: #26281
9ceca05e6b FindMatlab: Search mex and mx libraries for MCR
67e3c6b6eb FindMatlab: Cache whether MATLAB root contains MCR or MATLAB
b426ce1d04 FindMatlab: Add support for MCR distributions without mex.h
cd4782bac3 FindMatlab: Only consider versioned MCR subdirectory if it exists
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9831
cc293b4963 ci: Run RunCMake.ExternalProject serially in macos-x86_64 Xcode job
26359076c8 gitlab-ci: update macOS jobs to use Xcode 16.0
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9830
Add the `native0.0` framework to the list of allowed frameworks allowing
native (C/C++) NuGet packages. This extends commit 0f4d3664a9
(CPack/NuGet: Build dependencies in groups, 2024-06-01, v3.30.0-rc1~18^2).
Fixes: #26305
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
Brad King