[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    KOffice libraries & linking.
From:       Thomas Zander <zander () kde ! org>
Date:       2008-08-29 12:41:57
Message-ID: 200808291441.59883.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/mixed)]


Hi,

the kdelibs peeps have done some research and notes that startup of 
applications is slown 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.

So, the result is a new cmake rule to allow us to explicitly export 
dependencies for libraries.
For example; Flake now exports that it depends on pigment.  Which means that 
anyone that links to flake implicitly pulls in pigment.
Pigment depends on komain, which means that anyone that depends on flake 
implicitly pulls in komain as well. (etc).

The big change is that flake actually also depends on Kde4-kde4support, but it 
doesn't export this dependency so anyone else will not automatically link to 
that as well.

To make this all a bit clearer; here is the graph of libraries in koffice-libs 
and the libraries they provide by linking to them.
So if you link to kopageapp, your application implicitly pulls in guiutils and 
all the libs above it and linked to. No need to put those in the link line, 
cmake will do that for us.

Hope that makes things clear!
-- 
Thomas Zander

["koffice-dependencies.svg" (image/svg+xml)]
["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]