Moving kdeeduplot to kdelibs
neundorf at kde.org
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
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:
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
CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR) both can work.
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org - http://www.kde.org
alex AT neundorf.net - http://www.neundorf.net
More information about the kde-core-devel