Solution: set default to bionic, and leave a few jobs that manually
set Trusty/Xenial to have more coverage
This is especially useful to get newer gcc for address sanitizer support
Solution: if the compiler supports it, pass C++98-compat flags.
Currently Clang supports this flag but GCC does not.
Add a new flag to enable it, as building with C++98-compat but also
with -std=gnu++11 will cause a lot of warnings due to the backward
compat ifdefs.
Add a CI job to run it and ensure we don't break compatibility.
* always run tests from tarball of `make dist`
ensures that tests will not pass if critical files are omitted from releases
* add explicit make dist only for non-default builds
distcheck should already cover this for default builds
* don’t verify that valgrind/coverage tests can be run from dists
* add various files missing from dists
- missing template from cmake
- add missing android build files
- add some missing ci_build.sh scripts
* Problem: TIPC availability check is too strict
Solution: at build time only check if the API is available. In the tests
do a first check and a skip if the functionality is not available.
TIPC needs an in-tree but not loaded by default kernel module, tipc.ko
to be loaded, which requires root, so it is unlikely to be available on
any build system by default.
This will allow most distributions to ship with TIPC support built in,
and to avoid tests failure if the module is not there.
* Problem: no Travis tests for TIPC
Solution: mark one job with sudo: required and load the kernel module
* Problem: CMake fails when test returns 77 (skip)
Solution: set property to let it mark the test as skipped as intended
* Problem: build failure with select as polling mechanism
Solution: cast mailbox_handle argument to (poller_t::handle_t) like in
the reaper thread class.
* Problem: build failure due to INT_MAX use without include
Solution: include limits and climits in src/select.cpp where INT_MAX is
used
* Problem: build failure due to unused variable in select.cpp
Solution: move the declaration of int rc inside the ifdef block where
it is actually used
* Problem: reference to wrong variable in select.cpp breaks build
Solution: fix it
* Problem: family_entry_t constructor has no body, build fails on *nix
Solution: add empty inline function in the struct
* Problem: no test coverage for poll and select
Solution: add Travis jobs for them on Linux
* Problem: Travis jobs cannot run in container infra
Solution: set sudo: false as it is not required anymore
Solution: add a CI build run with GCC's Address Sanitizer enabled.
This compiler flag will make the unit test programs abort if it
detects errors such as out-of-bound memory access or use-after-free.
Solution: use packages on Ubuntu and brews on OSX. The packages and
the brews are always kept up to date, so it's no use to rebuild the
libsodium stable branch manually everytime.
Solution: Use travis to deploy these artifacts automatically.
The deployment is triggered by tagging on the zeromq/libzmq repository.
Of the many builds travis is checking only the default one with
libsodium and drafts disabled is used for deployment.
For now the results of `make distcheck` are deployed as well as their
md5 and sha1 hash sums. Further changes may upload a generated
Changelog as well.
Solution: run make dist-check, which will run additional tests,
including making sure that the library is installable and the
distributable tarball is buildable, along with the usual make and
make check.
Solution: simply run make VERBOSE=1 check instead of manually
checking for return value and cat'ing the log file. With VERBOSE, on
error the log file will be automatically printed.
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).
Solution: checkout stable branch instead.
Several warnings are printed when building from the master branch,
and developers recommend using the stable branch instead.
Currently, a test fails on Travis-CI but that can not be reproduced locally.
Without the contents of the test-suite.log, this is difficult to analyze.
Solution: print test-suite.log if "make check" fails
This is based on the following answer on SO:
http://stackoverflow.com/a/32597140
