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
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
When GLEW is found by `find_package` (most of) the variables described
in the documentation of `FindGLEW` aren't set. That could lead to
issues when building packages that rely on these variables.
Fixes: #19662
8c9106538f FindwxWidgets: Support more wxWidgets versions, including 3.2
d8a2edb74e FindwxWidgets: Use version number from header for library names
2f2fe1a2e3 FindwxWidgets: Move extracting version number to a macro
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7374
The BLA_PREFER_PKGCONFIG switch is not that useful if you are not able
to specify the pkg-config package to use. This adds BLA_PKGCONFIG_BLAS
and BLA_PKGCONFIG_LAPACK to that effect, allowing user choice in
environments that install differing variants of the BLAS libraries
with distinct .pc file names.
This is part of work to get more standardized installations of the
BLAS libs with specific names, likely blas.pc and lapack.pc only
for Netlib reference code, or maybe blas-netlib.pc and lapack-netlib.pc,
in any case distinct from choices like openblas-openmp.pc.
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.
CUDA_TOOLKIT_TARGET_DIR doesn't always exist in the cache or defined by the user
previous to using FindCUDA. In this case it will always reset the variables
making it impossible to manually change or set them. This can be fixed by
checking to see if the variable is defined before checking against the
previously used version stored in CUDA_TOOLKIT_TARGET_DIR_INTERNAL.
Add an initial Platform module for SerenityOS [1]. This module is a mix
of the platform module currently used to build the Serenity Kernel and
Userspace applications and libraries, and the platform module included
in the CMake Port [2] which still has some work to do on the system
before its other patches could be considered for upstream.
As such, the platform module is currently only useful when used with a
suitably patched GCC or LLVM cross-compiler toolchain.
[1] https://github.com/SerenityOS/serenity
[2] https://github.com/SerenityOS/serenity/tree/master/Ports/cmake/patches
Issue: #23589
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
Brad King