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: 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 :)
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.
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).
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.
- 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
Took me over 8 hours to track down the cause of bizarre link
errors when building with libsodium. The VS project files are
not simple things.
Note to self and other maintainers: when someone is obviously
out of their depth, do not merge their changes to build scripts
without cynical appraisal.
Solution: undo the damage.
Caused by error in last commit which used HAVE_LIBSODIUM instead
of HAVE_SODIUM.
Solution: use HAVE_LIBSODIUM as we do in other configure scripts.
The project is called 'libsodium' and not 'sodium'.
There is an option to enable/disable libsodium via the Visual Studio
UI. This is not practical for command-line usage (via msbuild).
Solution: add configure.bat that searches for libsodium in sibling
directory to libzmq; if it finds it, defines HAVE_LIBSODIUM 1.
This is consistent with zproject, which has the same problem and
is getting the same solution for all dependency resolution on
Windows.
Note that this approach also provides a way to support tweetnacl
via a configure option.
Also, removed duplicate props files and re-copy in configure.bat
as it was an insane nightmare to update these by hand. (and not
clear that they were identical. Now it's forced.)
I hope restoring this from a previous version doesn't do any damage, it
is missing in the current version of this repository and is vital for
the lib to compile anywhere.
Solution: specify the necessary EXTRA_DIST
I added a Makefile.am in builds that covers all systems except msvc,
which already has a Makefile.am that does this.
Fixes#1505
