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 created this task.Feb 28 2018, 20:06
schancel added a project: Bootcamp.
schancel updated the task description. (Show Details)
deadalnix added a subscriber: deadalnix.EditedFeb 28 2018, 20:49

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 updated the task description. (Show Details)Feb 28 2018, 22:05
schancel renamed this task from Better Argument Handling to Better config/command line parameter handling.Mar 2 2018, 04:51
Steve132 added a subscriber: Steve132.Jun 9 2018, 04:14

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

Steve132 added a comment.Jun 9 2018, 06:48

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?

deadalnix assigned this task to matiu.Jul 4 2018, 15:59