[Kde-maemo] kdelibs modularizing (kde-mobile)

[Alexander Neundorf]

On Tuesday 27 April 2010, Alexander Neundorf wrote:
> On Tuesday 27 April 2010, Kevin Ottens wrote:
> > On Monday 12 April 2010 18:51:41 Alexander Neundorf wrote:
> > > On Monday 12 April 2010, Kevin Ottens wrote:
> > > > On Saturday 10 April 2010 19:34:14 Alexander Neundorf wrote:
> > > > > Doesn't look too bad, but I wouldn't commit it before there is
> > > > > something which also uses this.
> > > >
> > > > Well, it's chicken and egg problem. We kind need it in order to start
> > > > the efforts of cutting deps and so on which will use the content of
> > > > this patch.
> > > >
> > > > :-)
> > > >
> > > > Actually, the sooner it gets in, the sooner I can really start doing
> > > > the dependency cuts.
> > >
> > > How about putting it in together with the first use of it ?
> >
> > Wise man you are. While working on cutting deps in libplasma which is a
> > nice guinea pig there, I reworked the cmake related parts.
> >
> > There's two things the previous patch wasn't up to:
> >  - Keeping the high level controlling variable (profile and platform
> > features) out of the C++ realm by default;
> >  - Easily finding out from cmake what was the profile of kdelibs (which
> > other modules forming our platform should follow, kdepimlibs for instance
> > but probably others).
> >
> > So I took a different path, namely shipping an extra
> > KDEPlatformProfile.cmake with kdelibs just like we ship a
> > KDELibsDependenciesFile.cmake right now.
> >
> > Please find attached two patches against kdelibs (I left out the purely
> > C++ related changes in libplasma that Aaron already reviewed).
> > kdelibs_cmake_profiles.patch are the changes to our overall kdelibs build
> > with the new profile file installation, kdelibs_plasma_profiles.patch
> > shows the changes we would do to a lib build to take care of the platform
> > features declared by the profile.
> >
> > Please let me know if they're good to go. On my side they're ready to be
> > committed.
>
> kdelibs_cmake_profiles.patch:
> Looks good, but I would put the information not in a separate
> KDEPlatformProfile.cmake file, but just in the already existing
> KDELibsDependencies.cmake file.
>
> (if you have a look at that file you'll notice that the filename is just
> a "historic" relict and that it doesn't contain any dependency information
> anymore, this is now in the exported target-files).
>
> ...we might actually rename the KDELibsDependencies.cmake to
> KDELibs4Settings.cmake or something like that, and we might also think
> about installing these files somewhere in libs/ instead of share/...
> We'll have to make sure there are no compatibility issues if we rename/move
> this stuff.

Renaming the file to KDE4Config.cmake shouldn't be a problem.
Moving the files to lib/cmake/KDE4/ would be a relatively major problem I'm 
afraid.

When we do 
find_package(KDE4),
then the FindKDE4.cmake coming with CMake searches for FindKDE4Internal.cmake 
in the directory printed by kde4-config -path data.
This would not find FindKDE4Internal.cmake if we moved it from share/ to lib/.
When not moving FindKDE4Internal.cmake but the other files 
(KDELibsDependencies.cmake, KDEPlatformProfile.cmake, 
KDELibs4ToolsTargets.cmake, KDELibs4LibraryTargets.cmake) wouldn't help then, 
because we still would have only one entry point in share/, the 
FindKDE4Internal.cmake.
And how should this one file then determine whether the files to load are 
in ../lib/ or ../lib32/ or ../lib64/ or some other architecture-specific 
libdir.

So, if we want to move these files to lib/, we need to update the 
FindKDE4.cmake in CMake and then depend on the CMake version which will have 
this updated FindKDE4.cmake. So nothing for KDE 4.5 at least.

Alex