> Coming to think of it: Why don't you simply list ${A_LIBRARY},
> /usr/lib/liblapack.a and /usr/lib/blas.a (shouldn't that be libblas.a?) in
> A_LIBRARIES and the use that in TARGET_LINK_LIBRARIES? Simpler for you and
> less work for CMake...
When using ${A_LIBRARY}, ${B_LIBRARY}, ${G_LIBRARY}, and ${Z_LIBRARY}
(which may all depend on blas and lapack, I'd like to avoid
overlinking.
> PS: I can't tell for sure from what you show, but you REALLY should discover
> lapack and blas instead of hardcoding their paths, e.g. using FindBLAS and
> FindLAPACK (which admittedly have their deficiencies)
Well, there may be many different versions of BLAS/LAPACK installed
(think of different compilers, compiler versions, for example).
Against which one of those ${A_LIBRARY} is compiled is hardcoded in
one of the installation files of ${A_LIBRARY}. Those I then parse and
use that info and use that in FindA.cmake.
Cheers,
Nico
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
