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
