On Thursday 02 January 2014 11:42:57 Christoph Cullmann wrote: > > > This wasn't intended I guess. When the discussion about include files > > > occured the consensus was to have everything in a single directory (the > > > camel cased one). > > > > OK I initially thought it was so the implementation of > > ecm_generate_headers > > is > > simpler (lowercase everything), but in fact that's not it, it lowercases > > individual parts explicitely. > > > > In fact if we only use a camelcase header, the CMakeLists.txt code is even > > simpler because the INSTALL(DIRECTORY) line will install both kinds of > > headers. Which removes the need for the KCoreAddons_HEADERS variable > > altogether. > > See attached patch. > > > > Aleix, any objections? > > > > I'll script this over all modules, if not. > > > > I think the reasoning might have been: so that people can include > > <kcoreaddons/krandom.h>. But I'm not sure we even want to allow that. > > It breaks the whole idea that "the install dir is transparent to the > > apps", > > the idea of compile-time errors (header not found) when not linking to the > > appropriate lib, and of course it will break when we move stuff around for > > kf6. > > Well, we can't physically prevent people from writing #include > > <KCoreAddons/krandom.h> or <KCoreAddons/KRandom>, but the fact that the > > first one looks weird will at least reduce the chances of people doing > > that :) > Hmm, > > just a question for the case, that we have a namespace, like KTextEditor. > > At the moment we install (e.g. for KTextEditor::View): > > KTextEditor/View > > and > > ktexteditor/view.h > > Will that change still make that possible?
Ah, good point. The answer is: yes, if we put both under the framework name. If the framework is called KTextEditor, then this would lead to include/KF5/KTextEditor/KTextEditor/View include/KF5/KTextEditor/ktexteditor/view.h The benefit of that is that when an app forgets to link to KTextEditor, [which adds include/KF5/KTextEditor to the include path] the includes won't work. With the current solution, they will still work, which is inconsistent with non-namespaced headers. I already set things up this way for KIO, which has both namespaced and non- namespaced headers. include/KF5/KIOCore/KIO/ListJob include/KF5/KIOCore/kio/listjob.h Note the difference between the framework name (KIOCore) and the namespace (KIO), so it looks like it makes more sense here than when writing KTextEditor/KTextEditor - but that's just because your framework name matches your namespace name :-) What do you think? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
