There were numerous small issues with test cases:

- some lacked the right source file header
- some were not portable at all
- some were using internal libzmq APIs (headers)

Solution: fixed and cleaned up.

Solution: document the minimum rules in README.md

Solution: offer a build.bat to help the user.

Making gyp builds work

Solution: it's a lot of work to define the tests in project.gyp
so I did this using gsl to generate the JSON, from a small XML
list of the test cases.

To keep this, and the hundreds of .mk files, away from the root
directory, I've moved the gyp files into builds/gyp, where you
would run them.

It all seems to work now. Next up, OS/X and Windows :)

Doesn't affect building, just potentially confusing.

Solution: fix it.

It's all over the place.

Solution: remove duplicates and try to move main includes to start
of source. Also, include net/if.h always, so that the code will
compile if ZMQ_HAVE_IFADDRS isn't defined.

This is rather insane since the code knows well enough what systems
support if_nametoindex. I blame this on over-use of autotools early
in libzmq's days.

Anyhow, this breaks gyp builds on OS/X.

Solution: add ZMQ_HAVE_IFADDRS to build/gyp/platform.hpp for OS/X.

Getting gyp build working

Solution: add necessary macros into builds/gyp/platform.hpp

Work for Linux now, other platforms to test.

Problem: CI use of sodium or nacl is confusing

Solution: establish a matrix of CI options. On one axis we have the
build system (autotools, cmake, android) and on the other axis we
have the encryption options (tweetnacl, libsodium or none).

Problem: typo in CMake platform.hpp breaks build

Solution: use ZMQ_USE_TWEETNACL as a define as expected instead of
HAVE_TWEETNACL

I'm adding gyp support so that we can easily pull in libzmq
and other C/C++ projects into gyp packages, especially via
node-gyp.

Solution: add gyp definition

This works only for Windows, OS/X, and Linux. We set a single
macro in project.gyp according to the system, and the rest is
done in builds/gyp/platform.hpp. The values in that file are
not dynamic. Your mileage will vary.

Problem: CI is borken

Solution: if not building with tweetnacl, do not include its sources
in Makefile.am. CMake already includes them optionally.

Solution: must be upper case

Solution: check for WITH_LIBSODIUM configure option instead of
WITH_SODIUM

Solution: set the curve_library variable to the expected value if
libsodium is selected

Solution: avoid cloning libsodium, default build is tweetnacl

Solution: checkout stable branch before building

Solution: build by default with tweetnacl, and add sub-build project
to test libsodium

Problem: tweetnacl sources are a mess

- they have no copyright / license statement
- they are in some randomish directory structure
- they are a mix of postable and non-portable files
- they do not conform to conditional compile environment

Overall, it makes it rather more work than needed, in build scripts.

Solution: clean up tweetnacl sauce.

- merged code into single tweetnacl.c and .h
- standard copyright header, DJB to AUTHORS
- moved into src/ along with all other source files
- all system and conditional compilation hidden in these files
- thus, they can be compiled and packaged in all cases
- ZMQ_USE_TWEETNACL is set when we're using built-in tweetnacl
- HAVE_LIBSODIUM is set when we're using external libsodium

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'.

Problem: old filenames in .gitignore

Problem: autotools platform.hpp is not compatible with CMake

Solution: remove them

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.

Problem: use of libsodium vs. tweetnacl is confused

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.