Extending ecm_generate_headers to create cross-forwarding headers?

Friedrich W. H. Kossebau kossebau at kde.org
Wed Jan 15 10:01:55 UTC 2014


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


More information about the Kde-buildsystem mailing list