KDE Platform Profiles

[Alexander Neundorf]

On Monday 12 April 2010, Kevin Ottens wrote:
> Gooooood (not-so-)morning(-anymore) kde-core-devel!
...
> Then, what becomes important is to streamline the dependencies within the
> KDE Platform so that less storage, memory and bandwidth consumption is
> generated by pulling a KDE application. That also means that we need to
> clearly communicate about the packages that should be split from kdelibs
> and friends. Instead of a single kdelibs binary package, we need one per
> kdelibs submodule (kdecore, kdeui, solid...).

Ok, this part means some work for the buildsystem.

Right now, in any KDE4 application, you do a find_package(KDE4) and if that 
succeeds you can be sure that everything is there.
The only optional library right now is nepomuk (or isn't it optional ???) and 
kdefakes, kdesu and kpty exist only under UNIX.

If kdelibs can be installed in a modular way, this changes somewhat. Maybe 
everything is there except khtml and you are fine with this. Or you are not.
We need to be able to handle this.
The question is, how.

Here is my (rough) idea:

The find_package() cmake command supports specifying components of the package 
in question, for KDE this could look like:

find_package(KDE4 4.5.0 COMPONENTS kdecore kio kdeui)

This would mean you need kdecore, kio and kdeui and don't care about the other 
components. This call should then succeed if these three parts are available 
and not care about the rest.
To keep compatiblity
find_package(KDE4)
should still imply that you really want *all* components, and not none or only 
kdecore. Otherwise this would also succeed of only kdecore is there and your 
build would break later on, because you expected that all of kde(libs) is 
there.

Comments upto here ?


How to implement that in kdelibs ?

Currently, when installing kdelibs, FindKDE4Internal.cmake together with the 
file KDELibsDependencies.cmake and generated KDELibs4LibraryTargets.cmake and 
KDELibs4ToolsTargets.cmake files.

When doing a find_package(KDE4), the FindKDE4.cmake coming with cmake searches 
the FindKDE4Internal.cmake and includes it. This file then includes the other 
3 files and assumes they are located in the same directory as itself.

KDELibs4LibraryTargets.cmake is installed by the 
install( EXPORT kdelibsLibraryTargets ... )
call at the bottom of kdelibs/CMakeLists.txt.
It contains the exported targets for all installed libraries by kdelibs (they 
are marked via install(TARGET kdecore ... EXPORT kdelibsLibraryTargets) as 
belonging to the set "kdelibsLibraryTargets" of exported targets).

So, if we want to split kdelibs into modules this has to be changed, because 
as it is now we can only have all or none of these targets.

How fine grained do we want, or maybe better, _need_ it ?
KDELibs4LibraryTargets.cmake contains currently on my system 33 exported 
library targets:
ADD_LIBRARY(KDE4__nepomuk SHARED IMPORTED)
ADD_LIBRARY(KDE4__nepomukquery SHARED IMPORTED)
ADD_LIBRARY(KDE4__kdefakes SHARED IMPORTED)
ADD_LIBRARY(KDE4__kdecore SHARED IMPORTED)
ADD_LIBRARY(KDE4__kdeui SHARED IMPORTED)
ADD_LIBRARY(KDE4__kpty SHARED IMPORTED)
ADD_LIBRARY(KDE4__kdesu SHARED IMPORTED)
ADD_LIBRARY(KDE4__kjs SHARED IMPORTED)
ADD_LIBRARY(KDE4__kjsapi SHARED IMPORTED)
ADD_LIBRARY(KDE4__kjsembed SHARED IMPORTED)
ADD_LIBRARY(KDE4__kntlm SHARED IMPORTED)
ADD_LIBRARY(KDE4__kio SHARED IMPORTED)
ADD_LIBRARY(KDE4__solid SHARED IMPORTED)
ADD_LIBRARY(KDE4__kunittest SHARED IMPORTED)
ADD_LIBRARY(KDE4__kde3support SHARED IMPORTED)
ADD_LIBRARY(KDE4__kfile SHARED IMPORTED)
ADD_LIBRARY(KDE4__knewstuff2 SHARED IMPORTED)
ADD_LIBRARY(KDE4__knewstuff3 SHARED IMPORTED)
ADD_LIBRARY(KDE4__kparts SHARED IMPORTED)
ADD_LIBRARY(KDE4__kutils SHARED IMPORTED)
ADD_LIBRARY(KDE4__threadweaver SHARED IMPORTED)
ADD_LIBRARY(KDE4__khtml SHARED IMPORTED)
ADD_LIBRARY(KDE4__ktexteditor SHARED IMPORTED)
ADD_LIBRARY(KDE4__kmediaplayer SHARED IMPORTED)
ADD_LIBRARY(KDE4__kimproxy SHARED IMPORTED)
ADD_LIBRARY(KDE4__katepartinterfaces SHARED IMPORTED)
ADD_LIBRARY(KDE4__knotifyconfig SHARED IMPORTED)
ADD_LIBRARY(KDE4__kdnssd SHARED IMPORTED)
ADD_LIBRARY(KDE4__krosscore SHARED IMPORTED)
ADD_LIBRARY(KDE4__krossui SHARED IMPORTED)
ADD_LIBRARY(KDE4__plasma SHARED IMPORTED)
ADD_LIBRARY(KDE4__kunitconversion SHARED IMPORTED)
ADD_LIBRARY(KDE4__kdewebkit SHARED IMPORTED)


I think splitting this into 33 components would be a bit more than we need.

With whatever grouping we come up, the plan could be the following.
Assuming we come up with three groups kdelibsALibs, kdelibsBLibs and 
kdelibsCLibs, we would need to
 * change the install(TARGET ...) calls for the libraries to specify the 
respective export set, i.e. kdelibsALibs, kdelibsBLibs or kdelibsCLibs 
instead of kdelibsLibrarytargets
 * add the install(EXPORT ... ) calls at the bottom of kdelibs/CMakeLists.txt
 * modify FindKDE4Internal.cmake so it loads these smaller export-files 
instead of the KDELibs4LibraryTargets.cmake as it does now, using the 
COMPONENT keyword of find_package()


That's how far my thinking has come so far. 
Comments welcome :-)

Alex