When cross compiling it's important that the resulting config.h reflects the platform we are building for and not the one we are building on.
Otherwise we end up with a config.h that defines headers that are not there on the target platform, wrong endnianness and so on.
The -static flag is there to be able to easily run the configurator test executables on the build machine with qemu-*.
E.g. Without the -static flag the resulting dynamically linked ARM executables complain about the lack of linker (/lib/ld-linux-armhf.so or /system/bin/linker for Android), since these files are not usually available on the build machine building statically avoids this problem and results in a proper config.h for cross compiling.
This doesn't cover external libs in general (which *could* be effected by
CFLAGS), but at least all our own objects are rebuilt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Adds two new environment variables TEST_GROUP_COUNT and TEST_GROUP to
split the integration tests into groups and run only a selected group.
This allows us to increase the TEST_GROUP_COUNT and add a new
TEST_GROUP to avoid bumping up against the time limit when running in
valgrind.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The py.test unit test runner offers a number of more advanced features
than simply running using unittest.main. In particular it allows us to
capture a tests output and print it if it fails. This change checks
whether we have pytest available and if yes, enables verbose tests and
runs using pytest. This'll give the usual experience (with colors!)
and show us the stdout if a test fails making travis a lot easier to
handle.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
And nail "make check-source" to that specific version (which is a commit id,
not a branch name, so needs a different syntax for git).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a bit messier than I'd like, but we want to clearly remove all
dev code (not just have it uncalled), so we remove fields and functions
altogether rather than stub them out. This means we put #ifdefs in callers
in some places, but at least it's explicit.
We still run tests, but only a subset, and we run with NO_VALGRIND under
Travis to avoid increasing test times too much.
See-also: #176
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
update-mocks was broken, since it assumed the daemon/ directory.
We now use "make" directly to build the test file and harvest errors,
and are more robust if it simply doesn't compile (ie. fails, but no
linker errors).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You will want to 'make distclean' after this.
I also removed libsecp; we use the one in in libwally anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Also, we split the more sophisticated json_add helpers to avoid pulling in
everything into lightning-cli, and unify the routines to print struct
short_channel_id (it's ':', not '/' too).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To avoid everything pulling in HTLCs stuff to the opening daemon, we
split the channel and commit_tx routines into initial_channel and
initial_commit_tx (no HTLC support) and move full HTLC supporting versions
into channeld.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This moves all the non-legacy blackbox testing into python.
Before:
real 10m18.385s
After:
real 9m54.877s
Note that this doesn't valgrind the subdaemons: that patch seems to cause
some issues in the python framework which I am still chasing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The Dockerfile is now stored in contrib and built using the Docker
Hub. This allows us to simply pull in the finished image from the hub
instead of having to build it ourself. Should shave off about 2
minutes from the build time.
I also switched to running the individual build and check steps in
their own containers, but on the same volume, so travis can group the
commands and run them independently.
libwally's tools/cleanup.sh doesn't actually remove files if it can't
run make, so do that manually. Also clear some other cruft.
Also, we weren't deleting wire/gen_onion_wire.c in "make clean".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We had a hack for 'struct rval' in protobuf_convert.h; make an
explicit header and put it in bitcoin/preimage.h. It's not really
bitcoin-specific, but it's better than having bitcoin/script depend on
an external header.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can't run them in parallel, but we can at least have 'make check'
run them all.
Developers should be running "make check-source && make check".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The API formalizes how daemons should report their statuses back to
the main lightningd. It's a simple write API, which includes tracing
support (currently it always sends traces, later it could send iff
there's a failure, for example).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Setting the environment variable `COVERAGE=1` allows us to turn
coverage measurements on. This produces a number of auxiliary gcno and
gcda files which can then be converted into coverage reports.
I know line coverage and branch coverage is not a perfect metric, but
it might get us some more visibility into where more tests might be
needed.
The object file should not be built inside the submodule, as that can
confuse git.
Not everything depends on the libbase58 header (CCAN doesn't), so
move that to the everything-else depends line.
The BITCOIN_SRC etc should also move to bitcoin/Makefile, but that's
a bigger change.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
