KDE/kdepimlibs

[Pino Toscano]

Alle martedì 12 maggio 2009, Christophe Giboudeaux ha scritto:
> 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...

Being incoherent with what was done with KDE CamelCase includes so far.

> 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.

Arguable.

> 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.

They all are KDE CamelCase includes.

> 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.

Unrelated.

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

... and?

> 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).

Ageed on the compatibility, and?

> 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.

Coherency with other modules?
- all of KDE installs lowercase includes in $prefix/include, CamelCase ones in 
$prefix/include/KDE
- kdepimlibs installs lowercase includes in $prefix/include, CamelCase ones in 
$prefix/include/KDEPimLibs
See the asymmetry/incoherency? Which message to 3rd parties do we give with 
this?

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

Unrelated to the choice.

> 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.

This is completely unrelated to choosing $prefix/include/KDE vs 
$prefix/include/KDEPimLibs for installing CamelCase includes.

So, are there other serious reasons, other than that kdepimlibs "looks 
special(?)" wrt the rest of KDE?

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