Moving kdeeduplot to kdelibs

Alexander Neundorf neundorf at
Wed Jan 10 18:12:19 GMT 2007

On Wednesday 10 January 2007 15:24, Thomas Zander wrote:
> On Wednesday 10 January 2007 11:10, Boudewijn Rempt wrote:
> > Instead of having extra libraries that depend on multiple modules (like
> > koffice and kdeedu),
> This is not about libraries. This is about a component that happens to ship
> like a library. Much like krita is an application that happens to ship like
> a library.
> > we'd do better to extract the libraries from koffice
> > (like pigment) that would be useful to apps outside koffice and the
> > libraries from kdeedu that would be useful to apps outside edu -- and so
> > on, digikam hsa a couple of useful libraries as well -- and make those
> > libraries, like kdepimlibs, only depend on kdelibs, not on their
> > ancestral modules.
> This, to me, is an entirely different subject.  Many parts in the KOfice
> libraries (flake as a great example) have a broader usage than just
> KOffice. Pigment and some other KOffice libs join that rank.
> When some dust has settled in KOffice and we did a lot of cleanup in the
> libs I think we should make a kofficelibs module.

IMO that's a good idea :-)
We will then have kdepim + kdepimlibs, kdegraphics+kdegraphicslibs, 
koffice+kofficelibs. See some scheme ? How about taking this one step 
further ?

We could either say we introduce for every module we have an accompanying libs 
module OR we structure our modules (actually with svn we don't have modules 
anymore) all following the same scheme:

        |    +--lib1/ 
        |    +--lib2/

Of course the libs/ dir must be compilable on its own. Should the whole module 
still be compilable at once or have libs/ and apps/ to be compiled 
separately ? If we follow some rules (I think mainly not using 

Work: alexander.neundorf AT -
Home: neundorf AT                -
      alex AT               -

More information about the kde-core-devel mailing list