xkbcommon
Add xkb_get_version()
Enable to apps to query the version of the libxkbcommon library actually in use and adapt their behavior: e.g. supported flags and available symbols, etc.
Fixes #932
TODO:
- [ ] Better commit message
- [ ] Documentation with examples (do and don’t)
- [ ] Changelog
- [ ] Add a flag arg to enable future developments?
@bluetech @whot See #932 for the rationale. My main reluctance for this function is that it can be abused or the app workaround get out of sync, while testing failures could be a more robust solution (e.g. unsupported flags[^1], etc.).
[^1]: Note that xkb_context_new() currently does not fail on invalid flags. Probably worth fixing.
I will go with symbol testing in the end for what I need. I see xkb_get_version as something useful only if functions like xkb_keymap_is_supported_format, xkb_context_is_flag_supported, etc. are missing for functionality that can't be probed through symbols or require e.g. constructing context+keymap+state to check whether something is supported.
Wayland allows requesting specific protocol versions, so I guess this would simplify some cases the same way it helps with protocol versioning in WL. But I agree now that it's bad to rely solely on version to handle all version differences in the library because that requires the app/bindings/wrapper to stay on top of all the changes to this library.
There's potential for misuse, but it could also pad omissions and mistakes. I suggest you mention in the docs "prefer other means (e.g. checking symbols) instead of relying solely on this value if possible".
historically libraries exporting a version made it hard(er) for backports like enterprise linuxes to work correctly - you can't backport a single feature without bumping the version number but then you have to backport every new API to be correct. Relying on build-time checks to check if a function exists and/or code compiles (for enums) is a better option than relying on some numbers.
Of course this only works at configure time, not dynamically. And libxkbcommon features aren't backported anywhere afaik but nonetheless, having the version number feels wrong.
Relying on build-time checks to check if a function exists and/or code compiles (for enums) is a better option than relying on some numbers.
This seem to be a popular sentiment in C-adjacent circles but people don't actually follow through on it and instead rely on compile-time version detection.
- https://gitlab.freedesktop.org/libinput/libinput/-/blob/38b5c2e0cc4aa0a705b45d1f7337231798479bd7/meson.build#L166
- https://gitlab.freedesktop.org/libinput/libinput/-/blob/38b5c2e0cc4aa0a705b45d1f7337231798479bd7/meson.build#L171-172
- https://gitlab.freedesktop.org/libinput/libinput/-/blob/38b5c2e0cc4aa0a705b45d1f7337231798479bd7/meson.build#L206
- https://gitlab.freedesktop.org/libinput/libinput/-/blob/38b5c2e0cc4aa0a705b45d1f7337231798479bd7/meson.build#L216
- https://gitlab.freedesktop.org/libinput/libinput/-/blob/38b5c2e0cc4aa0a705b45d1f7337231798479bd7/meson.build#L676
Given that these are all my fault :)
It's a mix and largely depends on how much effort I want to spend on versions that don't have those features. In the above examples: mtdev 1.1 is 15 years old and had some significant API changes back then. libwacom 0.27 is 8 years old and the only new required features are behind a function check. lua multiple versions is just a no-go, too much effort.
One counter-example for taking the checks to quite some extreme: https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/blob/master/meson.build?ref_type=heads#L48.
Version checks are still useful for a minimum supported version - it's anything after that minimum that should be dynamic is where they tend to break down (esp. where only a single feature is required).
Given that these are all my fault :)
It's a mix and largely depends on how much effort I want to spend on versions that don't have those features. In the above examples: mtdev 1.1 is 15 years old and had some significant API changes back then. libwacom 0.27 is 8 years old and the only new required features are behind a function check. lua multiple versions is just a no-go, too much effort.
It's nobodies fault, you're doing the thing that everyone should be doing in my opinion (and what everyone is doing in other languages where static linking is king). But it is hypocritical to do this and then say "having the version number feels wrong" when people who use dlopen want the same courtesy. People who link at compile time have strictly more tools available to do feature detection (within reason), and yet, you're saying that only they should get to use version numbers.
But maybe you're right. There is an easy way to prove it that also benefits everyone using dlopen: From now on, keep the pkg-config version of libinput fixed at 1.30.1. Distributions can still increment the package version number if they need to do so for technical reasons, but the pkg-config version stays fixed. Everyone who wants to use newer libinput features will have to check for their availability at runtime or at compile time with the same mechanism.