FS#71849 - [capnproto] executables do not report version correctly
Attached to Project:
Community Packages
Opened by nyanpasu64 (nyanpasu64) - Monday, 16 August 2021, 15:23 GMT
Last edited by David Thurstenson (thurstylark) - Sunday, 01 May 2022, 14:33 GMT
Opened by nyanpasu64 (nyanpasu64) - Monday, 16 August 2021, 15:23 GMT
Last edited by David Thurstenson (thurstylark) - Sunday, 01 May 2022, 14:33 GMT
|
Details
Description:
Currently, running `capnp[c] --version` on Arch Linux (both the current 0.8.0 and my self-built 0.9.0 package) prints "Cap'n Proto version (unknown)". According to upstream, this bug only occurs in CMake and not Autotools (though it will probably be fixed), and Arch Linux should switch to Autotools instead of CMake for building capnproto. Is this going to be done or not? (Personally I don't see a problem with building with CMake and use CMake to build my vendored capnproto, but perhaps it's more likely to break on updates.) Additional info: * Message from upstream: https://github.com/capnproto/capnproto/pull/1306#issuecomment-899534792 |
This task depends upon
Closed by David Thurstenson (thurstylark)
Sunday, 01 May 2022, 14:33 GMT
Reason for closing: No response
Sunday, 01 May 2022, 14:33 GMT
Reason for closing: No response
As you seem to have provided an upstream fix, I don't think there is much to do but to wait until they release a new version including that fix.
The pkgconfig and cmake integration seem fine. Are there any harmful side effects if the capnp* executables return a non valid version in their --version output?
I don't think it's a big deal, other than being confusing to users. Perhaps it breaks some scripts that check the version number, but if nobody has reported it yet it shouldn't matter.
With this bug fixed, do you plan to switch to autotools (because upstream treats it as their "official" build system) or keep the CMake-based PKGBUILD as-is?