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
