Add a header with the version of xkbcommon

[wismill]

Currently there is no easy way to universally check the version of xkbcommon.

Make clear we use the semantic version schema MAJOR.MINOR.PATCH and add an auto-generated header version.h that provide the following macros:

• XKBCOMMON_VERSION_MAJOR: MAJOR version component
• XKBCOMMON_VERSION_MINOR: MINOR version component
• XKBCOMMON_VERSION_PATCH: PATCH version component
• XKBCOMMON_VERSION(a, b, c): create a version number from its components
• XKBCOMMON_VERSION_NUMBER: version as a number, e.g. 1.6.0 is transformed into 0x010600. Intended use example: #if XKBCOMMON_VERSION_NUMBER >= XKBCOMMON_VERSION(1,7,0)
• XKBCOMMON_VERSION_STR: version as a string

[bluetech]

@whot had previously argued against something similar: #172 (comment)

[wismill]

Thanks for the pointer. It is a bit different though: here it is meant to do checks at compile time. The use case appeared in #398: I want to check my implementation in Qt but faced the impossibility to check enum values definition with macros, in order to support older version of the lib.

[whot]

Somewhat of the same downsides though, e.g. if I backport your patch(es) to Fedora's packages, Qt would continue to assume it doesn't exist because it doesn't check if the functionality exists, just the version number.

faced the impossibility to check enum values definition with macros, in order to support older version of the lib.

I only know how to do this with meson, but you'd use something like:

cc = meson.get_compiler('c')
if cc.compiles('''#include <xkbcommon.h>
                  int foo = MY_ENUM_VALUE;''')
   ... do something here ...
endif

See the meson reference manual. Other build systems have the same, just less conveniently to invoke :)

[wismill]

if I backport your patch(es) to Fedora's packages

@whot I do not think backporting a feature without changing the major/minor version is a good idea anyway, is it ?

Qt would continue to assume it doesn't exist because it doesn't check if the functionality exists

I agree: my previous version introduced a XKB_HAS_FEATURE_XXX macro style. But somehow it felt not right to me. Maybe it is still the best solution?

I did not know the trick with meson, thank you! It seems a bit convoluted to me and add non negligible amount of code in already complex build code. I will have a look to see if Qt already uses something similar though.

I think a good compromise could be a macro #define XKB_COMPOSE_OVERLAPPING_SEQUENCES_API 1: if not defined, there is no support. If defined, we may also increase the number in the future to support other related features/alternative implementations.

Just sharing some idea. It would be nice to adopt a recommended practice (you know better than me) and use it throughout the code base.

[whot]

@whot I do not think backporting a feature without changing the major/minor version is a good idea anyway, is it ?

lemme introduce you to long-term stable distributions :P doesn't happen that often in Fedora, more commonly in RHEL (especially in the kernel). I guess my point is more that version numbers only work reliably where you can assume fast-moving consumer stack (like npm) but not where you have a library that you may have to hack up to support multiple years/decades of different applications. Backporting a single feature can be worthwhile in larger code-bases where you don't want the risk of pulling in hundreds of patches from a new release just to get access to a new small thing.

I agree: my previous version introduced a XKB_HAS_FEATURE_XXX macro style. But somehow it felt not right to me. Maybe it is still the best solution?

I think a good compromise could be a macro #define XKB_COMPOSE_OVERLAPPING_SEQUENCES_API 1:

the issue with both of these is that you're shifting the effort from the ones who need to consume the new feature to yourself. But the ones that consume the feature are the ones who know what exactly they need. You (as in libxkbcommon) don't know how they use it so those defines are basically just putting things out there in the hope they're useful. And even if they're not you're now stuck with maintaining them forever.

make Qt check for features if Qt wants to use a specific feature. They'll know how.

input-leap's libei support uses CMake's check_symbol_exists for looking up library symbols. Maybe that's a starting point for figuring out the CMake magic for this.

[wismill]

@whot Thank you for the detailed explanation. I gave it a try in a Qt MR.

In the Haskell world we rely much more on semantic versioning. But even there, there might be people backporting features and breaking semantic versioning. I wonder how they handle this.