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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel