Problem: czmqpp uses deprecated CZMQ APIs

[bluca]

The CZMQ v2 APIs have been declared deprecated with the 3.0.0 release in October 2014: https://github.com/zeromq/czmq#toc3-8224

Following the C4.1 process we are moving toward retiring those APIs - i.e. deleting them. This will break czmqpp.

The solution would be to update czmqpp to use the new v3 APIs from CZMQ.

[evoskuil]

We (libbitcoin) are no longer using czmqpp. We have built up abstractions directly over zeromq. We originally created the czmqpp library and have done some maintenance work on it. But given that we are no longer using it and it doesn't appear to have much of a user base I recommend deprecating it altogether.

In the mean time our version2 branches break with the latest czmq changes. Given we aren't using czmqpp going forward, it makes sense for us to just freeze the czmq dependency in our version2 builds. This would be very trivial for us to do if there was a czmq v3 github branch to build against (our builds don't target commits or tags, just the top of a branch).

It looks like czmq doesn't maintain anything but master. If that's a limitation I think we'll just fork it and set a branch for our installer and document the v3 requirement.

Sorry I haven't been very active with czmq, but now you know why. We are very committed to libzmq and make heavy use of GSL as well. Did we ever get a GSL maintainer, or should we fork the repo at some point?

[bluca]

Any reason why the CI can't target the tag or commit of 3.0.2? It's git after all:

git clone --depth 1 -b v3.0.2 https://github.com/zeromq/czmq.git

[evoskuil]

It's just the way the (generated) installer works. We have a system of 10 repos that use the same build artifact generation system (11th repo). It's similar in concept to zproject, but in some ways more generalized. We made a decision to have the installers always build from branches so that we would fail fast when dependencies introduced breaks. This has worked well, but it obviously makes an assumption about branching interface changes.

Generally if we build from repos it means we want latest, otherwise we would target release tarballs (as we do with boost, icu, png, qrcode, zlib). We went with latest in limzmq (and originally czmq) because we wanted some latest features - but these are now shipped in v3/v4. It may make sense for us to convert both to tarballs at this point.

[evoskuil]

I've almost got it working with tarballs for both zeromq and czmq. Is there a reason that czmq doesn't ship with an autogen.sh file?

[evoskuil]

With one exception I've got everything working building zeromq and czmq from current tarballs (though it would be easier if czmq also shipped with an autogen.sh).

The zeromq install fails when using a prefix directory and a non-sudo build, because of docs installation. Is there any way to either get docs to honor the directory or to not install them? I don't see any switch.

[bluca]

CZMQ should definitely ship the autogen.sh, if it doesn't it's a bug. If you use a script, as a workaround you could check if autogen.sh exists and if not call manually autoreconf -fi -I config which is what that script does.

The docs also should respect the prefix, and that's another bug if they don't. Building using --without-docs should solve the immediate problem by avoiding building the docs entirely (also if it's a CI system you'll save some build time).

Please do open bugs for these issues so I don't forget, I'll get around to fix them this week if someone else doesn't beat me to it.

[bluca]

Thinking again at the autogen.sh, the point of a distributable tarball is that the autoconf stuff is already generated, to remove all that toolchain from the build dependencies. So it's just ready to call ./configure after unpacking it. If you have logic in an install script, I think perhaps that should be the correct way to handle tarball dependencies, just unpack and ./configure.

Of course shipping autogen.sh is not much trouble, just a line in Makefile.am I expect, and we can do it if you prefer.

[evoskuil]

My workaround was to do what you suggest, and just invoke reconfigure without the extra checks, which I applied generally to the tarball builds. Note however that zeromq does ship with autogen.sh.

I believe the docs issue arises from our need to use version 3.x, which appears to not allow a non-sudo install because of the docs. I'll create an issue for that.