Closed kcgthb closed 2 years ago
The reason, why this was never detected, was that we only test on:
If you have an idea in mind, please provide a PR (only for one Find...
file by now) and we discuss a proper solution. Once we have it, we port it to the other Find...
scripts. One must have is, that is does not break the detection on Fedora/Ubuntu/Debian. If we make it until end of this week, it will be included in the next release.
Thanks @grisuthedragon !
PR proposed in #28 for FindOpenBLASSerial.cmake
This looks promising. I will integrate the patch for all find routines.
Excellent, thank you!
Closed in 3.2.0
Hi!
I just spent a few hours trying to understand why my Open BLAS and BLIS installations were not detected by
cmake
, until I realized that CMake'sfind_library
was explicitly called withNO_CMAKE_PATH NO_CMAKE_ENVIRONMENT_PATH
in all theFind<blas_installation>.cmake
files. Like in https://github.com/mpimd-csc/flexiblas/blob/bb816067e9900cff14a73489aac1455108ff1d96/cmake/FindBlisSerial.cmake#L14Is that intentional? What's the rationale behind this?
In a lot of HPC environments, BLAS libs are made available to users through environment modules that set environment variables, and could expose installation paths in things like
CMAKE_{PREFIX,INCLUDE,LIBRARY}_PATH
.By artificially limiting the scope of
FIND_LIBRARY
detection, and limiting it to OS-specific directories , CMake will be able to detect BLAS libraries that have been installed via OS package managers (as RPM or DEBs). But that's rarely the case on large-scale computing systems, where software installations often reside on shared, networked file systems.Would it be possible to remove that limitation, and let CMake try to autodetect BLAS installations in other directories as well, as specified in
CMAKE_*_PATH
env variables, without having to manually specify a long list of-DEXTRA
entries?Happy to provide a PR if needed. Thanks!