Calligra/Libs/LibsProvides

Explanation of the graph

The libraries in KOffice are build on top of each other, KoMain, for example, depends on the Flake library for some of its functionality.

The effect is that if an application were to use a class from KoMain as well as another class from Flake the application only has to link to KoMain. The reason for this is that all the libraries in the graph that KoMain points to are provided by linking to KoMain. This goes all the way down the graph so QtGui is provided as well by just linking to anything above it.

It is good practice to make a link line in your application as short as possible so as to avoid linking to too much and slowing down both the linking time but also the startup time of that application.

In the graph there are some lines that are 'dotted'. These are there to indicate the fact that the library is used internally, but its not provided to anyone else.

Background

the kdelibs peeps have done some research and notes that startup of applications is slowed down by it linking to libraries it doesn't need linking to. The reason for this is that if we stack libraries (c depends on b depends on a) all the libs that 'a' links to are also included in the link line to the application that links to library c. And that causes slowdowns.

So, the result is a new cmake rule to allow us to explicitly export dependencies for libraries. In contrary to the old method where all dependencies were implicitly exported. The difference being that if I use a certain lib internally, I can avoid exporting that dependency so others depending on me don't automatically link to that internal lib as well. For example; KoMain now exports that it depends on KoText. Which means that anyone that links to KoMain implicitly pulls in KoText. KoMain internally links to ThreadWeaver library, but that is not exported. The concept is even recursive. KoMain depends on Flake which depends on Pigment, which means that anyone that depends on KoMain implicitly pulls in Pigment as well. (etc).

Bottom line; KoMain actually also depends on ThreadWeaver, but it doesn't export this dependency so anyone else will not automatically link to that as well and its essentially hidden from the public.

Practical implications

If you add a new dependency and you've got a library that uses that dependency and you've got code that uses both the library and stuff from the dependency, say:

* LibA
* MyLib
* MyCode

add a line like

target_link_libraries(MyLib LINK_INTERFACE_LIBRARIES LibA)

to the CMakeLists.txt file of MyLib. If you do that, you won't have to add LibA to the target_link_libraries line of MyCode.