What are the plans with CamelCase includes?

[Aleix Pol]

On Tue, Dec 31, 2013 at 12:50 PM, David Faure <faure at kde.org> wrote:

> On Sunday 29 December 2013 23:23:44 Friedrich W. H. Kossebau wrote:
> > Am Sonntag, 29. Dezember 2013, 17:39:47 schrieb Kevin Ottens:
> > > On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
> > > > So possibly something more that needs to be decided on: where should
> > > > plain headers end up?
> > >
> > > Consensus was: same place. The camel cased includes and the .h ones
> were
> > > planned to live in the same folder.
> >
> > To have the same pattern like Qt5 uses, I guess? Makes also sense to me.
> >
> > So by example of KI18n:
> >
> > Instead of
> >
> > include/KF5/klocalizedstring.h
> > include/KF5/KI18n/KLocalizedString
> >
> > there should be
> >
> > include/KF5/KI18n/klocalizedstring.h
> > include/KF5/KI18n/KLocalizedString
> >
> > right?
>
> No,
> include/KF5/ki18n/klocalizedstring.h
> include/KF5/KI18n/KLocalizedString
>
> (lowercase ki18n in the first line).
>
> See "make install" in kcoreaddons now:
>
> -- 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}.
>

> Aleix, is there a final version of that RFC in a wiki page maybe, so we can
> all make sure we refer to the same "spec" for this?
>

Ok, maybe I should be changing the ones we have now CamelCased to KF5/KDE/.
Having a KDE namespace doesn't make much sense though, if the idea is not
to break source compatibility, we can just tell people to either depend on
KDE4Support or to move from KDE -> {ModuleName}.

I don't know about any page on the wiki about headers structure. We really
need this.


>
> > (kuitmarkup.h possibly was not renamed to kuitsetup.h for backward
> support)
> >
> > And KF5I18nTargets.cmake should have both:
> >   INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/KF5"
> >   INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/KF5/KI18n"
>
> Yes, see the KCoreAddonsTargets file ;)
>
> > Now, what to expect for "frameworks not using the K* prefix for their
> > classes (and generally using namespaces)", by example of KParts:
> >
> > include/KF5/KParts/KParts/StatusBarExtension
> > include/KF5/KParts/KParts/ListingExtension
> > include/KF5/KParts/kparts/statusbarextension.h
> > include/KF5/KParts/kparts/browseropenorsavequestion.h
>
> I think this is what we should have, but the RFC thread isn't really clear
> to
> me, hence my request for a final spec.
>

The RFC thread is more about whether include/.../KCoreAddons
and  include/.../kcoreaddons should be by default in the include paths or
not.

>
> > More questions:
> >
> > Q: Really hardcode KF5/ prefix to include path?
> >
> > The KF5/ part of the include path, does it make sense in all deployments
> > given that all headers are already contained in subdirs? IMHO that should
> > be left to be defined by the packager/installer. For what reason would we
> > want to enforce that?
>
> For co-installability in /usr/include.
>

I have another pro. This way you never include files without wanting to.
With the new headers structure you have to explicitly link against a module
to be able to find the headers of a framework. That's good, because it's
easier to diagnose a missing dependency from missing includes than weird
linker errors.


>
> > Will there be any files outside of the $MODULENAME/ subdirs?
>
> I don't think so.
>
> > Q: Add a convenience Module/Module file?
> >
> > What about adding a convenience include-all file Module/Module, e.g.
> > include/KF5/KI18n/KI18n, like there usually is one with each Qt module?
>
> I don't like them very much. They make compilation slower, and allow
> people to
> be lazy instead of doing the right thing....
> In quick test programs they are fine, but they are quickly abused in real
> code...
> Well, I won't veto them (consistency is good), but I certainly won't spend
> time on them.
>

AFAIK, it hasn't been discussed. Personally I've never been happy when
using those. I hear they're good when using precompiled headers, but I've
never experienced that myself.


>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
>
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131231/97c28a7d/attachment.html>