[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-maemo
Subject:    [Kde-maemo] Fwd:  KDE Platform Mobile
From:       gladhorn () kde ! org (Frederik Gladhorn)
Date:       2010-03-09 18:34:23
Message-ID: 201003091934.27749.gladhorn () kde ! org
[Download RAW message or body]

On Tuesday 09 March 2010 11:29:26 Kevin Ottens wrote:
> On Tuesday 9 March 2010 11:11:30 Volker Krause wrote:
> > In my understanding the profile stuff just defines the defaults for the
> > various internal #defines that affect a specific feature. That's at least
> > what I have been starting to do in kdepimlibs/kdepim regarding getting
> > rid of KResources for example. The profile stuff is still very important
> > IMHO as it defines what features you can expect on a certain platform.
> > Otherwise we will end up with everyone shipping there specially
> > configured libs along (although we keep that option open for special
> > cases where this might be the only way to go).
> 
> Spot on. That's exactly the intent. That's why I provided a table with
>  several lines in my previous mail. Your work on removing KResources falls
>  into the "Removing deprecated classes from the build" category.
> 
> The profiles are here to provide defaults for all those low level options.
> 
> Note that at first I wouldn't like to make it too easy to change individual
> low level options though, otherwise we'll quickly end up with indeed
>  everyone shipping different versions.
> 
> Regards.
> 

Hi, since I already wrote a "this is what it might look like" patch for 
kdelibs cmakelists.txt, I might as well share that.

The idea is to create a simple header file, that contains the selected profile 
(maybe it shouldn't?) and the individual features that were enabled or 
disabled. This file can then be included elsewhere to enable/disable parts of 
kdelibs and/or apps.

This is just a proof of concept and probably it would be best to ask kde-
buildsystem how to do this patch for real. The actual variables need to be 
better named of course, as mentioned in this thread.

The magic in the FindKDE.cmake is still missing, but it could be implemented 
by just examining the installed config header, so that the information is 
available in cmake when building other modules.

Cheers,
Frederik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdelibs_profiles.diff
Type: text/x-patch
Size: 4040 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-maemo/attachments/20100309/1ecc1392/attachment.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-maemo/attachments/20100309/1ecc1392/attachment.sig 

[prev in list] [next in list] [prev in thread] [next in thread]