Stefan Beller <[email protected]> writes:
> Your approach seems more like what we really want, however I'd have
> some points:
> * Is it a good idea to have so many different OPT_MODE or
> OPTION_MODE defines? In my attempts I tried to reuse existing
> OPTION_s to not pollute the parsing infrastructure with more
> lines of code. ;)
>
> * You can only have one OPTION_CMDMODE in one argv vector right?
That is not what I intended, at least.
int one = 0, two = 0;
struct option options[] = {
OPT_CMDMODE('a', NULL, &one, N_("set one to a"), 'a'),
OPT_CMDMODE('b', NULL, &one, N_("set one to b"), 'b'),
OPT_CMDMODE('c', NULL, &two, N_("set two to c"), 'c'),
OPT_CMDMODE('d', NULL, &two, N_("set two to d"), 'd'),
OPT_END()
}
should give you two independent sets of modes, one and two.
The only reason I needed to add an extra parameter to get_value()
was so that I can tell the former two and the latter two belong to
different groups, and that is done by looking at the address of the
variable. In opt_command_mode_error(), opt->value == that->value
is used as a condition to see if the other option is possibly the
one that was used previously, which conflicted with us.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
