On Thu, Aug 8, 2024 at 11:34 PM Paolo Bonzini <pbonz...@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.
