KDE/kdepimlibs

Andreas Pakulat apaku at gmx.de
Tue May 12 18:03:29 CEST 2009


On 12.05.09 10:54:32, Pino Toscano wrote:
> Alle martedì 12 maggio 2009, Andreas Pakulat ha scritto:
> > On 11.05.09 23:23:25, Pino Toscano wrote:
> > > Alle lunedì 11 maggio 2009, Christophe Giboudeaux ha scritto:
> > > > SVN commit 966746 by cgiboudeaux:
> > > >
> > > > As mentioned by Alex when KDEPIMLIBS_INCLUDE_DIRS was created,
> > > > installing the kdepimlibs CamelCase headers in the same dir as the
> > > > kdelibs ones is not a good idea. (different package -> different dir).
> > > >
> > > > They will now be installed in include/KDEPIMLIBS.
> > >
> > > I don't understand the logic behind this move.
> >
> > For one thing, it makes sure we don't get name clashes, which is
> > particularly bad as CMake will just happily overwrite existing files
> > without further notice.
> 
> If there is a name clash, then this won't solve anything, as doing
> #include "clashingheader.h"
> (with no path, assuming you added it in the include path).

Right, but that can be easily fixed by the author of that application.
However, fixing a naming clash on the filesystem involves quite a bit more
work, as you need a new release of the library in question and you possibly
need to update all applications that use the library.

> And still, did we actually have this issue, yet?

If you have that, its too late already.

> > > Currently, we have the following situation:
> > > - all the .h files from any KDE modules go to $prefix/include
> >
> > KDevPlatform and any public API from KDevelop plugins all go into
> > $prefix/include/kdevplatform/$library and
> > $prefix/include/kdevelop/$plugin
> >
> > So its not "all" KDE modules :)
> 
> Actually you've just proven my point, because kdevelop _does_ install them in 
> $prefix/include, just organized them in a subdir.

Right, thats what KDE should do as well. So in fact kdeui should install
its headers into prefix/include/kdeui, kdepimlibs into
prefix/include/kdepimlibs. We could have a "convenience" directory
prefix/include/KDE with all of them, but again as soon as there are too
modules installing foobar.h this is going to be a problem.

> The right comparison would have been if kdevelop installs them in let's say 
> $prefix/kdevelop-include.

Thats just insane and violates all common sense.

> > > - before this commit, all the CamelCase includes would go
> > > $prefix/include/KDE, from any KDE module (eg kdelibs, kdepimlibs,
> > > kdebase-workspace, kdegames, etc)
> > > But now kdepimlibs differs and will install its CamelCase includes in a
> > > different location. I don't see them conflicting with kdelibs (or other
> > > modules) ones, so... why?
> >
> > Not now, but what about the future? IMHO _all_ modules should do the
> > same as kdepimlibs does. _No_ library should ever install headers
> > directly into $prefix/include, they should _always_ be in
> > $prefix/include/$library - IMHO. And thats also what distributions
> > patch into their package anyway.
> 
> Again, you did not understand me.
> I'm not speaking about the direct installation of .h files in 
> $prefix/includes, but the installation of CamelCase headers for kdepimlibs, 
> which before were in $prefix/include/KDE (which _is_ "namespaced" enough 
> already)

You assume that all classes from kdepimlibs have very specialized names (I
didn't check this), so they can never clash with any other headers from
other modules. This might even be true right now, but do you know which
kdepimlibs headers are going to be installed in 3 years? The longer the
library exists the more painful it will be to change the header locations
later on.

> to $prefix/include/KDEPimLibs.
> Isn't $prefix/include/KDE "namespaced" already?

Yes, across all of KDE main modules, which might or might not be enough. If
KDevPlatform would install camelcase versions of its public API into
prefix/include/KDE we'd most probably have naming clashes rather sooner
than later because of:

IPlugin
ICore
IAssistant
ISession
ProjectModel

and possibly more. And namespacing those files with KDev_ would obviously
defeat the purpose of the camelcase includes.

Andreas

-- 
You are going to have a new love affair.


More information about the Kde-buildsystem mailing list