#239 Version 3.0.3 build fails with capnp > 0.6.0

[Giovanni Mariani]

Trying to build the program for Rosa Fresh R9 (aka Rosa 2016.1) on x86_64, using capnp 0.6.1.
The build process fails with an error about version mismatch from capnp binary and library (attached the full log); here is the relevant log snippet:

in file included from piper-cpp/vamp-capnp/VampnProto.h:35:0,
from piper-cpp/vamp-client/qt/../CapnpRRClient.h:45,
from piper-cpp/vamp-client/qt/PiperAutoPlugin.h:40,
from svcore/plugin/PiperVampPluginFactory.cpp:31:
piper-cpp/vamp-capnp/piper.capnp.h:10:2: error: #error "Version mismatch between generated > code and library headers. You must use the same version of the Cap'n Proto compiler and
library."

The culprit is in the lines below, form the file piper.capnp.h:

#if CAPNP_VERSION != 6000
#error "Version mismatch between generated code and library headers. You must use the same version of the Cap'n Proto compiler and library."
#endif
It test for a capnpn version not equal to 0.6.0, so the test will always fail for 0.6.1, even if this release is OK to be used.

Changing the test to #if CAPNP_VERSION < 6000 fixes the build...
until the next error (but this is another bug...).

[Luigi Baldoni]

This is my recipe with capnp 0.6.1:

pushd piper-cpp/vamp-capnp/
wget https://raw.githubusercontent.com/piper-audio/piper/02bafb5284eb20e4c8d96ac5fe5b697ed11f59a4/capnp/piper.capnp # this should be the version with which it was generated
capnp compile -oc++ piper.capnp
popd

From what I could tell it builds regularly, but please let me know if there are other problems.

[David Runge]

I have the same issue for packaging this for Arch Linux. Fumbling with old versions of capnproto is not an option, as I will have to adopt that package from the user repositories first to build sonic-visualizer and Arch being a rolling release... you get the point.

Please find a patch in attachment.

[Luigi Baldoni]

Sorry, but I don't think it's appropriate.
The warning is there for a reason: who guarantees you the format hasn't changed (or won't in the future)?

[Chris Cannam]

Yep, the right answer is to regenerate the header on each build. The current code in the repo does this, and so will the next point release of SV. My fault in the earlier releases.

[David Runge]

Alright, never mind the patch then. I fixed the build using recompiling now.
Thanks for the hint!

[Chris Cannam]

Should be rolled out properly in v3.1 now (and more recent repo code).

[Luigi Baldoni]

3.1 works for me.

[David Runge]

Same for me

[Giovanni Mariani]

Confirming: 3.1 builds fine as is...
This issue can be closed, then.

[Giovanni Mariani]

Now there is still issue #240 in my path...