KDE/kdepimlibs

[Christophe Giboudeaux]

On Tuesday 12 May 2009 19:31:41 Andreas Pakulat wrote:
>
> As asked by Pino (just to make sure that this doesn't get lost as I've
> discussed with him a bit different things): Why is this done at all? All
> the headers in kdepimlibs are namespaced with the relevant libraries
> inside prefix/include/KDE. So whats the reasoning? I don't see the old
> version create problems for anyone, but apparently all applications that
> used the old dir need to be built from scratch so cmake find the right
> include dirs (and doesn't use the cache).
>

Well, I don't see any problem created by the new prefix...

Several thoughts then :

1/ When looking at my current /usr/include/KDE, it looks like a giant blob 
where all kinds of headers from every module (seems to) live happily.

I wouldn't call that a generic dir but the inheritance for the KDE3 behaviour. 

I don't really understand how logical it would be to have the pimlibs headers 
in the same directory as (eg) KZip, OrgKdeKDirNotifyInterface or ThumbCreator.

2/ The cmake introduction in the build system (and specially since cmake > 
2.6.0) made installation in random prefixes quite easy and the KDE modules are 
much more modular.

3/ The kdepimlibs camelcase headers will be available for the first time in 
KDE 4.3.

4/ The consequence of 3: for compatibility reasons, we won't be able to change 
this directory after 4.3 if we go for /KDE (which should, imo, be reserved for 
the KDE core headers, ie KDELibs).

5/ Considering 1,2 and 3, I still didn't read any valid reason for using the 
same prefix as kdelibs, kdebase, kdegames etc... and add more files inside 
/KDE.

6/ Still for compatibility, we must keep KDEPIM_INCLUDE_DIR available until 
KDE5.

The consequence of 2 and 6 is that, even after 3 monthes, some projects still  
wrongly use KDEPIMLIBS_INCLUDE_DIR where they need KDEPIMLIBS_INCLUDE_DIRS. 
That just simply breaks the compilation for whoever doesn't install kdepimlibs 
in the same prefix as kdelibs.

I absolutely want to avoid such problems in the future.

Christophe.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090512/66422408/attachment-0001.sig