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

[Paolo Bonzini <pbonzini@redhat.com>]

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.

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.

Paolo