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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5