Re: [program_options] Proposal: self-contained, header-only port of Boost Program Options library

From: Vicram Rajagopalan (vicramrajagopalan_at_[hidden])
Date: 2019-09-17 05:02:13

On Thu, Sep 12, 2019 at 11:01 AM Zach Laine via Boost
<boost_at_[hidden]> wrote:
> I agree with a lot of the points raised above about the problematic nature
> of Boost.ProgramOptions.  I also think Lyra looks interesting.

Regarding Lyra, I took a look at the Github repo a few weeks ago, but
as far as I could tell, it hasn't gained much traction. That was just my
impression from the low number of stars, watches, issues, and pull
requests. Are there any particular reasons that y'all recommend Lyra
in particular?
Granted, development/maintenance does seem to be active, which
is a good sign in my book.

> If you're interesting in solving problems in this space, rather than doing
> a straight port, here are some things I would find very helpful, not all of
> which Lyra provides:

I suppose what I'd really like to see is a de-facto standard; right now,
it doesn't seem that one exists. Given that Boost.ProgramOptions is
not a particularly good example to follow, the best use of my time
may be to contribute to a healthy project. cxxopts is one that caught
my eye, as it seems more well-known than most other similar
projects. Does anyone have any impressions of cxxopts (or others)?

> - The ability to serialize the options, so that I can easily use "response
> files" (files containing command line options or some serialized form of
> them), and/or hand-editable config files.

Judging from the documentation, the Gflags library (Google's command-
line flags library) supports something like this, which they call a "flagfile":
https://gflags.github.io/gflags/
I've never used Gflags so I can't speak to whether it's any good.

-Vicram Rajagopalan