The fix in commit e9755bc7c1 (MinGW: Restore using windres when
toolchain-prefixed name is not available, 2022-08-15, v3.24.1~4^2)
incorrectly listed two entries in `CMAKE_RC_COMPILER_INIT`, which is
only meant to have one value. Revise the logic to support multiple
platform-specific names for the Windows Resource Compiler while still
only using one name as the fallback when it is not found.
Fixes: #24190
Issue: #23841
Revert commit be848a71b0 (MSVC: Teach find_library to consider the
'libfoo.a' naming convention, 2022-09-19, v3.25.0-rc1~111^2). When
targeting the MSVC ABI, this causes GNU-ABI libraries to be found in
cases they were not previously, and broke existing builds. Revert the
change pending further discussion on how to handle the motivating use
case.
Issue: #23975Fixes: #24168
Since commit 0c141b0393 (try_compile: Record output location instead of
reverse computing it, 2022-08-31, v3.25.0-rc1~154^2) we always look for
the "Debug" configuration's output binary from the test project.
Restore looking for the `CMAKE_TRY_COMPILE_CONFIGURATION`.
Fixes: #24180
Extend the change from commit 1d9f2f9714 (FindCUDA: Do not search for
the deprecated nppicom when CUDA >= 11, 2020-06-22, v3.18.0-rc3~14^2)
to also not use the `CUDA_nppicom_LIBRARY` variable.
Issue: #20845
Follow up the python 3.11 and 3.12 support from:
* commit 43844c5d82 (FindPython: Add support for Python 3.11,
2021-12-07, v3.22.2~20^2)
* commit ca2877c039 (FindPython: add support for Python 3.12,
2022-05-11, v3.23.2~15^2)
with an update for the FindBoost test.
Under the policy's NEW behavior, `[CMAKE_]MSVC_DEBUG_INFORMATION_FORMAT`
may be explicitly set to an empty string to tell CMake not to add any
flags for this abstraction. In this case, fall back to checking the
language-wide flags as we do in the OLD behavior.
This revises commit 183b9a9eca (CMP0141: Fix PCH REUSE_FROM under policy
NEW behavior, 2022-10-31, v3.25.0-rc3~4^2).
Issue: #24106
Adding missing narrow string conversion.
This backports commit f3c918ef1b (cmGlobalVisualStudioGenerator: Fix
compiling as C++20 in VS 2022, 2022-10-20, v3.25.0-rc3~31^2) to the
CMake 3.23 and 3.24 branches.
Fixes: #24162
46b2849550 ci: Update LLVM/Clang to 15.0 in nightly CI jobs on Windows
3eb94e4d51 ci: Simplify LLVM/Clang CI job specs on Windows
8ba5835c8d ci: Factor out helper to load clang into environment on Windows
bf2e4a2e85 ci: Factor out helper to load ninja into environment on Windows
93ff726114 Tests: Fix TryCompile bad source case for clang-cl 15 on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7897
Compile with the preprocessor definitions necessary for the `arc4random`
family so it's available even when compiler extensions are not enabled.
Similar things are done in cmbzip2, cmcurl, cmlibarchive, cmliblizma and
cmlibuv.
This issue surfaced on a nightly bot after glibc 2.36 added arc4random
functions. cmlibarchive defines the necessary macro, but also relies on
`HAVE_ARC4RANDOM_BUF`. cmlibarchive's check with the necessary macro
defined was skipped due to cmexpat running the same check before, but
without the macros, and it being cached.
This extends commit c7c3e39e4f (Utilities: Activate POSIX APIs even
without compiler extensions, 2022-06-02, v3.24.0-rc1~34^2) to cover our
build of expat too.
Issue: #20454
Problems with `cmake-gui` when compiled with the MSVC 14.33 toolset,
that did not occur with the MSVC 14.32 toolset, no longer occur with the
MSVC 14.34 toolset. Revert commit cb8b27a901 (gitlab-ci: Use separate
MSVC toolset specification for packaging jobs, 2022-08-18, v3.24.2~24^2~1)
and update the remaining toolset version references.
Fixes: #23859
When `pass.c bad#source.c` passes through `nmake`, the compiler gets
`pass.c bad`. The clang-cl 15 compiler now fails on `bad` with an
error that we did not previously match. Update our regex.
Since commit 386465bf83 (cmTarget: add support for C++ module fileset
types, 2022-04-08, v3.25.0-rc1~624^2~7), the Ninja generator checks for
C++20 support using logic that requires `CMAKE_<LANG>_STANDARD_DEFAULT`
to be non-empty. On some compilers, such as ARMClang, CMake does not
automatically detect and set default language standards, thus causing
`HaveStandardAvailable` to raise an internal error.
To fix this issue, if `CMAKE_CXX_STANDARD_DEFAULT` is empty, assume all
standards to be supported instead of calling `HaveStandardAvailable`.
This is consistent with how `CompileFeaturesNode::Evaluate` handles this
case.
Fixes: #24146
