What are the plans with CamelCase includes?

[David Faure]

On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
> 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}.

Ah, for old-style #include <KDE/KIcon>?
Let's just script that away and make it #include <KIcon>.

We don't need a KDE prefix, we already have a KF5 prefix at install time.

This is the <QtGui/QLabel> thing again. Prefixes in the #include line create 
future trouble when the prefix isn't related to the C++ class/namespace but 
just arbitrary.

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

Well, that much is clear, the answer is yes, we want #include <kjob.h> and 
#include <KJob>, no prefix in the #include line.

But ... going back to the question of where we should install kparts 
headers... I'm pretty sure you and Aurélien (and others, possibly) had come up 
with a final solution, didn't you?

> 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.

Yes.

> > > Q: Add a convenience Module/Module file?
> > > 
> 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.

Exactly: that's what they're good for, but in an opensource environment you 
can't know what people are going to be using as setup for compiling (unlike a 
more controlled internal-to-one-commercial-company setup), so we can't rely on 
people having precompiled headers support.
However, with that argument, we could be providing all-in-one headers for the 
benefit of commercial companies who can be sure they use precompiled 
headers... Oh well, let's postpone this, it's more urgent to install the stuff 
in the first place.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5