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. _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
