Since commit f85913fa08 (VS: Add support for enumerating VS instances
with vswhere, 2022-04-11, v3.24.0-rc1~282^2), if the COM lookup does not
report any VS instances, we fall back to finding vswhere. However, the
`getenv` call returns nullptr if the `ProgramFiles(x86)` environment
variable is not set. Update the logic to tolerate not-set environment
variables. Also check the plain `ProgramFiles` environment variable.
Fixes: #24090
This was accidentally broken by commit 87c762d435 (CPack: Use
cmCommandLineArgument instead of cmsys::CommandLineArguments,
2022-04-18, v3.24.0-rc1~258^2).
Fixes: #24085
The test added in commit 50e90e2828 (try_compile: Honor CMP0128 setting
in test project, 2022-10-18, v3.25.0-rc2~4^2) requires that the compiler
support C++11 mode, so do not run it on GNU compilers that are too old.
The `remove_filename` and `replace_extension` methods compute an offset
between the whole path in a `std::string` and a part of a path in a
`std::string_view`. This is done by subtracting their `.data()`
pointers. However, C++17 adds a non-const `.data()` through which
modification of the string is allowed. This means the copy-on-write
implementation used by the pre-C++11 std::string GNU ABI must reallocate
if the string has been copied. Our subtraction then computes an offset
between two different allocations, which is undefined behavior.
The workaround in commit b3ca4f9ad1 (cm/filesystem: Work around crash
when compiled for CYGWIN/MSYS runtime, 2021-04-22, v3.21.0-rc1~271^2~2)
avoided the problem by calling the non-const `.data()` to reallocate
before constructing the `string_view`. Instead, explicitly call the
const `.data()` method on the string, which does not reallocate.
Fixes: #22090, #23328
Due to CVE-2022-39253, Git 2.30.6 sets `protocol.file.allow=user` by
default. The change has also been backported to other Git versions by
distros. This breaks some of our test cases that use the file-based
protocol locally to simulate real workflows without requiring network
access. In these cases the file protocol is safe, so explicitly enable
it in the tests.
When cross-compiling for Android, the library path suffixes `/<number>/`
refer to API level specific platform libraries instead of architecture
bitness. Disable path suffix use under NDK to avoid incorrect inclusion
of API level specific libraries below the targeted API level.
Fixes: #23830
Some projects pass a raw `-std=` flag to the compiler in the
`try_compile` project. If they do not set CMP0128 to NEW,
we should not append a `-std=` flag where we did not before
the policy was added.
Fixes: #24063
In commit 00c4f488f2 (FindJNI: support Android NDK, 2022-03-18,
v3.24.0-rc1~325^2) we used `CMAKE_ANDROID_API` to check the Android API
level. However, `CMAKE_SYSTEM_VERSION` is the authoritative value.
When cross-compiling for Android, an unset `CMAKE_ANDROID_API` can
result in failure to locate JNI because the `NativeHelper` component
cannot be found. In this case, the component is falsely assumed to be
available by default (and thus required) since the comparison against an
unset `CMAKE_ANDROID_API` variable evaluates to true. Use
`CMAKE_SYSTEM_VERSION` to determine the Android API level instead.
Issue: #23830
Parse implicit link information for this compiler to support
mixed-language linking. This was missed by commit 85749766df
(LLVMFlang: Add support for LLVM Flang, 2021-07-07, v3.24.0-rc1~86^2).
Also activate mixed-language test cases that would have caught this.
Issue: #22387
In commit b795c96727 (CPack/NSIS: Fix uninstall command when run from
installer, 2022-03-21, v3.23.0-rc5~9^2~1) we incorrectly removed the
`_?` parameter when calling the uninstaller during installation.
This parameter is however essential for ExecWait to actually wait for
the uninstaller to finish. Without it, the uninstaller is started in
the background and installer and uninstaller run at the same time.
See https://nsis.sourceforge.io/Docs/Chapter3.html#installerusageuninstaller
Add back the `_?` parameter to fix this regression. Use another
approach to solve the problem motivating the original change.
Fixes: #24041
Update the compiler options table added by commit 76a08cd253
(COMPILE_WARNING_AS_ERROR: Add options to treat warnings as errors,
2022-04-21, v3.24.0-rc1~173^2) to use the Intel Fortran compilers'
dedicated `-warn*` flags.
In commit 76a08cd253 (COMPILE_WARNING_AS_ERROR: Add options to treat
warnings as errors, 2022-04-21, v3.24.0-rc1~173^2) we formatted the
options table entries as command-line string fragments. Since they are
part of the `CMAKE_${lang}_COMPILE_OPTIONS_*` tables, they should be
formatted as `;`-separated lists of compiler options.
