On Tue, 21 Jan 2020 at 06:40, Markus Armbruster <arm...@redhat.com> wrote: > John Snow <js...@redhat.com> writes: > > Still, I do want to ask: Are we sure we want to double-down on keeping > > the .hx files around instead of trying to move to a more generic data > > format? > > One the one hand, I'd prefer to invest as little as practical into .hx. > On the other hand, adding more hard dependencies on QAPIfication is not > a good idea. > > What's the stupidest solution that could possibly work now? Is it the > one Peter sketched?
FWIW, I wrote some code for the Sphinx extension approach yesterday, along the 'simplest possible thing' lines. It's less than 200 lines of Python (though I still need to put in the support for DEFHEADING and ARCHHEADING). The actual texinfo fragments in the various .hx files of course would also need to be hand-converted to rST, same as the hand-written manual .texi file contents. (This has been easier than my last half-attempt at updating qapi-gen to support output of rST format...) thanks -- PMM
