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

[David Faure]

On lundi 27 avril 2020 14:28:42 CEST Friedrich W. H. Kossebau wrote:
> 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.

I know it's not autumn yet, but isn't this what COMMON_HEADER in 
ecm_generate_headers already does, actually?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5