Reducing library dependancies

[Alexander Neundorf]

On Monday 04 August 2008, John Tapsell wrote:
> > Getting our dependencies straightened out and using symbolic-functions
> > will help a lot more with startup time than -Wl,-as-needed (which is
> > mostly a noop now with the link reduction in /trunk).
>
> Could someone explain in more detail what this "link reduction" thing
> is?  This is a cmake feature right?  What does it do and how does it
> do it? :)

Let's say we have the following:

add_library(A a.c)

add_library(B b.c)
target_link_libraries(B A)

add_program(foo main.c)
target_link_libraries(foo B)

------------------------------------

What happens is that cmake now automatically links foo also against library A. 
The reason for this is that this behaviour is required for static libraries, 
for shared libs it isn't, but doesn't really hurt a lot.

While it doesn't hurt a lot, it hurts a bit, 
- more work has to be done on application startup, so this gets slower
- more dependencies -> bad for packagers

This is how our linking works with 4.0.x and 4.1.0. When building 
something !kdelibs, the installed KDELibsDependencies.cmake is loaded by 
FindKDE4Internal.cmake, which brings in all these dependencies.
We changed this now in trunk, using the (new) target property 
LINK_INTERFACE_LIBRARIES. This property specifies which libs will be linked 
additionally. by default this is empty now, i.e. all those extra libs are not 
linked anymore. This reduces the dependencies and should bring a minor 
speedup to application startup.
E.g. in kdelibs/kdecore/CMakeLists.txt this property is, so you can see how it 
is done.

Alex