Forwarding headers for ThreadWeaver

[Mirko Boehm]

Hi, 

On 02 Jan 2014, at 15:37 , David Faure <faure at kde.org> wrote:

> 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?)

Actually, I *know* I have unpushed changes at home where I started with the class renaming. These will very likely clash with header file renamings. So I can take care of that on Saturday. If I need help, I will holler on IRC. 


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

Please wait, for the same reason as above. If you want to, we can set a time for Saturday and meet, and get everything ready. Sorry for being a pain here :-) 

What you could do is change the occasions you find that use the Weaver/ subdirectory to use the official include directory. Then removing the subdirectories should not affect anybody outside of the ThreadWeaver source. 

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

The class name changes will be source *in*compatible. 

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

Agreed, it is only a remote possibility and that can be managed when needed. 

Cheers,

Mirko.
-- 
Mirko Boehm | mirko at kde.org | KDE e.V.
FSFE Fellow, FSFE Team Germany
Qt Certified Specialist and Trainer