What are the plans with CamelCase includes?

[Friedrich W. H. Kossebau]

Am Samstag, 28. Dezember 2013, 12:32:43 schrieb Kevin Ottens:
> On Saturday 28 December 2013 11:55:56 David Faure wrote:
> > On Friday 27 December 2013 19:01:09 Friedrich W. H. Kossebau wrote:
> > > So existing code ported from kdelibs would have to explicitely prefix
> > > the
> > > includes, e.g. be changed like
> > > #include <KLocalizedString> -> #include <KI18n/KLocalizedString>
> > 
> > Definitely don't want this.
> > 
> > See the QtGui/QLabel -> QtWidgets/QLabel issue between Qt4 and Qt5, we
> > don't want to create the same problems with KDE Frameworks.
> > 
> > So yeah, I'm definitely in favour of "*Targets.cmake files,
> > should include the path including the module prefix"
> 
> Which is supposed to be the case as discussed in the thread with Aurélien a
> while ago.
> 
> The complete consensus was IIRC:
>  - For frameworks with K* prefixed classes, the include line should be
> #include <KFoo>;
>  - For frameworks not using the K* prefix for their classes (and generally
> using namespaces) the include line should be #include <Framework/Foo>.
> 
> With the forward headers included, if the frameworks doesn't behave like
> that it should be considered a bug.
> 
> Cheers.

Another problem with the current macro is that it expects the normal headers 
in a path postfixed with the module name, by always writing the 
CamelCase/forwarding headers like:

	file(WRITE ${FANCY_HEADER_NAME}
		  "#include \"${lowercasemodule}/${lowercaseclassname}.h\"\n")

e.g. resulting in [..]/include/KF5/KI18n/KLocalizedString containing
#include "ki18n/klocalizedstring.h"

Which of course will fail, as currently the plain *.h headers are installed 
directly into the include path, not in a subdirectory named with the module 
name. So possibly something more that needs to be decided on: where should 
plain headers end up?

Cheers
Friedrich