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.
Update the example to use a more recent wxWidgets version.
Use a list with known version numbers when searching for installation directories and wx-config names.
cd324110d2 CUDA: NVCC support for COMPILE_WARNING_AS_ERROR target property
2e9ac1d272 Tests: Refactor warn on error tests to support multiple languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7417
Revert commit e4e309f165 (FindHDF5: Add explicit library location
instead of guessed library name., 2022-03-22, v3.24.0-rc1~375^2).
The old behavior was not a guessed library name, but the name of an
imported target that can contain per-config locations and encode usage
requirements. Although find modules do not normally return their
imported target names in the `_LIBRARIES` variable, FindHDF5 has done so
since commit 5201a3065b (FindHDF5: use the target rather than the path,
2017-01-04, v3.8.0-rc1~81^2).
Fixes: #23667
Since LCC 1.26.03, compiler developers decided to rename
liblfortran to libgfortran (internal reference: mcstbug#131633),
and despite it's stated that "-llfortran will be automatically
treated as -lgfortran", it actually does not work (and there's
even no symlinks like liblfortran.* -> libgfortran.*); so we
have to explicitly choose which library we have to link in.
Fixes: #23646
Revert commit 020976d637 (FindPkgConfig: Populate
_STATIC_LINK_LIBRARIES. Add STATIC_TARGET., 2021-12-31,
v3.24.0-rc1~105^2). Several regressions have been reported.
Revert the feature pending further discussion and design work.
Issue: #21714Fixes: #23642
7c79fde5fb Xcode: automatically create Info.plist for signing during compiler id
116cc5a57b cm_cxx_features: filter out warnings from Xcode 14
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7391
The change to `_ep_add_mkdir_command` in commit 5fbac2bb24
(ExternalProject: Move inline scripts to separate files, 2022-01-22,
v3.23.0-rc1~101^2) did not account for the possibility that
`CMAKE_CFG_INTDIR` is `$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)`
instead of just the configuration name. Pass the value into the helper
script on the command line so that the native buildsystem placeholders
are evaluated.
Fixes: #23645
The change to `_ep_add_mkdir_command` in commit 5fbac2bb24
(ExternalProject: Move inline scripts to separate files, 2022-01-22,
v3.23.0-rc1~101^2) did not account for the possibility that
`CMAKE_CFG_INTDIR` is `$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)`
instead of just the configuration name. Pass the value into the helper
script on the command line so that the native buildsystem placeholders
are evaluated.
Fixes: #23645
Xcode 14 no longer accepts an empty signing identity for macOS.
However, Xcode in general does not accept an ad-hoc signing
identity for iOS. Switch based on the target platform.
Fixes: #23609
Forward `CMAKE_<LANG>_FLAGS` and `CMAKE_<LANG>_FLAGS_DEBUG` from the
calling project into the test project. The set of flags may affect the
availability of IPO support. Since this may change the result of the
check for existing projects, add a policy for compatibility.
This was discovered after commit 5fcadc481e (MSVC: Default to -ZI
instead of /Zi for x86 and x64, 2022-05-24) introduced policy CMP0138 to
switch our default for MSVC's debug info flag. The `-ZI` flag is
incompatible with the `-GL` flag used for IPO, so CMP0138 was reverted
pending future work on an alternative solution. Re-use the CMP0138
policy number for this change to CheckIPOSupported instead.
Fixes: #23607
Revert commit 5fcadc481e (MSVC: Default to -ZI instead of /Zi for x86
and x64, 2022-05-24). The `-ZI` flag is incompatible with the `-GL`
flag used for IPO, and so is not an unconditionally better default.
Revert the change pending future design of a first-class setting for
MSVC debug info format that can be automatically reconciled with IPO
settings.
That commit introduced policy CMP0138, but we already have later policy
numbers used too. Leave placeholder text to avoid policy renumbering.
Issue: #23607, #10189
The guide previously only focused on the find_package() command,
with a bias towards libraries. FetchContent was not mentioned at all.
Reorganise and update the existing content. Add new sections to cover
providing dependencies with FetchContent and dependency providers.
Improve discoverability of the guide by mentioning it at the beginning
of the find_package(), FetchContent and dependency provider docs.
The ExternalProject module has long used the generator-specific
placeholder in the `${CMAKE_CFG_INTDIR}` variable to express per-config
stamp file paths in multi-config generators. Now that most generators
support generator expressions in custom command outputs, we can use
the `$<CONFIG>` genex instead.
In particular, this fixes cross-config `BUILD_BYPRODUCTS` with the Ninja
Multi-Config generator.
Fixes: #23595
It's been a long-standing bug in CMakePrintHelpers that the
cmake_print_properties() function cannot print the SOURCES
property of a requested TARGET, confusing it with a request
to print properties of SOURCES.
We work around this by parsing the arguments in two stages,
so that a SOURCES that comes after the PROPERTIES keyword
is handled differently from a SOURCES that comes before it.
This adds the restriction that the "mode" keyword (TARGETS
SOURCES DIRECTORIES etc...) and its arguments **must** precede
the PROPERTIES keyword and its arguments. In other words:
1. Both of these are now valid and will be interpreted correctly,
whereas previously only the first was, and the second caused
a FATAL_ERROR:
cmake_print_properties(SOURCES foo.c PROPERTIES LANGUAGE)
cmake_print_properties(TARGETS foo PROPERTIES SOURCES)
2. This, OTOH, which used to be valid, no longer is, and will
trigger a FATAL_ERROR:
cmake_print_properties(PROPERTIES LANGUAGE SOURCES foo.c)
Fixes: #14883
