Forwarding headers for ThreadWeaver

[David Faure]

On Thursday 02 January 2014 15:29:13 Mirko Boehm wrote:
> > The official way used by all other modules would be
> > threadweaver/job.h (lowercase real header) and
> > ThreadWeaver/Job (forwarding header)
> 
> Ok.

Is this a green light for us to convert all of threadweaver (and its users) to 
this scheme? (or do you plan to do so?)

> > OTOH to really make threadweaver like the other modules, I would move
> > src/Weaver/* to src/*, the subdir isn't useful.
> 
> Is that a change that has any meaning to the outside world? If not, that can
> be done later as well.

Well, it makes sure that nothing can include <Weaver/File.h> :)
But OK, only two unittests do that, I thought there was more.

I'll make that change unless you object, because it makes it easier to script 
stuff across all frameworks (like I've been doing in the last 48 hours, and 
will do again since we changed the include path a little bit...).

> > I want to release TP1 asap (i.e. once all forwarding headers are
> > installed), but SIC changes can still be done afterwards.
> 
> Threadweaver cannot be released before the class name changes are done,
> because those will be source incompatible. I get back tomorrow night, and
> will finish it on Saturday. After that, all other changes are incremental
> and BC, so the release would get unblocked. Sorry for that.

As I said, TP1 does NOT include a SC promise, it's ok to make SC changes 
afterwards.

But yeah, with the unexpected delays due to the forwarding header stuff it's 
too late for tagging today, so I'll do that on Sunday, with your changes from 
Saturday in.

> OSX uses a case insensitive but in all other aspects UNIX like file system
> (with symlinks et cetera) by default. I feel slightly uncomfortable with
> installing into the same directory because it may lead to weird clashes if
> there are file names that only differ in case  - those will end up being
> the same file on Windows and OSX. Can be avoided, but is a potential
> pitfall.

Only the directories clash, never the actual files, since the lowercase 
headers have a ".h" extension and the CamelCase headers have no extension.

And we can't fully fix the clash anyway... for non-namespaced frameworks like 
kcoreaddons we can (KCoreAddons/kjob.h and KCoreAddons/KJob) but for 
namespaced frameworks like KIO and KParts (and ThreadWeaver) we'll still have
KIOCore/KIO/Job and KIOCore/kio/job.h, since there's a lot of code that uses 
<kio/job.h> out there. My planned fix is to never lowercase the framework name 
anymore, but the prefix can be lowercased, leading to KIO and kio dirs side by 
side. No filename clash though, ever.

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