Closed bast closed 9 years ago
Yes, I fully agree. Let us split math_libs.cmake into into separate modules, each for one library.
On top of it, the whole code of _mathlibs.cmake is difficult to read and modify approriately. I strongly suggest not only split it, but also provide in-depth documentation. My static linking flags are difficult to glue into _mathlibs.cmake in a sophisticated way, what includes these macros inside.
Yes. I agree. This module is incredibly complicated and unmaintainable. Probably it will help to split it. In any outcome we need to document it.
Also, the cmake installation contains FindBLAS and FindLAPACK. Are these modules somehow incorporated in math_libs.cmake ?
They are not but I think we should use them. Few years ago when we wrote the math detection code FindBLAS/LAPACK were not good enough but this probably changed. I am more and more convinced that we should split the module into separate modules. Explicit is better than implicit.
We will go for the split. I am closing this discussion issue to have better overview over remaining issues.
The module
math_libs.cmake
is monolithic and relatively convenient but rather complex, difficult to extend and understand, in particular for non-experts in CMake. I would like to discuss here the possibility to split it into separate modules (one for system native BLAS/LAPACK, one for Atlas, one for MKL, one for ESSL, one for OpenBLAS, etc.). This could simplify the CMake code and make the modules behave more predictably. Currently the behavior can be a bit opaque.