About the pyzmq breakage

So when we released zeromq 4.2.3 , it broke the pyzmq conda package (on default and conda-forge), which depended on zeromq 4.2*. The reason is that with the way pyzmq is built, it tries to explicitly load libzmq.so.4.2.1, 4.2.1 being the version it was built against.

Looking at the build results for zeromq with and without cmake in 4.2.1 and 4.2.3, our understanding is that the same breakage for pyzmq would have occurred with pkg-config as with cmake.

With cmake

zeromq 4.2.1

zeromq 4.2.3

Without cmake

zeromq 4.2.1

zeromq 4.2.3

So, with the way pyzmq is currently built, my understanding is that the runtime version should be pinned to the version it was linked with at build time. Since conda has no means of doing so, we simply pinned it at both runtime and build time.

cmake versus configure+ make

• We also often get frustrated with cmake, but for the C++ community, CMake has clearly won and everyone is moving to it now. It is not perfect, documentation is not always great, but we don't think new projects should be using anything else if they have dependencies or intend to be used by other projects... Even boost libraries, which had their own build system for years announced that they were moving to CMake last summer http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Committee-tt4696934.html

• Even within the zeromq GitHub organization, other projects are relying on zeromq being presumably built with cmake, such as cppzmq, azmq, the lua bindings and others.

• The entire xeus stack now relies on the same.

• Generating the cmake build artefacts (projectConfig.cmake, projectConfigVersion.cmake and projectTargets.cmake) from a autotools build would be very cumbersome, especially for the Targets file which is platform-specific and lengthy.

For these reasons, we are -1 on the proposed use of autotools+make for Unix platforms by @minrk #20. If we find issues with the cmake build, we think that it is preferable to fix them than to roll back to the previous build method.

cc @isuruf @ocefpaf

-- Sylvain & Johan