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