KDE/kdepimlibs

[Ingo Klöcker]

On Friday 15 May 2009, Andreas Pakulat wrote:
> 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.

I have problems following this discussion. My naïve view is that I as 
application developer want to type something like

#include <KMime/Message>

to get the header of the Message class of the KMime library, just like I 
would do

#include <QtCore/QTextStream>
#include <QtCore/QByteArray>
#include <QtCore/QList>

to get the corresponding classes from the QtCore library.

I have no idea how KDE and KDEPimLibs come into play here. Is the 
question whether the Message header should be in
  <prefix>/include/KDE/KMime/
or
  <prefix>/include/KDEPimLibs/KMime/
?

Or is this discussion about whether it should be directly in
  <prefix>/include/KDE/
or
  <prefix>/include/KDEPimLibs/
?

IMHO, the latter makes no sense at all and does not seem to be what is 
done for Qt, so I hope that this is not what this discussion is about.

In the former KDE(PimLibs)?/KMime case it would be completely 
transparent for the application developer whether the KMime headers are 
in KDE or KDEPimLibs because he will simply add
  include_directories( ${KDEPIMLIBS_INCLUDE_DIR} )
to his CMakeLists.txt and not have to worry about the actual location of 
the KMime directory containing KMime's headers.

Again, this is just my completely naïve view of this situation.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090516/ebc21e97/attachment.sig