On Mon, 23 Jun 2008, Linus Torvalds wrote:
>
> Trust me, you need what I wrote. Something that parses all the options in
> one go, and ignores the ones it cannot parse, because a TOTALLY DIFFERENT
> function than the caller will call it!
Side note: of course you can always just queue them up yourself, and then
pass those off to the later stage. But where do you queue them? Can you
re-use argv[]? If so, what's the difference with the simpler patch that I
already posted? (simpler both from a usage standpoint _and_ from a patch
size standpoint).
That said, I *really* don't care what the end result is, but I would
strongly urge people to actually look at what existing code does. That
includes at a minimum builtin-blame.c, but also all the existing users
where _most_ of the arguments are just trivial. builtin-apply.c is a great
example of something where it's almost all trivial, but a lot of the
options set more than one value.
The guiding light here should not be how pretty or clean option-parse.c
is, but how easy it is to convert the hundreds of existing options that
haven't been converted yet. And a lot of them haven't been converted
because it's currently very painful to do multi-valued things, even if
most of those values really are pretty simple.
In that vein - maybe it would be a good idea to allow multiples of the
same option, so that things like builtin-apply.c can handle the "-p"
option (to give an example of this behaviour) as a set of TWO options that
do
OPT_INTEGER('p', NULL, &p_value, "Patch depth"),
OPT_BOOLEAN('p', NULL, &p_value_known),
where "-p3" would then trigger on both, once setting "p_value" to 3, and
once setting p_value_known to 1.
I dunno. But _this_ is the real problem with parse-options.c. It's hard to
convert existing really simple parsers. Whether the problem is writing a
sane set of rules for it without using callbacks (callbacks are neither
easy nor clean), or whether the problem is that the parsing is done in
multiple different places..
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
