[Monotone-devel] Re: boost::program_options

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Sat, 2 Apr 2005 15:39:03 -0800, Nathaniel Smith 
<address@hidden> said:

njs> If someone is going to consider going to the trouble of mucking
njs> around this much with the command parsing, it would be good to
njs> also consider finally adding subcommand option support, which has
njs> been needed for some time :-).  The basic idea for how to do this
njs> is that we want to avoid "cvs subcommand option hell", so rather
njs> than having completely different option parsing before and after
njs> the subcommand, we declare that any option can occur anywhere on
njs> the command line, and no matter the subcommand there is always
njs> the same correspondence between short and long options... but
njs> some options are illegal combined with some subcommands, and
njs> these options are only described in the subcommand help for
njs> subcommands that accept them, not the generic help.

Uhmmm...  Eeep!  From a technological point of view, this may head us
toward hell.  Basically, it would entail accepting all possible
options, then check the subcommand and see if any of the options we
just accepted should really be rejected.

I'll think about it.

njs> (This last point is why popt's insistence on documenting all
njs> options is unacceptable, as mentioned above.)

Hmm, popt actually has a flag, POPT_ARGFLAG_DOC_HIDDEN...  If we could
just have that applied dynamically...  Again, I'll think about it.

njs> To make life a little bit more interesting, it should be possible
njs> to change the documentation printed for one of these options
njs> depending on which subcommand we're documenting; "--depth" means
njs> something very similar, but not quite the same, for "log" and
njs> "pull".

I *hope* we can insist on --depth taking the same type of argument for
all subcommands that take it.  Otherwise, we're truly going to hell.

njs> The interesting parts of adding this support would seem to be:
njs>   -- coming up with a sane uniform way for CMDs to declare which
njs>      options they accept

That should be the easier part.  I think...  The simplest is probably
to have all possible options in the main options table, and then just
have each CMD declare which of them it takes.  Honestly.  Especially
considering (1) below.

njs>   -- needing some checking code that can verify that (1) no CMD
njs>      wants an option that isn't globally consistent, (2) every
njs>      option actually appearing on the commandline is compatible
njs>      with the subcommand being called

njs>   -- needing to teach commands::explain_usage how to describe
njs>      these subcommand options

Did I mention hell already?  I'm sure I did...  :-)

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis