Also squashed:
config: add log messages to set_algo() and set_nfactor().
algorithm: use set_algorithm_nfactor() when setting default nfactor in set_algorithm().
Otherwise algorithm->n defaults to 0.
P.S. Did I already mention how this could have been C++?..
Had two bugs:
1. Will not compile due to unknown algorithm_t size.
2. nfactor is set to 0 (bad calling, fix later).
So squashed two commits:
1. algorithm: move algorithm_t definition to header.
2. config: if --nfactor is specified, properly set algorithm->nfactor.
Doc in `doc/configuration.md` (has to be started sometime, no?).
Configuration function has to be lamely-named set_algo(), because
set_algorithm() is already declared in algorithm.h (prevent namespace
conflict).
algorithm has to be added as global variable due to the way the
callback is done (by CCAN/opt, which in itself is nice).
This can be cleaned up significantly by (at least) introducing a
global configuration struct, but there is no reason to do it now
just for this - better a wholesale manana.
The config parser has a bug, and can only set boolean options to
non-default state. If a default state is given to an OPT_WITHOUT_ARG
option (as defined in the config table), it is set to the non-default state
anyway, because a CCAN function opt_set_[inv]bool() is used, which is not
meant for this.
Therefore, using such options from the command line is fine, but specifying
them in the .conf file results in above-described behaviour.
E.g., a user tests
"api-listen" : true
in the config, but changes it later to
"api-listen" : false
The option will be set true anyway.
A previous commit (8dd1c2d4af) has allowed
this, whereas previously only setting to true was allowed.
Currently boolead options that default to true and can be set false by
the user are explicitly defined as true, e.g.:
bool opt_restart = true;
There is no simple or right way around this. This is an issue with the
design.