What are the plans with CamelCase includes?

Aleix Pol aleixpol at kde.org
Thu Jan 2 13:41:27 UTC 2014


On Thu, Jan 2, 2014 at 12:31 AM, David Faure <faure at kde.org> wrote:

> On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
> > > -- Up-to-date:
> > > /d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
> > > -- Up-to-date:
> > > /d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
> > >
> > > The email thread "RFC Rules for installation of header files" does say
> > >
> > > >>> If the header files of a framework are not prefixed, then they
> should
> > > >>> be installed in include/{lowercaseframework} and convenience
> headers
> > > >>> should be installed in include/KDE/{CamelCaseFramework}.
>
> Actually, what's the reason for lowercaseframework there?
>
> I used that in all the modules I converted (except KIO, I just realized),
> and
> I'm wondering what the point is.
>
> Example:
> include/KF5/KIOCore/KFileItem
> include/KF5/KIOCore/kfileitem.h
> works fine with KIOCore in the include path, apps just include <KFileItem>
> or
> <kfileitem.h>
>
> If I fix it to
> include/KF5/KIOCore/KFileItem
> include/KF5/kiocore/kfileitem.h  [all lowercase]
> it will of course work too, with both dirs in the include path.
>
> It's all transparent for the apps either way, since the cmake magic
> encapsulates it for the them.
>
> I'm just wondering what's the point in using two different dirs for
> kfileitem.h and KFileItem?
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
>
I did it like that because KParts works this way. Of course, it's not
required on other modules.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140102/35aa0e31/attachment.html>


More information about the Kde-frameworks-devel mailing list