This is the counterpart of the annotations we did in the last few commits. It
extracts queries, passes them through a driver-specific query rewriter and
dumps them into a driver-specific query-list, along with some metadata to
facilitate processing later on. The generated query list is then registered as
a `db_config` and will be loaded by the driver upon instantiation.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We were just telling GCC not to treat them as errors: this suppresses them
entirely unless at -O3. People keep trying to "fix" them, when in fact
they're false positives, as revealed with "./configure COPTFLAGS=-O3".
Fixes: #2856
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I noticed that DEVELOPER was being reset to 0 by ./configure --reconfigure;
that's because we set the defaults first, then --reconfigure would only
override *unset* vars. We now set up defaults last.
We unify all our "find the default" functions, to neaten them; in
particular find_pytest and our open-coded valgrind testing function.
We can figure out whether valgrind works using /bin/true instead of waiting
until configurator is built.
We're also more careful with ${FOO-default} vs ${FOO:-default}; the former
does not replace if FOO is set to the empty string, which is possible for
some of our settings (COPTFLAGS, CDEBUGFLAGS in particular).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Drive-by fix of CONFIGURATOR_CC setting when CC is overridden on cmdline
(not via env var).
Note that clang defines __GNUC__ (to 4) :(
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`./configure CC=newcc --reconfigure` didn't set CC, because reconfigure
simply replaced all values: only make it replace undefined values.
Also, it didn't change COPTFLAGS or CWARNFLAGS, even if they were previously
the defaults (eg. --reconfigure --enable-developer).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Unfortuntely we get spurious uninitialized variable warnings with
anything but -O3 or no optimization, so set default CWARNFLAGS
appropriately.
MCP bench results without optimization:
store_load_msec:28509-31001(29206.6+/-9.4e+02)
vsz_kb:580004-580016(580006+/-4.8)
store_rewrite_sec:11.640000-12.730000(11.908+/-0.41)
listnodes_sec:1.790000-1.880000(1.83+/-0.032)
listchannels_sec:21.180000-21.950000(21.476+/-0.27)
routing_sec:2.210000-11.160000(7.126+/-3.1)
peer_write_all_sec:36.270000-41.200000(38.168+/-1.9)
MCP bench with -Og: 22% speedup vs no optimization
store_load_msec:21963-23645(22841+/-6.6e+02)
vsz_kb:579916
store_rewrite_sec:10.080000-10.960000(10.456+/-0.3)
listnodes_sec:1.280000-1.390000(1.338+/-0.047)
listchannels_sec:14.770000-16.080000(15.518+/-0.46)
routing_sec:0.990000-6.660000(3.958+/-2.2)
peer_write_all_sec:29.950000-32.950000(31.138+/-1)
MCP bench with -O2: 31% speedup vs no optimization
store_load_msec:20713-22088(21505.6+/-4.8e+02)
vsz_kb:579928
store_rewrite_sec:9.570000-11.200000(10.192+/-0.54)
listnodes_sec:0.960000-1.090000(1.028+/-0.045)
listchannels_sec:10.400000-11.770000(11.012+/-0.48)
routing_sec:0.300000-3.140000(1.978+/-1.1)
peer_write_all_sec:28.980000-30.310000(29.572+/-0.44)
MCP bench with -O3 -flto: 36% speedup vs no optimization
store_load_msec:19616-20191(19862.6+/-1.9e+02)
vsz_kb:578452
store_rewrite_sec:8.980000-9.960000(9.55+/-0.32)
listnodes_sec:0.920000-1.910000(1.18+/-0.38)
listchannels_sec:8.960000-9.450000(9.206+/-0.16)
routing_sec:0.730000-1.850000(1.438+/-0.42)
peer_write_all_sec:28.090000-29.410000(28.772+/-0.42)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* remove libbase58, use base58 from libwally
This removes libbase58 and uses libwally instead.
It allocates and then frees some memory, we may want to
add a function in wally that doesn't or override
wally_operations to use tal.
Signed-off-by: Lawrence Nahum lawrence@greenaddress.it
The v1.0.9 release of libsodium added
crypto_aead_chacha20poly1305_ietf_NPUBBYTES which we use; before that it was
...IETF_NPUBBYTES.
Since that release was in April 2016, it seems fair to simply check for
ancient versions and use the internal one if found. The alternative would be
to use the older names (which are still in the header), but given we've never
tested with such old versions, this seems safer.
Reported-by: Zoltán Gálli <@gallizoltan>
Signed-off-by: Christian Decker <decker.christian@gmail.com>
== is bash-only; for other shells this gives an error (meaning that you won't
get the sanity check):
./configure
Compiling ccan/tools/configurator/configurator...done
./configure: 148: [: gcc: unexpected operator
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If you use use CC='gcc <options>' this blocks ASAN. Of course, no
check is perfect, but this catches the obvious misuse still.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Also one less headache for reproducible builds. But unlike
libsodium, this only seems common in Ubuntu.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we are planning to release a bug fix release, and the plugin
subsystem is not yet complete, it is better to make plugin support
opt-in while we continue testing.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Installing pytest through pip3 (at least sometimes) doesn't create a script.
This means calling `which` won't work.
Changed configure so that it can also test if the module is present by calling python/python3.
Change the error message for when pytest can't be found, so that it's clear to the user `configure` must be ran again after installing pytest.
Addresses #486 and takes into account @rustyrussell 's
comment about PYTEST defined in the environment which
always overrides without checking the version.
You can use environment variables or the commandline to set defaults.
It looks very autoconf, but you don't need to learn m4.
Doesn't cover all the obscure flags, but it's easy to extend.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>