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
Curl 7.85.0 introduced support for TLS 1.3 support with schannel.
We've observed connection failures in some cases, so disable the
support pending further investigation.
Fixes: #24147
Refactoring in commit 89a1e1c1be (Build: Link w/ `OBJECT` library is OK
since 3.12, 2022-08-21, v3.25.0-rc1~97^2~19) dropped the `.res` object
containing this information from the `cmake-gui` link line. Restore it.
96ddcbee60 cmState: Clarify name of member tracking the active scope in a directory
cb53d9309e block: Fix variable scope protection from modification by subdirectories
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7885
The `DirectoryEnd` member added by commit 52dbe654de (cmState: Record
the end position of each directory., 2015-08-01, v3.4.0-rc1~251^2~1)
actually tracks the current top-most scope in a directory's stack. This
is evidenced by the use case in commit 3f4e5e8c3d (cmState: Return end
snapshot for GetBuildsystemDirectoryParent., 2015-09-01,
v3.4.0-rc1~100^2~1). Rename the member to `CurrentScope` to clarify
this role.
When `cmStateSnapshot::RaiseScope` raises a variable in to a parent
directory scope, it uses `GetBuildsystemDirectoryParent` to find the
current top-most scope on the directory's stack. Since commit 3f4e5e8c3d
(cmState: Return end snapshot for GetBuildsystemDirectoryParent.,
2015-09-01, v3.4.0-rc1~100^2~1), that depends on the `DirectoryEnd`
field in the directory's state. However, when variable-only scopes were
added by commit 6954c8936f (cmState: Add a VariableScope snapshot type.,
2015-08-01, v3.4.0-rc1~179^2~1), we neglected to account for the
addition of that field by commit 52dbe654de (cmState: Record the end
position of each directory., 2015-08-01, v3.4.0-rc1~251^2~1).
Prior to commit 44a2f3f332 (Add new flow-control commands for variables
and policies scopes management, 2022-08-05, v3.25.0-rc1~257^2) this
problem went unnoticed because there was no way to have a variable scope
at the top of a directory's stack while processing a subdirectory. Now
the `block()/endblock()` commands enable the behavior, so fix tracking
of a variable scope as the top-most scope in a directory.
Fixes: #24138
