What are the plans with CamelCase includes?

Kevin Ottens ervin at kde.org
Sun Dec 29 16:39:47 UTC 2013


On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
> 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?

Consensus was: same place. The camel cased includes and the .h ones were 
planned to live in the same folder.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131229/ea16c849/attachment.sig>


More information about the Kde-frameworks-devel mailing list