It's especially annoying to see this:

  --enable-perf           Build performance measurement tools [default=yes].
  --disable-eventfd       disable eventfd [default=no]
  --enable-curve-keygen   Build curve key-generation tool [default=yes].

Solution: all options should explain the non-default case. Also
the language should be enable/disable, with/without, rather than
yes/no. E.g. '--without-docs'.

Specifically, the poller detection code does not set macros in
platform.hpp. The configure script passed them as -D on the command
line.

Solution: rewrite the poller detection code.

This happens if you first configure with autotools, and then run
cmake. The problem is that the compiler finds the old src/platform.hpp
before looking for the one generated by CMake. Further, there are a
set of macros that configure passes via the command line, yet CMake
passes via platform.hpp. (HAVE_xxx for pollers, at least.) This means
you can't do a CMake build using the autotools platform.hpp.

Solution: remove any src/platform.hpp when running cmake. This is a
workaround. I'll fix the inconsistent macros separately.

It's unclear which we need and in the source code, conditional code
treats tweetnacl as a subclass of libsodium, which is inaccurate.

Solution: redesign the configure/cmake API for this:

* tweetnacl is present by default and cannot be enabled
* libsodium can be enabled using --with-libsodium, which replaces
  the built-in tweetnacl
* CURVE encryption can be disabled entirely using --enable-curve=no

The macros we define in platform.hpp are:

    ZMQ_HAVE_CURVE    1        //  When CURVE is enabled
    HAVE_LIBSODIUM    1        //  When we are using libsodium
    HAVE_TWEETNACL    1        //  When we're using tweetnacl (default)

As of this patch, the default build of libzmq always has CURVE
security, and always uses tweetnacl.

Cleaning up recent option names

And I'm on a reasonably sized laptop. I think allocating INT_MAX
memory is dangerous in a test case.

Solution: expose this as a context option. I've used ZMQ_MAX_MSGSZ
and documented it and implemented the API. However I don't know how
to get the parent context for a socket, so the code in zmq.cpp is
still unfinished.

These options are confusing and redundant. Their names suggest
they apply to the tcp:// transport, yet they are used for all
stream protocols. The methods zmq::set_tcp_receive_buffer and
zmq::set_tcp_send_buffer don't use these values at all, they use
ZMQ_SNDBUF and ZMQ_RCVBUF.

Solution: merge these new options into ZMQ_SNDBUF and ZMQ_RCVBUF.

This means defaulting these two options to 8192, and removing the
new options. We now have ZMQ_SNDBUF and ZMQ_RCVBUF being used both
for TCP socket control, and for input/output buffering.

Note: the default for SNDBUF and RCVBUF are otherwise 4096.

The proper name is ZMQ_THREAD_SAFE

Solution: fix in the documentation.

This option has a few issues. The name is long and clumsy. The
functonality is not smooth: one must set both this and
ZMQ_XPUB_VERBOSE at the same time, or things will break mysteriously.

Solution: rename to ZMQ_XPUB_VERBOSER and make an atomic option.

That is, implicitly does ZMQ_XPUB_VERBOSE.

Solution: rename to ZMQ_MAXRT

This is the option name used on Windows, so easier to use and
remember.

Problem: ZMQ_USEFD does not follow conventions

Solution: rename socket option (and variables and files) from usefd
to use_fd.

Problem: ZMQ_PRE_ALLOCATED_FD is too long

Solution: rename socket option (and variables and files) from
pre_allocated_fd to usefd.

CMake and tweetnacl CI

Solution: add builds/cmake/ci_build.sh and call it from travis.yml

Solution: bump CMake required version to 2.8.12 to avoid:

CMake Error at tests/CMakeLists.txt:110 (target_include_directories):
  Unknown CMake command "target_include_directories".

Solution: add builds/tweetnacl/ci_build.sh and add it in travis.yml

Solution: disable -pedantic when building with tweetnacl to avoid
warning about "long long" not existing in ISO C++ 98

fallback on tweetnacl if libsodium is not found and not explicitly requested

allows building with tweetnacl without cmake

Fixes to Windows builds

Solution: fix these.

Solution: at least for vs2015, add vs2015/build.bat to work the
same was as zproject.

Fix a typo in "Add ZMTP heartbeats" changes

Change to detect POSIX Thread priority support properly

Use memcpy instead of assuming option values are aligned

Otherwise, it's undefined behavior. ubsan catches alignment issues in
the libzmq test suite without this.

Refinement of #f4fe375b

Solution: be more explicit in the code, and in the zmq_recv man
page (which is the most unobvious case). Assert if length is not
zero and buffer is nonetheless null.

There's no value in this as the same pattern is repeated in several
places and it's fair to expect people to understand it.

Solution: revert to the old, one-liner style.

It is poor style for test cases to use the internal API (i.e.
libzmq classes or header files), as this code serves the purpose
of teaching developers how to use the library (it doesn't do this
very well, it's an ambition).

Also, including headers in src/ creates problems when compiling.

Solution: remove use of src/macros.hpp.

Solution: update (with correct one from VS2015)

updates for bumped _WIN32_WINNT version with mingw builds

windows.hpp must be included first due to increases _WIN32_WINNT version

Don't call memcpy with 0 size and NULL pointer(s)

added conditional includes for unix / windows