[CMake] intercomponent link dependencies?

[Michael Wild]

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