Extending ecm_generate_headers to create cross-forwarding headers?

[Friedrich W. H. Kossebau]

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.


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

B) extend ecm_generate_headers to also create cross-forwarding headers
No real idea for a good cmake pattern here, somehow there should be multiple 
pairs possible with each the name of the normal header.h and the list of class 
names. Is that better done with additional parameters to ecm_generate_headers, 
or by separate macros? The latter might mean duplication needed of 
REQUIRED_HEADERS, PREFIX and MODULE, so perhaps the first is better, even if 
it might look strange.

E.g. the usage would be like this:
ecm_generate_headers(
    Part
    Plugin
    PartManager
    MainWindow
    Event
    BrowserExtension
    HistoryProvider
    BrowserInterface
    BrowserRun
    StatusBarExtension
    BrowserOpenOrSaveQuestion
    ScriptableExtension
    TextExtension
    HtmlExtension
    FileInfoExtension
    ListingExtension

    CROSSCLASSES PartBase ReadOnlyPart ReadWritePart OpenUrlArguments
    CROSSHEADER part.h

	 CROSSCLASSES BrowserArguments WindowArgs OpenUrlEvent BrowserHostExtension 
LiveConnectExtension
	CROSSHEADER browserextension.h

	 [...]

    REQUIRED_HEADERS KParts_HEADERS
    PREFIX KParts
)

Or perhaps just e.g.
    CROSS part.h  PartBase ReadOnlyPart ReadWritePart OpenUrlArguments

C) ?


I personally would favour B) as it matches Qt's behaviour and allows people to 
keep (personal) habits to put related class declarations into the same file, 
so in general offer more flexibility.

What do you think? If B) what macro call extension would you propose, with 
which keywords?

Cheers
Friedrich