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

List:       koffice-devel
Subject:    Re: lib reorg; finishing touches.
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2009-08-25 14:30:33
Message-ID: 200908251630.34083.boud () valdyas ! org
[Download RAW message or body]

On Tuesday 25 August 2009, Thomas Zander wrote:
> I did some work today and yesterday on lib reorg.
> As you all know, boudewijn did the excellent work of splitting the libs
>  into different sub-libs.
> The intent was to join them afterwards again after getting a much better
> insight into what we actually *use*.
> 
> To find this out we can simply look at the cmake files and see what libs
>  any application actually links to. Well, theoretically.
> First there was the problem that there was a lot of duplication. Many apps
> explicitly linked to QtCore. Which is quite unneeded since linking to
> practically any app already pulls in QtCore[1] and the same goes for a lot
>  of other parts.
> So I did a big cleanup which I'll commit in 48 hours. See attached.

Cool!

> To make clear what these numbers mean, look at the attached svgz; I've
>  taken the liberty to avoid mapping the 10 widgets libs but instead push
>  them under 'komain'.

Actually, only the libs/widgets/zoom links to komain, and I would like to keep 
it that way, i.e., make komain use the widgets it needs, but have as few 
widgets use komain as possible.

For widgets, pending a way to make pigment use less memory, I propose to make 
three libs for now: 

* widgets that need pigment
* widgets that don't need pigment
* widgets that need komain (or maybe move those to komain)

Alternatively, we could for now make one widgets lib excluding the bits that 
depend on komain, and have the pigment-dependent things excluded from the 
build.

I really hope to find some time this week/next week to look into this; would 
that be too late?

> The question is; what do we do next?
> We need to merge some of these libs, for sure.  We intended to make things
> faster and due to having many more libs that any app loads on startup we
>  have accomplished the opposite. Now all we need to do is determine the
>  libs we want to end up with.

Do we actually know what the performance impact of the current number of 
libraries is on startup 

> But before we decide to merge and what to merge it might be an option to
>  move classes around.  If a plugin depends only on flake *and* KoGlobal,
>  does that mean its worth it to move KoGlobal into flake?  I don't think
>  so, but questions like this are valuable to ask.

KoGlobal is ugly :-). In this case, the dpi stuff might be necesary for flake, 
but flake shouldn't do stuff with the global kofficerc -- as far as I'm 
concerned.

But yes, a more detailed dependency graph of koffice libs and apps would be 
very useful. I did a lot of cleanup, but that was only through manual grepping 
through the sources. Vandenoever gave me a tool to automate this, but I 
haven't had time to actually apply it -- been too busy removing Qt3 from our 
code :-).

> Hoping for feedback :)

I'll recompile asap & check the patch itself.

> 1) this is solved in CMake quite nicely; the details of the concept are
> described here; http://wiki.koffice.org/index.php?title=Libs/LibsProvides
> 


-- 
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
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]