RFC: KF (& other lib) consumers: want KFOO_VERSION macro definitions automagically available?
Friedrich W. H. Kossebau
kossebau at kde.org
Tue Feb 28 14:20:11 GMT 2023
(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
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:
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.
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
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
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
Grepping through the list of headers of non-KF libraries on my system, it
* 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
And there are many includes which have come and gone before.
What do you think?
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
PPS: Again, cc:kde-core-devel only for heads-up, any reply please only to kde-
More information about the kde-devel