Re: [Qemu-devel] [PATCH] RFC: options parse in vl.c should be moduled

["Lluís Vilanova" <vilanova@ac.upc.edu>]

Anthony Liguori writes:
>> My plan is to have a -query-capabilities so we can change the help text, then
>> use GOptionContext.
>> 
>> It would take a small function that goes through and promotes any option in the
>> format '-foo' to '--foo'. But that's not too hard.
>> 
>> Then we can completely rip out the option parsing, qemu-options.hx, and all of
>> that other junk.

> glib's option parsing support has some really nice features like translation
> support, grouping, and inline help for option definition.

> The grouping is a really nice touch.  It will let us have a target specific
> group, device groups, etc.

This sounds really nice and much more "uncrufty".

What I'd like to see is some "type_init"-like black magic so that code can
easily register GOptionEntry structures without having to resort to modifying a
central file (otherwise I think the story will repeat itself again).

For this to work, besides defining the GOptionEntry itself, the programmer
should also establish:

* The option group (for cmdline help grouping). This is already supported by
  GOptionGroup, and everybody should register against a set of pre-defined
  groups.

* The parsing priority (so that it's easy to establish a partial order on the
  parsing of options). This also requires a set of pre-defined priorities to
  register against.

What I'm not sure is whether both can be merged into a single one. That is, that
options in the same group don't care about the order in which their parsing
callbacks are called (as long as you know the order between groups).



Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth