Am Mittwoch, 15. Januar 2014, 09:28:22 schrieb David Faure: > On Sunday 12 January 2014 23:04:03 Friedrich W. H. Kossebau wrote: > > Hi, > > > > ecm_generate_headers currently only supports forwarding includes for > > classes which are declared in a matching class.h header. Just, in KF5 > > there are a few classes which are declared in non-matching classes. E.g. > > in KParts, if you grep for KPARTS_EXPORT, you will find some like that. > > > > Worse, there were cross-forwarding (proper wording?) headers in > > kdelibs4/kde4support, so with just KF5::Parts some code will stop > > compiling, e.g. if it has > > #include <KParts/ReadOnlyPart> > > because KParts::ReadOnlyPart is declared in parts.h > > > > Looking at Qt5 I still cross-forwarding headers, e.g. > > $ cat qt5/qtbase/include/QtWidgets/QVBoxLayout > > #include "qboxlayout.h" > > > > I guess everyone agrees that just having to write > > #include <Class> > > or > > #include <Namespace/Class> > > without having to look in which header a class is really defined is very > > comfortable to have, right? So we would have to fix things. > > Yes. > > > Solutions: > > A) move any class declarations into proper class.h files > > For backward compatibility any moved class declarations would be > > substituted with a #include "class.h" at the old place, guarded by some > > #ifdef KDE4Support > > Yes, this is what I did in a few places when converting everything to > ecm_generate_headers. > (e.g. karchive, but also some others). > Seems I missed KParts. > Ah - I know why - that's one of the *two* frameworks out of 57 that I didn't > port myself ;) > > I think this solution is the easiest and the best one. > * easiest because no need to make ecm_generate_headers more complex > (honestly "cross forwarding" would mean nothing to me, without reading this > entire email) > * best because it makes the source code clean. You look for a class in order > to hack on it -> it's in <lowerclassname>.h > > Qt doesn't do that in qboxlayout.h for old historical reasons, but does so > in any newer code AFAIK.
Okay, fine with me (second reason is how I prefer code to be organised as well). Guess you already started to tackle that? :) Or should I give it a try tonight? Cheers Friedrich _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
