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.
In c2044fdf3f (FetchContent: Respect the CMP0135 policy setting,
2022-06-02), the URL keyword was wrongly assumed to only have
a single value. Multiple URL values are allowed if they are all
non-local. Rework the logic to remove that incorrect assumption
and handle both single and multi-value URL combinations.
Fixes: #23792
Since commit 2c9e623e31 (Find{BLAS,LAPACK}: Add support for the NVHPC
LAPACK library, 2021-05-05, v3.21.0-rc1~192^2) we try the `-fortranlibs`
option as a dependency of the NVHPC LAPACK. That flag is specific to
the NVHPC/PGI compilers, so use it conditionally with them.
Without this modification, CMake fails to find LAPACK if
- compiler ID is GNU
- `BLA_STATIC` is `ON`
- `BLA_VENDOR` is not defined or set to `All`
Fixes: #23705, #22878
Only reset it when `WX_ROOT_DIR` had a value. This change allows to set
both `wxWidgets_LIB_DIR` and `wxWidgets_ROOT_DIR` at the same time when
they where previously `-NOTFOUND`.
Since commit 6fac8af9ca (FindwxWidgets: set wxWidgets_FIND_STYLE to unix
on MINGW, 2022-04-11, v3.24.0-rc1~296^2), we only tried unix find style
on MinGW. However, only some MinGW builds have the `wx-config` needed
for unix find style. Other builds, including those using the official
wxWidgets makefiles, do not provide `wx-config` and need to use win32
find style. To accommodate both use cases, first use win32 find style
and if it fails, use unix find style.
