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

[Friedrich W. H. Kossebau]

Am Mittwoch, 29. April 2020, 21:41:37 CEST schrieb 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?

No, this is not what I mean here. COMMON_HEADER (from what I understand) 
creates a include-complete-module-headers convenience header, to be used 
instead of including individuals headers as needed. As in: #include <QtCore>

I meant something similar to qglobal.h, so providing export macros, version 
macros and posible similar module-wide code things which one would expect 
available in all places more or less. And which thus one would expect to 
already be included when using other classes/stuff from a module.

Cheers
Friedrich