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

[Friedrich W. H. Kossebau]

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

Am Dienstag, 28. Februar 2023, 15:20:11 CET schrieb Friedrich W. H. Kossebau:
> 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.

Thank you who took the time to give feedback so far :)

Seems having the *_VERSION macros implicitly available would be favoured by at 
least some others than me, so I have continued work on the matter and locally 
test-applied this to all KF6 modules and some other libraries.

Which as side-effect resulted already in some additions of missing version 
header installations as well as include dir layout clean-ups with KF6 :)

Now some bits for those interested on the implementation side:

The current state of the proposed solution, using ECM MR 341 
("ECMGenerateExportHeader: add USE_VERSION_HEADER arg (& related tune args)"), 
requires for each library in ideal situations only this additional flag (by 
example of KCoreAddons):

--- 8< ---
 ecm_generate_export_header(KF6CoreAddons
+    USE_VERSION_HEADER
 )
--- 8< ---

And as result includes like "#include <KPluginMetaData>" will make all version 
macros like "KCOREADDONS_VERSION" from kcoreaddons_version.h available without 
further work.

For multi-library KF modules, where the module version header will then differ 
in the base name from (most) library base names, an additional argument is 
needed (by example of KIO's KIOCore):
--- 8< ---
 ecm_generate_export_header(KF6KIOCore
+    USE_VERSION_HEADER
+    VERSION_BASE_NAME KIO
 )
--- 8< ---

Additionally sometimes some adaption is needed in the internal buildsystem for 
the version header to be seen during the internal build.

All in all this seems acceptable to me as overhead.
(though someone someday should deduplicate all the cmake code in all the KF 
modules, so many patterns that shout "make me a central macro/function"...)

For non-KF libraries, which IMHO ideally also should support this developer 
experience in the Qt6/KF6-based world, and which currently see to support both 
Qt5 & Qt6 builds from the same branch and also cannot yet rely on latest ECM, 
possible code is like this (by example of KDEGames):
--- 8< ---
+if (QT_MAJOR_VERSION STREQUAL "5")
+    set(_generate_export_header_version_args)
+else()
+    # For Qt6/KF6 world transitively include the version header 
+    if(ECM_VERSION VERSION_LESS "5.105")
+        set(include_version_header_code "#include <kdegames_version.h>\n")
+        set(_generate_export_header_version_args CUSTOM_CONTENT_FROM_VARIABLE 
include_version_header_code)
+    else()
+        set(_generate_export_header_version_args USE_VERSION_HEADER)
+    endif()
+endif()
 ecm_generate_export_header(KF5KDEGames
+    ${_generate_export_header_version_args}
 )
--- 8< ---

This is the path I will continue in related MR in the next days/weeks,

So if you want to participate please comment on ECM MR 341 & KCoreAddons MR 
310.

(note to self: next time again use a phabricator task as central place for 
tracking feature development discussion)

Cheers
Friedrich

PS: Again, cc:kde-core-devel only for heads-up, any reply please only to kde- 
devel or, better, on the MRs :)