<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 31, 2013 at 12:50 PM, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im">On Sunday 29 December 2013 23:23:44 Friedrich W. H. Kossebau wrote:<br>
> Am Sonntag, 29. Dezember 2013, 17:39:47 schrieb Kevin Ottens:<br>
> > On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:<br>
> > > So possibly something more that needs to be decided on: where should<br>
> > > plain headers end up?<br>
> ><br>
> > Consensus was: same place. The camel cased includes and the .h ones were<br>
> > planned to live in the same folder.<br>
><br>
> To have the same pattern like Qt5 uses, I guess? Makes also sense to me.<br>
><br>
> So by example of KI18n:<br>
><br>
> Instead of<br>
><br>
</div>> include/KF5/klocalizedstring.h<br>
> include/KF5/KI18n/KLocalizedString<br>
><br>
> there should be<br>
><br>
> include/KF5/KI18n/klocalizedstring.h<br>
> include/KF5/KI18n/KLocalizedString<br>
><br>
> right?<br>
<br>
No,<br>
include/KF5/ki18n/klocalizedstring.h<br>
include/KF5/KI18n/KLocalizedString<br>
<br>
(lowercase ki18n in the first line).<br>
<br>
See "make install" in kcoreaddons now:<br>
<br>
-- Up-to-date: /d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h<br>
-- Up-to-date: /d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData<br>
<br>
The email thread "RFC Rules for installation of header files" does say<br>
>>> If the header files of a framework are not prefixed, then they should<br>
>>> be installed in include/{lowercaseframework} and convenience headers<br>
>>> should be installed in include/KDE/{CamelCaseFramework}.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
Aleix, is there a final version of that RFC in a wiki page maybe, so we can<br>
all make sure we refer to the same "spec" for this?<br></blockquote><div><br></div><div>Ok, maybe I should be changing the ones we have now CamelCased to KF5/KDE/. Having a KDE namespace doesn't make much sense though, if the idea is not to break source compatibility, we can just tell people to either depend on KDE4Support or to move from KDE -> {ModuleName}.<br>

</div><div><br></div><div>I don't know about any page on the wiki about headers structure. We really need this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="im"><br>
> (kuitmarkup.h possibly was not renamed to kuitsetup.h for backward support)<br>
><br>
> And KF5I18nTargets.cmake should have both:<br>
>   INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/KF5"<br>
>   INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/KF5/KI18n"<br>
<br>
</div>Yes, see the KCoreAddonsTargets file ;)<br>
<div class="im"><br>
> Now, what to expect for "frameworks not using the K* prefix for their<br>
> classes (and generally using namespaces)", by example of KParts:<br>
><br>
</div>> include/KF5/KParts/KParts/StatusBarExtension<br>
> include/KF5/KParts/KParts/ListingExtension<br>
> include/KF5/KParts/kparts/statusbarextension.h<br>
> include/KF5/KParts/kparts/browseropenorsavequestion.h<br>
<br>
I think this is what we should have, but the RFC thread isn't really clear to<br>
me, hence my request for a final spec.<br></blockquote><div><br></div><div>The RFC thread is more about whether include/.../KCoreAddons and  include/.../kcoreaddons should be by default in the include paths or not. </div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> More questions:<br>
><br>
> Q: Really hardcode KF5/ prefix to include path?<br>
><br>
> The KF5/ part of the include path, does it make sense in all deployments<br>
> given that all headers are already contained in subdirs? IMHO that should<br>
> be left to be defined by the packager/installer. For what reason would we<br>
> want to enforce that?<br>
<br>
</div>For co-installability in /usr/include.<br></blockquote><div><br></div><div>I have another pro. This way you never include files without wanting to. With the new headers structure you have to explicitly link against a module to be able to find the headers of a framework. That's good, because it's easier to diagnose a missing dependency from missing includes than weird linker errors.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Will there be any files outside of the $MODULENAME/ subdirs?<br>
<br>
</div>I don't think so.<br>
<div class="im"><br>
> Q: Add a convenience Module/Module file?<br>
><br>
> What about adding a convenience include-all file Module/Module, e.g.<br>
> include/KF5/KI18n/KI18n, like there usually is one with each Qt module?<br>
<br>
</div>I don't like them very much. They make compilation slower, and allow people to<br>
be lazy instead of doing the right thing....<br>
In quick test programs they are fine, but they are quickly abused in real<br>
code...<br>
Well, I won't veto them (consistency is good), but I certainly won't spend<br>
time on them.<br></blockquote><div><br></div><div>AFAIK, it hasn't been discussed. Personally I've never been happy when using those. I hear they're good when using precompiled headers, but I've never experienced that myself.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE, in particular KDE Frameworks 5<br>
<br>
</div></div></blockquote></div><br></div><div class="gmail_extra">Aleix</div></div>