On 13. Jan, 2010, at 11:51 , Nico Schlömer wrote:
>> 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.
Overlinking is actually only an issue for dynamic libraries. So as long as
you're absolutely sure that you only have static libraries, you're fine.
>
>> 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.
Fair enough, if A really requires a specific version and that information is
readily available.
Does the IMPORTED_LINK_INTERFACE_LIBRARIES thing work? I just noticed that
there is also IMPORTED_LINK_DEPENDENT_LIBRARIES to list libraries that are an
implementation detail of a shared library and might to be specified explicitly
on the link line (such as OS X). Not sure how the behavior for static libraries
is, though.
Michael
_______________________________________________
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
