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

[Alexander Neundorf]

On Wednesday 28 April 2010, Kevin Ottens wrote:
> On Tuesday 27 April 2010 22:02:33 Alexander Neundorf wrote:
> > 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).
>
> Yeah, thought about it already, and after all started a separate files for
> the following reasons:
> 1) The indeed unclear name of KDELibsDependencies.cmake and I didn't want
> to worsen the situation;
> 2) To keep the profile definition readable an maintainable, putting the
> logic in CreateKDELibsDependencies.cmake it'd be buried with a lot of other
> details

Well, ok. OTOH all these settings would be in one place then.

> 3) The platform profile definition has to be processed as early as possible
> (in particular before the add_subdirectory directives) while the other
> definitions can come up later apparently;

They are both included in FindKDE4Internal.cmake, so I think this doesn't 
matter ?

> 4) And, it's really meant to be a controlling file also for other modules
> forming our platform like kdepimlibs but which aren't kdelibs, a
> KDELibsSomething name would just give the wrong signal IMO.

Well, strictly speaking, FindKDE4.cmake would have to be FindKDELibs4.cmake.
So, in the buildsystem, whenever something global to all of KDE4 appears, it 
comes from kdelibs.
Other modules will not see that file directly anyway, since it is included 
automatically in FindKDE4Internal.cmake.

> > ...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.
>
> Right, would make a lot of sense IMO.
>
> I'll leave it up to you though. So I'm planning to commit this part of the
> patch as is (I'd really need that committed now). Should be fairly easy to
> merge back the files into a new one later on and will be almost transparent
> for me.

So I'll have a look at that in the next time.

Alex