John Snow <js...@redhat.com> writes: > Presently we use hxtool and a .hx format to generate a few things like > the qemu_img subcommand dispatch table, the qemu_img help() display output, > and a help output in qemu-img.texi. > > Unfortunately, this means that this information is duplicated in at least > three places: > > (1) in qemu-img-cmds.hx as a human readable string > (2) in qemu-img-cmds.hx as a texi string > (3) in qemu-img.texi again, as a texi string > > We can do a little better, though: all of these sources can be generated > from a single json file. Add a new small tool ("pxtool") that can do this. > > This tool can at least handle generating (1) and (2) from the same source > without needing to reduplicate that information. Deduplicating (3) happens > in the next patch. > > Notes: > - The json format was chosen to be very "stupid", and the command line > documentation is being kept one-per-line to make future diffs easier > to read. > - It's easy enough to generate the human-readable output from the texi > output by removing '@var{foo}' with 'foo'. > - The qemu-img command dispatch always calls img_cmdname, so we don't > need to store this information separately, either. > - The need for DEF() macros could be removed as well, but I left it in > to create a minimally disruptive patch. > Signed-off-by: John Snow <js...@redhat.com>
We got just five .hx: qemu-img.cmds.hx killed off by this patch qemu-options.hx CLI QAPIfication should kill this off hw/audio/pl041.hx misnamed, not actually food for hxtool hmp-commands.hx no exit strategy hmp-commands-info.hx for these two, yet CLI QAPIfication got stuck in the back-burner, and as long as that's the case, it's not an alternative to your patches.