Hi, On 02 Jan 2014, at 15:37 , David Faure <fa...@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 | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
