[CMake] intercomponent link dependencies?

Michael Wild themiwi at gmail.com
Wed Jan 13 07:27:37 EST 2010


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



More information about the CMake mailing list