On Tue, Sep 15, 2020 at 06:03:57PM +0200, Alex Riesen wrote:
> > If you go that route, we have some "_F" macros that take flags. Probably
> > would make sense to add it more consistently, which lets you convert:
> >
> > OPT_BOOL('f', "foo", &foo, "the foo option");
> >
> > into:
> >
> > OPT_BOOL_F('f', "foo", &foo, "the foo option", PARSE_OPT_RECURSIVE);
> >
> > but could also be used for other flags.
>
> This part (marking of the options) was easy. What's left is finding out if an
> option was actually specified in the command-line. The ...options[] arrays are
> not update by parse_options() with what was given, are they?
Oh right. Having the list of options is not that helpful because
add_options_argv() is actually working off the parsed data in individual
variables. Sorry for leading you in a (maybe) wrong direction.
I think this approach would have to be coupled with some mechanism for
looking over the original list of options (either saving the original
argv before parsing, or teaching parse-options the kind of two-pass
"don't parse these the first time" mechanism discussed elsewhere in the
thread).
> Maybe extend struct option with a field to store given command-line argument
> (as it was specified) and parse_options() will update the field if
> PARSE_OPT_RECURSIVE is present in .flags?
> Is it allowed for parse_options() to modify the options array?
No, we take the options array as a const pointer, so many callers would
likely need to be updated to handle that. Plus it's possible some may
actually re-use the array multiple times in some cases.
> Or is it possible to use something in parse-options.h API to note the
> arguments somewhere while they are parse? I mean, there are
> parse_options_start/step/end, can cmd_fetch argument parsing use those
> so that the options marked recursive can be saved for sub-fetches?
Possibly the step-wise parsing could help. But I think it might be
easier to just let parse_options() save a copy of parsed options. And
then our PARSE_OPT_RECURSIVE really becomes PARSE_OPT_SAVE or similar,
which would cause parse-options to save the original option (and any
value argument) in its original form.
There's one slight complication, which is how the array of saved options
gets communicated back to the caller. Leaving them in the original argv
probably isn't a good idea (because the caller relies on it having
options removed in order to find the non-option arguments).
Adding a new strvec pointer to parse_options() works, but means updating
all of the callers, most of which will pass NULL. Possibly the existing
"flags" parameter to parse_options() could grow into a struct. That
requires modifying each caller, but at least solves the problem once and
for all.
Another option is to stick it into parse_opt_ctx_t. That's used only be
step-wise callers, of which there are very few.
-Peff
