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
