KDE/kdepimlibs

[Alexander Neundorf]

On Tuesday 12 May 2009, Pino Toscano wrote:
> 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

Question here is, what is KDE.
Must any package which links against kdecore install its headers into 
include/KDE/ ?
I would see include/KDE/ actually more as the include directory for the 
kdelibs module.
That's also what 
find_package(KDE4)
does, it doesn't find everything on the system which is KDE-related, it finds 
only kdelibs.
I think I agree with Christophe that installing kdepimlibs into its own subdir 
would be a good thing.
I would also see this as appropriate e.g. for kdevplatform and the koffice 
libs. They are really independent projects.
(... we also don't install our headers into the Qt include dir, although all 
KDE applications use QtCore ;-)  )

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

It's how "the rest of KDE" is defined. As I said above, I think it makes sense 
to see include/KDE/ as the include dir for the core of KDE, which is kdelibs.

Alex