Re: [RFC PATCH 03/23] scripts: add script to generate C header files from SVD XML files

[Octavian Purdila]

On Thu, Aug 8, 2024 at 11:34 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 8/8/24 23:56, John Snow wrote:
> > I haven't read the rest of this series; I'm chiming in solely from the
> > build/python maintainer angle. Do we *always* need pysvd, no matter how
> > QEMU was configured? Adding it to the meson line here is a very big hammer.
>
> In general I'd agree, though for a 7.5 kB package with no other
> dependencies I'm willing to make an exception.
>
> The alternative would be pretty complex:
>
> - check if pysvd is installed in the host
>
> - check if a machine type that needs pysvd is enabled, defaulting to y
> or n depending on the previous step and --enable-download
>
> - use that to decide between doing nothing, installing pysvd or erroring out
>
> - pass the availability of pysvd to Kconfig
>
> - use that to make the final determination on whether to enable those
> machine types that use pysvd
>
> This is quite obviously overengineered compared to the alternative.
>
> Another possibility is to ship the generated file, skip regeneration if
> pysvd is not installed (on the host), and not touch pythondeps.toml at
> all.  Whether shipping a generated file is acceptable should be decided
> by Peter as ARM maintainer, personally I would go the way that Octavian
> is going already and I'm mentioning the rest only for completeness and
> education.
>
> However...
>
> > We also need to provide a way for pysvd to be available offline; some
> > packages are available via distro libs and if this package is available
> > for every distro we officially support, that's sufficient (but requires
> > updates to our various docker and VM test configuration files to add the
> > new dependency). Otherwise, like we do for meson, we need to vendor the
> > wheel in the tree so offline tarball builds will continue to work.
> >
> > It looks like pysvd is a pure python package with no dependencies, so it
> > should be OK to vendor it in qemu.git/python/wheels/ - look at
> > qemu.git/python/scripts/vendor.py and consider updating and running this
> > script.
>
> ... this is indeed correct.  It's not hard and it helps building on
> older distros.  Future versions of Debian or Fedora might package pysvd,
> but right now it's not included anywhere
> (https://repology.org/project/python:pysvd/history).
>
> > That said, you might be the first person I've seen outside of Paolo and
> > I to brave mucking around with the python build venv. You deserve a
> > bravery sticker :)
>
> It's not that bad, come on. :)  But yeah, I'm positively surprised by
> the effort to include pysvd in the virtual environment, and any
> suggestions to improve the documentation and discoverability of the venv
> setup are welcome.  I'm curious whether you figured it out yourself or
> found https://www.qemu.org/docs/master/devel/build-system.html.
>

A combination of reading the docs above and looking at how things are
done for other packages (meson, sphinx). It really was
straightforward.

> One thing I heard from others is that pythondeps.toml looks "too much
> like" a fringe standard Python feature that no one has heard about.  In
> some sense that's a great compliment, but I can see how it can be a bit
> disconcerting.
>

Now that you mentioned it I can see how people might think that :) But
the build system docs are pretty clear IMO.