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
