Page MenuHomePhabricator

Better config/command line parameter handling
Open, Needs TriagePublic

Description

Currently the configuration handling in Bitcoin-ABC is very disparate and somewhat all over the place. We would like to setup a global configuration structure whereby config parameter data may be registered with a global configuration handler from the module that they are relevant.

The parameter data structures should include:

  1. Long flag and config file parameter name.
  2. Data type
  3. Validation methods
  4. Help message data.

Ideally, the obtain the value for the argument, the particular instance of the argument data structure may be provided to the global registry.

Event Timeline

schancel added a project: Bootcamp.
schancel updated the task description. (Show Details)

The general idea is to have something that works as follow:

CommandLineParameter<bool> MyParameter("myparameter", true, "This parameter does some very interesting thing");

// Parameter use
void doTheThing(const Config &config) {
    bool value = config.get(MyParameter);
    // ...
}

Later on the parameter can take more arguments, such as a parser for it's value, a validator to ensure the provided value is correct, a visibility parameter to know if we display it in the help or not, etc...

Once we get the basic to work, we can extend.

schancel renamed this task from Better Argument Handling to Better config/command line parameter handling.Mar 2 2018, 04:51

I like this task I can take a shot at it.

So is it assumed that the parameters are global to the state? The design becomes a little bit more efficient in some regards if the parameter as given in the example is considered global to the run of the program vs living in the "config" object.

Is it conceivable that there are multiple Config objects that point to different configurations alive in the same memory space? Or is "Config" always a part of the global state?