.travis: Fix installation of non-stock cppzmq

[t-b]

In 86174eea (Travis Tests: Avoid code duplication, 2019-06-05) we added
support for using the environment variable NON_STOCK_CPPZMQ to say if we
use the stock version or the non-stock version.

That commit got the logic wrong. Flip the naming to have now one less
negation.

STOCK_CPPZMQ=ON means that the system cppzmq is used, =OFF that we use
the latest cppzmq from the repo.

(Adapted from fedback in #598 (comment))

[bourtemb]

In 4b5128f (zmqeventconsumer/zmqeventsupplier: Make it compatible with
all stock cppzmq versions, 2019-06-05) we added support for using the
environment variable NON_STOCK_CPPZMQ to say if we use the stock version
or the non-stock version.

That commit got the logic wrong. Flip the naming to have now one less
negation

To be fair, NON_STOCK_CPPZMQ was added in 86174ee and the logic simply reproduced what we had before where we were installing a custom cppzmq version on all Debian versions except Debian 8 which was already coming with a compatible zmq.hpp

In the mean time, the compilation issue when using these different zmq.hpp files versions got fixed, so I think it is a good idea to do the tests with the zmq.hpp file coming from the Debian distribution.
For Debian 8, we know it used to work with the default zmq.hpp file coming with Debian 8, so why not trying with a more recent cppzmq version...?
This is what this PR is proposing.

[t-b]

@bourtemb Thx. I've corrected the referenced commit.

[t-b]

The wheezy build fails with the stock cppzmq.

The version check for the zmq socket having the disconnect method is wrong. It currently reads

#ifdef ZMQ_VERSION
	#if ZMQ_VERSION > 30201
		#define ZMQ_HAS_DISCONNECT
	#endif
#endif

but this check the libzmq version and not the cppzmq version. A proper solution would be to instead of checking the version checking the existance of the method in cmake and set the define from that. Or just use a non-stock cppzmq for wheezy.

[bourtemb]

but this check the libzmq version and not the cppzmq version. A proper solution would be to instead of checking the version checking the existance of the method in cmake and set the define from that.

I agree this would be the cleanest. Could you please do that?

[t-b]

@bourtemb I've added a feature check for zmq::socket::disconnect. I'm only doing that on non-windows platforms, as windows should be unproblematic. Let's see what CI says.

[t-b]

@bourtemb Wheezy now builds with stock cppzmq.

[bourtemb]

Thanks for the fix.
This will fix the problem of someone compiling cppTango with CMake and using an old version of zmq.hpp.

For the Tango source distribution, we are still using the autotools. We are in a strange situation where CMake is actually used to generate some files (ant build package command to build the source distribution package) which are provided with the source distribution tar file. tango_const.h is one of these files.
So if the source distribution package is built from a computer where zmq.hpp does support zmq::socket::disconnect and then someone uses this generated package on a computer where zmq.hpp does not support zmq::socket::disconnect, there will still be some compilation problems for this person.

I think we may have to do something on the autoconf side to make it work for this use case, or we should provide a different package version, or instructions for the persons using an old version of zmq.hpp file, or a configure flag, ...?

There is a plan in the future to use CMake instead of configure to compile cpptango in the source distribution provided to the users.

[t-b]

think we may have to do something on the autoconf side to make it work for this use case, or we should provide a different package version, or instructions for the persons using an old version of zmq.hpp file, or a configure flag, ...?

I'll find a autoconf version as well.

[t-b]

I did some research and I think we don't need to do anything.

In the tango source distribution configure.ac file https://github.com/tango-controls/TangoSourceDistribution/blob/8a63f208b27c6cec36b76a24cdc02b673804da25/assets/configure.ac#L194

we require libzmq >=4.05. This is the version which was shipped with debian jessie (oldoldstable). And I just looked into that package and there zmq::socket_t::disconnect exists. According to https://docs.travis-ci.com/user/reference/linux#default travis uses ubuntu xenial by default so cmake (running on travis) and the user running ./configure will very very likely get the same results.

[bourtemb]

I did some research and I think we don't need to do anything.

In the tango source distribution configure.ac file https://github.com/tango-controls/TangoSourceDistribution/blob/8a63f208b27c6cec36b76a24cdc02b673804da25/assets/configure.ac#L194

we require libzmq >=4.05. This is the version which was shipped with debian jessie (oldoldstable). And I just looked into that package and there zmq::socket_t::disconnect exists.

Debian Jessie (Debian 8) is fine... And this exactly why we didn't need to install a recent version of cppzmq on Debian 8 travis tests.
We'll get some problems with Debian 7 (wheezy), which provided zmq 3.2.3 (libzmq3 package).
But if we require libzmq 4.0.5 in the configure as you noticed, then I think it's a good point because users who want to build latest source distribution on Debian 7 or older (there will probably be some), will already have to install a more recent version of libzmq.
The problem is that zmq.hpp file is not provided with libzmq when you install it manually from source.
Users will have to install as well cppzmq in order to get a correct zmq.hpp file, but they could do that, since they already had to install libzmq manually.
Maybe we can simply provide some support for these specific use cases and guide them?

According to https://docs.travis-ci.com/user/reference/linux#default travis uses ubuntu xenial by default so cmake (running on travis) and the user running ./configure will very very likely get the same results.

Not if the user is on an old debian 7 (or older) without the correct cppzmq... We can also consider it is his responsibility to get it right (or to use a more recent OS), but then we need to document it well.

I think there is something we can improve too in this PR. It is to avoid to clone cppzmq repository when STOCK_CPPZMQ=ON

[t-b]

I think there is something we can improve too in this PR. It is to avoid to clone cppzmq repository when STOCK_CPPZMQ=ON

Done.

Not if the user is on an old debian 7 (or older) without the correct cppzmq

I'll add an autotools check as well, see tango-controls/TangoSourceDistribution#54.

We can also consider it is his responsibility to get it right (or to use a more recent OS), but then we > need to document it well.

I've opened #606 to enhance the installation instructions.

[bourtemb]

Thanks! Looks good to me.