RFC: KF (& other lib) consumers: want KFOO_VERSION macro definitions automagically available?

[Friedrich W. H. Kossebau]

Hi,

(cc:kde-core-devel only for heads-up, any reply please only to kde-devel)

TL;DR  Would you fancy not having to always explicitly include a version 
header of a KFoo module to have the KFOO_VERSION variable available in your 
code? So is it worth it to add support for that on the KF side?
(KF6-only, to keep your KF5 experience consistent)

See for some discussion the description of
https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/310

Please voice your opinion on the use-case (not the implementation) either in 
that MR as comment or as reply in the ML.

To adapt to the new use-case, two new feature variants of related ECM macros 
are currently up for consideration:
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/337
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/341

Again curious which variant people might prefer in case they also work on 
public libraries, e.g. if there are other use-cases for the generic approach 
in 337 with the INCLUDE_FILES argument. Personally tend for 341 right now.


Personal motivation:

One of the things that annoyed me a bit with using KDE Frameworks over the 
last years was this:
if one wanted to query what API is available (by using the *_VERSION value as 
reference), one always had to explicitly include the respective version 
header. And then also remember to again remove the include once no longer 
needed.
For one this cluttered the list of includes a bit and was extra work. But more 
annoying has been to me that one often forgot the version header include, even 
more when copy & pasting some version-based code around, and only finding out 
the hard way when compiling or digesting any editor parsing error 
highlighting.
This developer experience differs from most of the other libraries one uses 
(most prominently Qt), so the need for the explicit include first has to be 
remembered, and in comparison also comes across with bigger developer work 
costs.

Grepping through the list of headers of non-KF libraries on my system, it 
seems:
* half of them do not even have separate version headers but instead have the
  version (also visibility/export) macros defined in generic global headers
  which are either the central header to include by consumers or indirectly
  included by all other headers
* the other have separate version headers, but roughly half of those again
  include the version header in some generic global headers, which again
  either directly or indirectly included by consumers

So in KF modules without changing the current structure of separate headers, 
but still having the version macros available implicitly when including a 
public class header, a solution, as proposed in the MRs, is to modify the 
export headers to transitively include the related version header. It seems 
like a least invasive change to achieve the desired.

And given KF API is used together with lots of Qt API, having a more similar 
developer experience here makes having that also more appealing.

Still, it needs a tad of adaption on the KF side and adds a tad of complexity, 
so it would be good to know if a good portion of consumers think the new 
behaviour is welcome, thus worth it.

As a reference point, right now on master branches of KDE projects there are 
up to 699 includes that would no longer be needed (should be only a few wrong 
hits):
https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C_version%5C.h%5C%3E&_casesensitive=1

And there are many includes which have come and gone before.

What do you think?

Cheers
Friedrich

PS: Yes, in some case one will still have to include the version header as 
before, like when deciding which single class header to include and no other 
header was yet included that provided the macro. But that is the case with any 
variant.

PPS: Again, cc:kde-core-devel only for heads-up, any reply please only to kde-
devel :)