Fix a regression from commit 073dd1bd81 (GoogleTest: Change format for
typed tests, 2022-02-07, v3.23.0-rc1~4^2) in the suite name detection.
Co-authored-by: Evgeniy Shcherbina <ixsci@pm.me>
Fixes: #24563
Intel oneAPI 2023.0 added the `icpx` compiler front-end on Windows.
It uses a GNU-like command-line, and is not yet supported by CMake.
Avoid finding `icpx` as the CXX compiler on Windows until support
is added.
Fixes: #24266
Issue: #24314
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
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
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.
When FetchContent_MakeAvailable() populates a dependency for which
find_package() integration is enabled, all future calls to find_package()
MUST succeed using the contents of the redirection directory. The
generated config version file was not handling calls where the EXACT
keyword was given, resulting in such calls rejecting the redirection
directory's contents and continuing its search. It is not allowed to do
that. Fix the generated file to also set PACKAGE_VERSION_EXACT to
true so that calls with EXACT now accept it, as was originally intended.
Fixes: #23950
The unset() command was using __cmake_contentNameLower before that
variable was restored from the __cmake_fcCurrentVarsStack. That means
if there had been a nested call to FetchContent_MakeAvailable(), the wrong
variable name would have been cleared (the nested name instead of the
one from the current call). That would have left the variable set upon return,
blocking the dependency provider from seeing any further calls to
FetchContent_MakeAvailable() in the current variable scope or below for the
current dependency.
The following `module.f90` file
module mymodule
contains
subroutine mysub()
end subroutine
end module
when compiled with `flang-new` (from LLVM 15.0.0) generate the
`_QMmymodulePmysub` symbol.
$ flang-new -c module.f90
$ nm module.o
0000000000000000 T _QMmymodulePmysub
This commit fixes the regular expressions accordingly.
CMAKE_FIND_LIBRARY_PREFIXES and CMAKE_FIND_LIBRARY_SUFFIXES have
different behavior when undefined and when defined but empty:
Empty means to use an empty prefix/suffix while undefined means to
use a hardcoded default for the platform we are running on.
Unfortunately, set(a ${b}) will undefine a when b is empty,
meaning that when targeting a platform where either of these variables
is empty (e.g. Windows where CMAKE_FIND_LIBRARY_PREFIXES is empty)
the unpatched FindZLIB code ends up unsetting that variable, causing
all subsequent find_library calls to use the hardcoded default
for the runtime platform (e.g. "lib" for CMAKE_FIND_LIBRARY_PREFIXES
on Linux).
On the other hand, set(a "${b}") will always define a to be empty but
defined so we have to do this dance to fully preserve the state of these
variables.
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_80_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.80.0 source tree.
They are the same as 1.79's dependencies, so just update
the version check for warning about newer versions.
`find_package(Vulkan REQUIRED FATAL_ERROR)` calls exist in the wild, but
`find_package` does not have a `FATAL_ERROR` option. We silently
tolerated such calls prior to commit 6e4d20921d (FindVulkan: Add
component for `shaderc_combined`, 2022-05-18, v3.24.0-rc1~111^2~5), by
treating the argument as a component and ignoring it. Restore tolerance
by removing the component and warning about it.
Fixes: #23849
Since commit 55ba10dcfd (MSYS/MinGW Makefiles: Simplify selection of
windres as Resource Compiler, 2022-05-26, v3.24.0-rc1~82^2) the `MinGW
Makefiles` and `MSYS Makefiles` generators no longer specify the plain
`windres` name for the MinGW resource compiler. Instead, the name is
specified in our MinGW platform information module. After the change in
commit af4adf6aa9 (MinGW: Fix default windres selection when
cross-compiling, 2020-03-25, v3.18.0-rc1~492^2), when cross-compiling,
we only specify the toolchain-prefixed name of the tool, which may not
be available in all environments.
If the toolchain-prefixed name is not available, fall back to the plain
`windres` name. We already use this approach for other binutils.
Fixes: #23841
1cd65dfa0e TI compiler: Add support for COMPILE_WARNING_AS_ERROR target property
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Josef Angstenberger <code@jtxa.de>
Merge-request: !7560
Revise the change from commit fe57410b33 (IPO: Use -flto=auto if
compiler is GCC >= 10.1, 2022-06-22, v3.24.0-rc2~2^2) to require
at least GCC 11 on Windows.
Fixes: #23836
Issue: #23640
Since commit 3257c34073 (FindThreads: avoid failing in AIX when using
-D_XOPEN_SOURCE=500, 2022-04-30, v3.24.0-rc1~197^2) we no longer check
for `pthreads.h` before checking for the `-pthread` flag. Compilers
targeting the MSVC ABI do not have such a flag, so avoid performing the
check unnecessarily.
Fixes: #23829
The CMAKE_VERIFY_INTERFACE_HEADER_SETS variable is intended to
be under the control of the user. It doesn't discriminate between
header sets defined in the main project and those defined by
dependencies brought into the build directly via FetchContent.
Developers will usually only be interested in verifying the main project's
header sets, not those from dependencies.
Make the variable effectively only enable header set verification of the
main project by turning it off during FetchContent_MakeAvailable() calls.
The user still has variables like CMAKE_PROJECT_INCLUDE and
CMAKE_PROJECT_<projectName>_INCLUDE available to them if they
want to enable verification of all or specific dependencies respectively.
Fixes: #23808
Since commit cb811d11ce (Help: Improve description of modules,
2019-04-12, v3.15.0-rc1~210^2) we've had two `::` prompts for
the preformatted block listing the result variables. Convert the
block to a definition list.
When we introduced the `GTest::gmock` and `GTest::gmock_main` targets in
commit 50bf457a0d (FindGTest: Add target for gmock library, 2021-10-17,
v3.23.0-rc1~321^2) we failed to handle the case where GTest isn't found.
Don't construct gmock targets that depend on non-existent gtest targets
when gtest failed to be found.
