Closed bast closed 8 years ago
Hi Rado,
I suggest more natural splitting of _mathlibs.cmake, according to math library providers:
SYSTEM_NATIVE; OpenBLAS, MKL, ESSL, ATLAS, ACML.
Eeach one should cover both Fortran and C blas and lapack.
Well I am not sure it is so natural in fact. They don't provide the same functionality. And some codes only need BLAS and do not need LAPACK. MKL provides both. Then there is CBLAS and LAPACKE, where does that fit in? Then on Mac there is the Accelerate framework (my plan is to also introduce --accelerate
).
OK, then go ahead with your ideas.
The aim of the reorg is "explicit is better than implicit".
Rado, one new feature would be helpful: combining several math libraries.
For example, the OpenBLAS has no dgesv (routine from LAPACK), would be good to have following SYSTEM_NATIVE or ATLAS lapack library as second (third etc) among linking flags.
This will be unproblematic in the upcoming implementation.
Good; looking forward to new math_libs CMake macros implementation.
Than I will check it with the mathlibs-tester, both with Fortran and C.
Process is ongoing. Will close this issue to keep better overview.
We are in the process of splitting
math_libs.cmake
into individual modules.Preliminary list:
The redesign will allow to switch to static linking by the caller and therefore explicit static linking will not be done in the math library modules but it will become optional "on the outside". Therefore also corresponding tests for static math library linking will be removed.