What are the plans with CamelCase includes?

[David Faure]

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?

> (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.

> 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.

> 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.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5