Remove boost::program options

pomerol-ed / pomerol

Exact diagonalization, Lehmann's representation, Two-particle Green's functions

http://pomerol-ed.github.io/pomerol/

Mozilla Public License 2.0

45 stars 16 forks source link

Closed aeantipov closed 3 years ago

aeantipov commented 4 years ago

Boost::program_options is incompatible with old gcc, clang and builds fail

krivenko commented 4 years ago

I checked three command-line parsing header-only libraries.

All three come with the same caveat: There is no way to simulate Boost's multitoken() feature, which allows us to write

anderson.pomerol --levels 1.0 2.0 --hoppings 3.0 4.0

With those libraries, it has to be either

anderson.pomerol --levels 1.0,2.0 --hoppings 3.0,4.0

anderson.pomerol --levels "1.0 2.0" --hoppings "3.0 4.0"

@aeantipov How much of a problem do you think this change of the command line format would be?

aeantipov commented 4 years ago

I think it's fine or actually it's even better when we need to provide arguments via a comma.

cxxopts support std::vector arguments, so something like that would work.

krivenko commented 4 years ago

cxxopts looked like a perfect choice as its API is very similar to that of boost::program_options. So I tried it and got disappointed.

For some reason, dots are disallowed in option names, and we do need them (gf.eta, gf.step, etc).
An option with a single-character name (for instance, --U) is always assumed to be a short option and has to be used as -U (https://github.com/jarro2783/cxxopts/issues/249).
Not really a problem, but a rather strange decision to define default values in their unparsed form, i.e. as strings.

I have some positive experience using args and will try it next, but it will require some redesign of the programs.

krivenko commented 3 years ago

Fixed by #40.