When using libpkg, the output filename is determined by libpkg
itself, based on information in the manifest: package name and
version, basically. This doesn't necessarily match the name that
CMake has determined via CPACK_TEMPORARY_PACKAGE_FILE_NAME or
CPACK_PACKAGE_FILE_NAME. So reset the CMake-determined list
to match what libpkg will do.
Previously this module only provided `GLUT_INCLUDE_DIR`, which does not
follow the modern naming convention documented in `cmake-developer(7)`.
Issue: #23018
Since commit f90d15458a (FindGLUT: Use pkg-config to find flags if
available, 2021-06-11, v3.22.0-rc1~469^2) we return early if pkg-config
provides the information. During review of that commit, code to
populate the legacy `GLUT_INCLUDE_DIR` result variable was removed from
that code path. Add code to provide it.
Also fix the test case to use `GLUT_INCLUDE_DIR`, the result variable
documented officially by the module.
Fixes: #23018
The logic added by commit 7808cbd644 (CMakeDetermineCompilerId: support
Intel DPC++ compiler toolset for VS gen, 2020-12-06, v3.20.0-rc1~330^2)
matches a specific toolset known to be the `icx.exe` compiler, and
assumes all other Intel C++ compilers (that are not DPC++) must be
`icl.exe`.
Since `icx.exe` is officially replacing `icl.exe`, use a regex that
matches the now-fixed set of toolsets known to use `icl.exe`. Any other
Intel C++ compiler will be assumed to be `icx.exe`.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_78_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.78.0 source tree.
The dependencies differ from those of 1.77:
* The `log` component no longer depends on `date_time`.
Fixes: #23016
The `find_package(OpenMP)` calls added/updated by:
* commit f7f3d8987a (FindBLAS: Add dependency of OpenBLAS on OpenMP for
BLA_STATIC, 2020-11-10, v3.20.0-rc1~492^2)
* commit 9ef82d95d8 (FindBLAS: Fix detection of OpenMP as dependency of
BLA_STATIC, 2021-04-07, v3.20.1~3^2)
were missing the `QUIET` option.
Fixes: #23000
The current regular expression is able to match `/usr/lib/<arch>`,
`/usr/usr/lib/<arch>`, `/usr/usr/usr/lib/<arch>`, ... but not
`/lib/<arch>`.
This behavior ends up causing the detected architecture to
be x86_64-pc-linux-gnu when the Clang compiler is installed on
a "non-system" location (like /opt/llvm-13) which, in turn, makes
almost every 'find_library()' fail because the correct
architecture is x86_64-linux-gnu.
This is due to a typo in commit 764606e256 (CMakeDetermineCompilerABI:
Extract lib arch from implicit object file paths, 2021-04-05,
v3.20.1~10^2), which used `+` instead of `?`.
The upstream `openssl` build system may install libraries to `lib64`
even on platforms whose conventions do not use `lib64` for
distro-packaged libraries.
Fixes: #22945
In commit 7b83ca816a (FindOpenSSL: add target OpenSSL::applink to
support OpenSSL's applink feature, 2020-05-12, v3.18.0-rc1~150^2) the
version check was written as "major.major.fix" instead of
"major.minor.fix".
Since commit 94a84dc0af (FindPkgConfig: add pkgconf to the search list.,
2021-07-02, v3.22.0-rc1~468^2), `pkgconf` is preferred over `pkg-config`
if they appear in the same directory. In some environments,
`pkg-config` may be a wrapper that adds semantics beyond either
`pkgconf` or the normal `pkg-config`. Prefer `pkg-config` over
`pkgconf` in order to preserve the prior behavior in such environments.
Fixes: #22976
Update logic added by commit ecaca8c129 (GNUInstallDirs now aware of
conda lib directory requirements, 2021-09-08, v3.22.0-rc1~142^2).
When it is ambiguous if we are doing a conda install or a system
install prefer using the system library directory.
Fixes: #22962
0fc8b2f61c CompilerId: Restore support for classic C by avoiding C++ style comments
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Raul Tambre <raul@tambre.ee>
Merge-request: !6759
C++ style comments were added by commit fc3a1cbdd8 (CompilerID: Compiler
extensions default detection, 2021-05-29, v3.22.0-rc1~52^2~2), but they
may not be supported by the default mode of some C compilers. Use
C-style comments instead. For consistency, do this for all languages.
Fixes: #22942
`googlemock` has been absorbed into the
[googletest](https://github.com/google/googletest) project and is built
and installed from the same source tree.
As GTest may be built with or without GMock, skip GMock if it is not
present.
Do not provide result variables for GMock. They are not provided by
upstream GTest's CMake Package Configuration File.
Also update the test case to cover linking to `GTest::gmock`.
