Re: [Qemu-devel] [PATCH RFC 0/2] qemu-arg: general purpose argument parser

[Leandro Dorileo <l@dorileo.org>]

Hi Peter,

On Sat, Mar 08, 2014 at 06:55:50PM +0000, Peter Maydell wrote:
> On 8 March 2014 18:47, Leandro Dorileo <l@dorileo.org> wrote:
> > The following patchset introduces a general purpose argument parser and migrates
> > qemu-img to make use of it. qemu-img is just the first user of it, if we see a
> > good feedback here I move forward and migrate all the other possible users.
> 
> Can you describe what the QEMU-specific features are that
> mean we must roll our own argument-parsing infrastructure
> rather than using (say) the glib option parsing routines?


I don't think GOption will do the output I want and think to be the ideal for
qemu or specially to qemu-img.

GOption knows nothing about command, since qemu-img was my first target I
wanted something to handle its command schema. GOption will not show the users
the list of available commands neither show commands specific options, I wanted
the user to run qemu-img create -h and show the create command arguments (similar
to git output). GOption will not do that by default, of course we can wrap that
and have something similar.

GOption will not be able to list commands and their arguments so we can generate
the .hx file (see patch 02 in my series) or maybe the texi output and keep the
sync between the implemented commands, arguments and the textinfo stuffs.
GOption also doesn't know about the "cumulative" stuff - well I agree this last
one is not somethig to justify qemu-arg per se.

The command callbacks flow is also something GOption will not give us for free,
we would still need to know ourself about the available commands and their
callees.

As I said, my first target was qemu-img, but I ended up writing something more
generic to be used elsewhere.

Of course I could wrap GOption or getopt and handle all the corner cases but
parsing the arguments myself gave me more flexibility.

Regards...

-- 
Leandro Dorileo