KDE/kdepimlibs

[Andreas Pakulat]

On 14.05.09 21:08:10, Alexander Neundorf wrote:
> On Thursday 14 May 2009, Andreas Pakulat wrote:
> > On 13.05.09 18:37:53, Alexander Neundorf wrote:
> ...
> > Agree.
> > > I think I agree with Christophe that installing kdepimlibs into its own
> > > subdir would be a good thing.
> >
> > I do understand your point, but IMHO having now one or two modules in
> > include/<modulename> but other modules (not only kdelibs, but also
> > kdebase libs) in include/KDE just adds confusion. We should just put
> > this down as todo for KDE5 to use include/<modulename> for _all_ modules
> > including kdelibs and leave what we have now so its at least consistent
> > - even though not perfect.
> >
> > > ...
> > >
> > > > 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.
> >
> > I don't, for me include/KDE naturally translates to any core module of
> > KDE (i.e. anything in trunk/KDE). Only include/KDELibs would translate
> > to kdelibs to me.
> 
> This is really the question.
> And I tend towards include/KDE/ is kdelibs.
> So, but while we allow non-kdelibs but KDE/ headers to be installed there, I 
> don't see a reason why we should really enforce it ?

Well, if we do not enforce other modules to install their camelcase headers
into prefix/include/<modulename> then we create even more confusion IMHO.
If its not enforced, then chances are good that some modules still install
their camelcase headers to include/KDE, which means the application author
is in a situation where some headers are easily associated to the related
module, but other are not - he'll get confused because things are
inconsistent.

Andreas

-- 
You will soon forget this.