Catch2 fixes

[albestro]

I tried building via spack and I stumbled across a few building problems.
I started addressing them, even if I'm not an expert of CMake/Catch2/ZMQ, but I hope it is useful and it is in line with what you are trying to achieve. Otherwise, feel free to discard this PR.

Main points:

• Upgrade minimal CMake requirement to 3.11 (mainly for FetchContent)
• use Catch2: if a system installed one is not available, it fetches the specified tag from a git repository
• use Catch2 CMake targets ("CMake modern way"), as suggested in their doc
• use the new location for the header <catch2/catch.hpp>
• fix problem with CHECK_THROWS_AS as suggested in their doc

There still is a problem involving socket_ref and comparison operators, that I quickly workaround (not committed). I'll investigate further and in case I will open an issue to understand the best way to fix it.

[albestro]

There still is a problem involving socket_ref and comparison operators, that I quickly workaround (not committed). I'll investigate further and in case I will open an issue to understand the best way to fix it.

Ok, I've just narrowed down the problem. For socket_ref a set of comparison operators is defined (starting from here), moreover it is possible to implicitly cast a socket_t to a socket_ref thanks to

cppzmq/zmq.hpp

Line 2186 in 18db456

operator socket_ref() ZMQ_NOTHROW { return socket_ref(from_handle, _handle); }

so, it is possible to use these comparison operators with both types.

But with Catch a problem arose, because CHECK(sr == s) passes by const& the operands and the cast operator for const socket_t is not available.

Unfortunately, I'm not used to the API of the library, so I would have to dig a bit to understand what's better to do (e.g. enabling the socket_ref operator by adding const). I can commit this proposal, just to see if other problems will come up in CI.

I don't know if you want me to open an issue about this, or if we want to keep it here and solve it directly.

[sigiesec]

The provisioning of Catch is definitely not optimal, so thanks for taking care of this!

However, the Travis builds are failing because they only have CMake 3.9.5 (https://travis-ci.org/github/zeromq/cppzmq/jobs/752508762#L1321). In general, I think it would be ok to raise the minimum CMake version, if it can be made available there without increasing build times excessively. But this would need to be done as part of this PR, or in a separate PR that is merged before this. Could you give that a look?

The Windows builds are failing because of another problem, I think that's the one you mentioned.

[albestro]

However, the Travis builds are failing because they only have CMake 3.9.5 (https://travis-ci.org/github/zeromq/cppzmq/jobs/752508762#L1321). In general, I think it would be ok to raise the minimum CMake version, if it can be made available there without increasing build times excessively. But this would need to be done as part of this PR, or in a separate PR that is merged before this. Could you give that a look?

I never configured Travis, but I'm exploring what we can do. The easiest thing that should not change the time of building would be to upgrade images for linux and osx. I don't know if it is a viable solution or there is any major constraint.
In particular:

• for linux it would mean upgrading the base image from Trusty to at least Xenial (see https://docs.travis-ci.com/user/languages/c/#cmake)
• for osx it would mean, looking at this not official reference, upgrading from xcode9.1 to xcode9.4 or xcode10

Then the game would move to keeping the right compiler.

The alternative, AFAICT, for osx would be to manually build cmake, while for linux we can look for a repository/PPA that provides the right version.

In the meanwhile, as soon as I'll have enough time, I will try to run Travis on my local machine, so I can test different configurations more easily.

The Windows builds are failing because of another problem, I think that's the one you mentioned.

In order to address this, base on the #466 (comment), I would open a PR with a very basic proposal.

[gummif]

For the comparison I would suggest adding

inline bool operator==(socket_ref sr, const socket_t& s) ZMQ_NOTHROW
{
    return sr.handle() == s.handle();
}

(and !=, and socket vs socket_ref) instead of the const trick to keep everything as const correct as possible

[albestro]

TODO

• Rebase current branch for solving build problem with Catch2 (i.e. comparison operators) (waiting for Generalize arithmetic operators for socket_base and derived #470)
• Evaluate how to update CMake in Travis images

[albestro]

It was creating a problem because the folder was not there (if I get it correctly, %configuration% refers to the Visual Studio MS build) and it was failing the test.

I don't have any experience at all with AppVeyor, look forward your comments on how to fix this or it is ok like this (I don't know why it was needed and/or if it breaks anything in terms of AppVeyor build caches).

[albestro]

@gummif at least now, without this copy, all tests passed! 🎉

[gummif]

I find it strange that no tests are being run (see No tests were found!!! in the logs), it has been this way for at least a year, so that it unrelated to this PR.

[albestro]

Good catch, you're right! I will give it a look. I will open a dedicated PR for that, it is not strictly related to this one, but since this PR changes the test part, I think it would be worth fixing it before, so we can check that everything works also on Windows platform.

[gummif]

I wouldn't worry too much about it, I would like to move to github actions soon instead of travis/appveyor which should make managing the CI easier.

[albestro]

So, if you want to skip this problem on the windows CI, feel free to review the PR. On my side it should be ok.