Support option name aliases / multiple long options

[eyalroz]

(This is a feature I added to boost::program_options a couple of years back.)

Right now, if you name an option "x,long-name-of-x,another-long-name-of-x" - you get an error:

terminate called after throwing an instance of 'cxxopts::invalid_option_format_error'
  what():  Invalid option format 'x,long-name-of-x,another-long-name-of-x'

instead, cxxopts should support having multiple aliases for the (first and primary) name of the option - all of which would be accepted on the command-line just as though the primary name were used.

[KappaDistributive]

I'd like to work on this. If there's anything I should keep in mind, please do let me know.

Otherwise, I'll share a first draft as soon as I have one and we can take it from there.

[jarro2783]

I can't think of anything, a short and a long name are basically already an alias for each other, so I think the syntax just needs to be extended. Go for it.

[KappaDistributive]

Sorry for the slow reply -- live happened.

I've taken a closer look at the code now and thought about how to implement it. AFAIK, there are a few viable options, ranked in increasing order of intrusiveness:

• We could overload Options::add_option once more and allow it to receive an array of long names and then adapt OptionAdder::operator() and the relevant RegEx accordingly. (The only option that is 100% backward compatible)
• We could do away with the assumption that long names consist of only one alias and replace the current implementation of Options::add_option and OptionAdder::operator(). (OptionAdder::operator() would remain backward compatible but Options::add_option would not.)
• We could add an additional layer of abstraction and create a bunch of Command (name tbd) entities that we split the initial string into and then handle both short and long names uniformly. (OptionAdder::operator() would remain backward compatible but Options::add_option would not.)

Since I don't know this package and its users well enough to make this call, I require your expertise to make this decision. Once we've narrowed it down, I'll create an initial implementation that we can discuss in detail.

[eyalroz]

I think that the minimal change in terms of user-facing functions is simply being willing to parse "x,foo,bar" and not just "x,foo":

    options.add_options()
        ("x,foo,bar", "Frobincate the bar", cxxopts::value<bool>()->default_value("true"));

That's your second option IIUC.

But it doesn't have to be just one way of specifying multiple aliases. And I like the first option as well, i.e. I'd also like it if I could write:

    options.add_options()
        ({'x', "foo", "bar" }, "Frobincate the bar", cxxopts::value<bool>()->default_value("true"));

and for that to work.

[KappaDistributive]

Yeah, that's the OptionAdder::operator() part -- that would remain compatible in any of my suggestions, i.e. the user would use

options.add_options()
        ("x,foo,bar", "Frobincate the bar", cxxopts::value<bool>()->default_value("true"));

to define aliases. My question is about the backend -- i.e. about how OptionAdder::operator() and Options::add_option should talk to one another. Right now, the implementation seems a bit ad-hoc. And the core of the question is whether we would like to refactor that part now or simply bolt on a new feature.

[eyalroz]

Change the backend, of course. (Goes without saying IMHO).

[jarro2783]

You should extend the interface without breaking existing behaviour if possible, and change the backend to support it. I think this is easily done in this case.

[eyalroz]

@KappaDistributive : Did you get around to working on this?

[KappaDistributive]

@KappaDistributive : Did you get around to working on this?

No. I was planning to work on this as my vacation project but then decided to go with another project instead. Sorry for not letting you know sooner.

[artpaul]

@eyalroz I'm just interested why would you need extra aliases for the single option?

[eyalroz]

@artpaul : Basically for the same reason you want both a short name and a long name: Convenience for the user. This way they don't have to remember whether to type, for example --with-foo=bar or --foo=bar or --enable-foo=bar - any of them would work.

It also makes it easier to change option names without breaking existing scripts.