[libvirt PATCH 321/351] meson: docs: introduce meson-html-gen.py helper

Peter Krempa pkrempa at redhat.com
Tue Jul 28 14:23:15 UTC 2020


On Tue, Jul 28, 2020 at 16:14:03 +0200, Pavel Hrdina wrote:
> On Tue, Jul 28, 2020 at 03:59:58PM +0200, Peter Krempa wrote:
> > On Tue, Jul 28, 2020 at 15:57:16 +0200, Pavel Hrdina wrote:
> > > On Tue, Jul 28, 2020 at 03:18:23PM +0200, Peter Krempa wrote:
> > > > On Thu, Jul 16, 2020 at 11:59:17 +0200, Pavel Hrdina wrote:
> > > > > Signed-off-by: Pavel Hrdina <phrdina at redhat.com>
> > > > > ---
> > > > >  docs/Makefile.am          | 26 ---------------------
> > > > >  scripts/meson-html-gen.py | 49 +++++++++++++++++++++++++++++++++++++++
> > > > >  scripts/meson.build       |  1 +
> > > > >  3 files changed, 50 insertions(+), 26 deletions(-)
> > > > >  create mode 100755 scripts/meson-html-gen.py
> > 
> > [...]
> > 
> > > > > +)
> > > > > +
> > > > > +html = subprocess.run(
> > > > > +    [args.xmllint, '--nonet', '--format', '-'],
> > > > > +    input=html_tmp.stdout,
> > > > > +    stdout=subprocess.PIPE,
> > > > > +    stderr=subprocess.PIPE,
> > > > 
> > > > We can then do this as separate stage.
> > > 
> > > What do you mean by separate stage? Not following here.
> > 
> > I was arguing that the reformatting done by xmllint can be done as a
> > separate build target thus eliminating the need to have this script
> > completely.
> 
> Right, I guess now it can be done like that since there is not the part
> that modified the string directly in python. However, I would like to
> keep it like this.

Well, and I don't like the extra python wrapper which obscures what is
happening. Arguably we could write everything ourselves and just invoke
a massive script from make/meson/whatever.

> We will not have temporary files in the build directory. With two
> targets the temporary file should not be removed otherwise ninja would
> rebuild it every single time and that would cause to rebuild the
> resulting HTML as well.

Umm there's plenty of temporary stuff in the build directory. I don't
think we care. 





More information about the libvir-list mailing list