cgiboudeaux at gmail.com
Tue May 12 21:38:49 CEST 2009
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
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
6/ Still for compatibility, we must keep KDEPIM_INCLUDE_DIR available until
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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
More information about the Kde-buildsystem