Having $(framework)_global.h headers (was: Re: building KF5 projects against a different Qt5 version [...])

[Friedrich W. H. Kossebau]

Am Sonntag, 26. April 2020, 16:12:31 CEST schrieb Friedrich W. H. Kossebau:
> Am Sonntag, 26. April 2020, 15:46:35 CEST schrieb David Faure:
> > On Sunday, April 26, 2020 3:21:34 PM CEST René J.V. Bertin wrote:
> > > Talking about version test hacks (or not-so-hacks): why is it that
> > > KFOO_VERSION isn't defined systematically when you include any header of
> > > the FOO KF5 framework? With Qt you never have to worry about QT_VERSION
> > > being defined.
> > 
> > Well, everything in Qt ends up including global.h
> > There's no such central header in KF5 frameworks (which are more modular,
> > by definition), so you need to include the framework_version.h header.
> We could perhaps look into extending the export headers into some kind of $
> (framework)_global.h headers, like we are now doing already a bit for all
> the deprecation definitions when using ecm_generate_export_header, where
> all additional stuff is injected via the export headers.
> 
> I also found a bit annoying to have to add all the explicit includes of
> framework_version.h every time one wanted to access KFOO_VERSION.
> 
> So far had only pondered the idea at that time, no yet investigated further
> given state of own TODO list :) Also low motivation given that there would
> need to be a backward-compatible setup, and usually one uses that very
> version header to be compatible to old versions, so there was no immediate
> gain. But long time (at least KF6) I would also prefer to see the version
> macros available by default.

And I meanwhile noticed that the actual version number of a library is already 
present in the export headers generated with ECMGenerateExportHeader, due to 
being a possible default number for all the version-dependent calculations for 
what to show warnings or which API to hide. Not accessible as macro though, so 
do not have hopes to "abuse" this :)

Given this kept following me into my shower thoughts this morning, guess I 
will soonish be working on some ECMGenerateGlobalHeader then, or at least 
explore more for now in some non-ECM projects the feasibility of semi-
generation of such global header carrying all the stuff interesting with all 
the (public) API of a library. Ping me again in autumn about this.

Cheers
Friedrich