boost::program_options (was Re: [Monotone-devel] popt buggy)

[Nathaniel Smith]

On Sat, Apr 02, 2005 at 04:16:51PM +0000, Julio M. Merino Vidal wrote:
> Couldn't we use Boost::Program_options?
> 
> http://www.boost.org/doc/html/program_options.html

Fascinating idea.  I hadn't known this was added.

>From a quick skim, it seems like it would work, except that it only
supports doing the equivalent of poptStuffArgs at the end of the
command line:
  http://www.boost.org/doc/html/program_options/howto.html#id549275
So
  $ monotone -@ options blah
would actually have to be parsed like current
  $ monotone blah -@ options
which I can't quite decide if is a problem or not :-).  Presumably
it's not a big deal in practice; OTOH, it is certainly
confusing/surprising, and it would be more elegant for the response
file to insert its contents where the user said, like popt's model.
I'm not sure this is fixable; program_options's model is to parse
everything before giving user code a chance to react.

It also, unfortunately, declines to provide a way to parse the file,
which is a bit annoying, because who wants to figure out what the
"expected" quoting rules etc. are?  Inexplicably, it actually _does_
provide a function to parse a command line string into a vector, but
only on Win32; it'd be nice if this function did something sane on
POSIX as well, and then could be used for "response files" directly.
(I guess "something sane" on POSIX ideally involves knowing about both
" and ' quoting, but even just providing the Win32-style parsing would
be a perfectly fine first pass.  poptParseArgv appears to only support
" quoting itself.)

It seems to be very sane WRT help output; you look to see if they
asked for --help, and if so, you can just cout the option description
object.  If you want to cout other stuff too, that's fine.  You can
easily "hide" options from this output, or display them.  (popt AFAICT
can't do this, which is a problem for us; see below.)

I can't figure out how things work when there is order dependence
between options.  For instance, if the user says --debug --quiet, then
--quiet should win; but if they say --quiet --debug, then --debug
should win.  But by the time we see the options, all we know is that
--debug and --quiet were both passed, and we don't know the relative
order.  Maybe there's some specific support for this kind of thing,
but if so it seems to be undocumented; if not, then it seems very hard
to fix, since again, user code doesn't really get a chance to run
until parsing is complete.  This is a showstopper for us; I don't
think we can use program_options at all without this feature.

If someone is going to consider going to the trouble of mucking around
this much with the command parsing, it would be good to also consider
finally adding subcommand option support, which has been needed for
some time :-). The basic idea for how to do this is that we want to
avoid "cvs subcommand option hell", so rather than having completely
different option parsing before and after the subcommand, we declare
that any option can occur anywhere on the command line, and no matter
the subcommand there is always the same correspondence between short
and long options... but some options are illegal combined with some
subcommands, and these options are only described in the subcommand
help for subcommands that accept them, not the generic help.  (This
last point is why popt's insistence on documenting all options is
unacceptable, as mentioned above.)  To make life a little bit more
interesting, it should be possible to change the documentation printed
for one of these options depending on which subcommand we're
documenting; "--depth" means something very similar, but not quite the
same, for "log" and "pull".

The interesting parts of adding this support would seem to be:
  -- coming up with a sane uniform way for CMDs to declare which
     options they accept
  -- needing some checking code that can verify that (1) no CMD wants
     an option that isn't globally consistent, (2) every option
     actually appearing on the commandline is compatible with the
     subcommand being called
  -- needing to teach commands::explain_usage how to describe
     these subcommand options

-- Nathaniel

-- 
In mathematics, it's not enough to read the words
you have to hear the music