[CMake] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?

[Rolf Eike Beer]

Am Dienstag, 29. März 2011, 09:41:36 schrieb Brad King:
> On 03/29/2011 05:19 AM, Rolf Eike Beer wrote:
> > The basic idea is: any symbols from those private libraries are, well,
> > private. The user only ever sees the symbols from the public library. In
> > fact he _can't_ even link to the private libraries on Windows as we
> > never
> > install the .lib files. And that's no problem at all as we already link
> > to everything we need. I'm using --as-needed and --no-undefined on Un*x
> > and see no problem there either.
> > 
> > So the point is I want CMake to stop telling the user that he needs to
> > those private libraries as that's simply not true.
> 
> As Michael pointed out it is needed to set this property:
> 
>  
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:IMPORTED_LINK_
> DEPENDENT_LIBRARIES
> 
> CMake running in an outside application needs to know these private runtime
> dependencies.  It needs them ensure that the application link line is
> generated such that the linker can find the transitive dependencies (e.g.
> -rpath-link) of the public library.

No, why should it? Take the attached example. Build it. Do ldd on testthing.  
It links against Qt. Run testthing. It prints your path. Delete libqthing. 
Move libcthing to libqtthing. Run testthing. It prints your path just like 
before. ldd testthing. It still links against Qt.

Now when I set LINK_INTERFACE_LIBRARIES on qthing to empty it will prevent 
testthing to be linked against Qt itself so after replacing libqthing with 
libcthing everything works fine but without the (now useless) dependency on Qt. 
So why would I import that dependency to an outside project then?

I think this transitive linking for _shared_ libraries should actually be 
considered harmful. We provide an API and that's all a user should care about. 
We may change our internal libraries in any release at will and the user 
should care. In fact we have done this more than one and the binaries linked 
against older runtime versions just happily work with newer releases. If that 
transitive stuff would have been used none of them would work anymore because 
we have moved, renamed, deleted, replaced and done other things to our 
internal libraries.

I guess you had a reason for this transitive stuff, but I don't understand it. 
To prevent the silly user from accidentially underlinking his executables and 
libs? I know where this is needed for in static libs, but for shared ones?

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmlink.tar
Type: application/x-tar
Size: 10240 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110329/2e097bdb/attachment-0001.tar>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110329/2e097bdb/attachment-0001.pgp>