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
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.
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.
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: 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: 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.
used static_cast<signed int> around WSA_WAIT_FAILED as it is an unsigned implicitly defined as (0xFFFFFFFF ion winbase.h) and causes a comparison error.
removed use of c++11 style initialiser list for 'sockaddr addr { 0 }' and changed it to 'sockaddr addr = { 0 }'
Solution: checkout stable branch instead.
Several warnings are printed when building from the master branch,
and developers recommend using the stable branch instead.
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.
Solution: when iterating over a map and conditionally deleting
elements, an erased iterator gets invalidated. Call erase using postfix
increment on iterator to avoid using an invalid element in the next
iteration.
Solution: parse the value set by the ZMQ_PRE_ALLOCATED_FD sockopt
when creating a new TCP socket and use it if valid.
Add new tests/test_pre_allocated_fd_tcp.cpp unit test.
Solution: parse the value set by the ZMQ_PRE_ALLOCATED_FD sockopt
when creating a new IPC socket and use it if valid.
Add new tests/test_pre_allocated_fd_ipc.cpp unit test.
Solution: add new [set|get]sockopt ZMQ_PRE_ALLOCATED_FD to allow
users to let ZMQ use a pre-allocated file descriptor instead of
allocating a new one. Update [set|get]sockopt documentation and
test accordingly.
The main use case for this feature is a socket-activated systemd
service. For more information about this feature see:
http://0pointer.de/blog/projects/socket-activation.html
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.)
select was improved to support multiple service providers on Windows.
it should be slightly faster because of optimized iteration
over selected sockets.
