[Kde-pim] Intra-module dependencies in kdepim

Tom Albers toma at kde.org
Mon Oct 5 18:22:04 BST 2009


Op Monday 05 October 2009 16:51 schreef u:
> Possible solutions: experimental library as part of kdepimlibs like it has 
> been done for KNotificationItem or copies in every module that uses it. Since 
> we only have four at most (apps, runtime, extragrear, playground), temporary 
> copies and more aggressively pushing to kdepimlibs seem the least ugly 
> solution to me.

I would go for the solution of putting it in pg. As soon as two apps use it, and the release cycle is < feature freeze, move it to kdepimlibs and polish there.

> libkdepim: A total nightmare as nearly everything uses it.
> - do not allow to put new stuff in there

 +1000

> The goal would be to have less and less components depending on libkdepim 
> which gives us more freedom when moving stuff around and avoids the libkdepim 
> copy in the runtime tarball.

Sounds like a good plan. I would like to even go a more aggresive approach in trying to remove it completely asap (after apps are ported to akonadi).

> akonadiconsole: ended up in runtime, due to the dependency mess. Should IMHO 
> be moved back to apps.
+1

> examples: there are a bunch of examples in akonadi/clients, more are part of 
> the upcoming merges from the akonadi-ports branch. They should be independent 
> of internal/non-installed libs and eventually moved to the kde-wide example 
> module IMHO. Even if that will not be created (I haven't seen the result of 
> that discussion yet), our examples should probably not be in the runtime 
> module, kdepim/examples maybe? or somewhere in playground/pim?

I've created http://websvn.kde.org/trunk/KDE/kdeexamples/ earlier, just nothing in there yet.

> Now on to the new stuff: I'm about to merge the current state of 
> libmessageviewer from the akonadi-ports branch. That's the Akonadi/KMime port 
> of the message viewer of KMail, extracted and made a stand-alone library 
> (depending, among other things, on libkdepim, libkleo and libkgpg, ie. three 
> libs in kdepim/apps, not movable to kdepimlibs currently). Besides KMail (and 
> hopefully KNode) this will also be used by the Nepomuk email feeder agent, to 
> do message decryption. With the feeder agent currently in kdepim/runtime, you 
> can see what made me think about the dependency mess in the first place ;-)

Move the 3 gpl libs to kdepimlibs is the solution, right?

> Despite obviously belonging into kdepim/runtime the only possible solution I 
> can see currently is to move the feeder agent to kdepim/apps. It shares a 
> small amount of code with the agents for contacts and calendar, this would 
> need to be copied for now. Some of this is at least supposed to end up in 
> libraries eventually.

That would remove nepomuk feeder usage for pg/eg users. I don't think I care much at this moment in time though.

> To at some point move it back to runtime we would need to get rid of its 
> libkdepim dependency, get rid of the deprecated libkpgp and make libkleo and 
> libmessageviewer API-stable and move them to kdepimlibs, so this is only a 
> very long term option.

If you put it in there it will get even harder to move it out imho.

Best,

Toma
-- 
KDE Developer
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list