On 9/8/24 11:59, Daniel P. Berrangé wrote:
On Fri, Aug 09, 2024 at 11:42:38AM +0200, Paolo Bonzini wrote:
On Fri, Aug 9, 2024 at 11:30 AM Philippe Mathieu-Daudé
<phi...@linaro.org> wrote:
On 9/8/24 00:30, Octavian Purdila wrote:
On Thu, Aug 8, 2024 at 2:56 PM John Snow <js...@redhat.com> wrote:
diff --git a/configure b/configure
index 5ad1674ca5..811bfa5d54 100755
--- a/configure
+++ b/configure
@@ -956,7 +956,7 @@ mkvenv="$python ${source_path}/python/scripts/mkvenv.py"
# Finish preparing the virtual environment using vendored .whl files
$mkvenv ensuregroup --dir "${source_path}/python/wheels" \
- ${source_path}/pythondeps.toml meson || exit 1
+ ${source_path}/pythondeps.toml meson svd-gen-header || exit 1
Hi John,
Thanks for reviewing!
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.
I think the minimum we can do is to install it only if CONFIG_ARM is
enabled. That might change in the future if the models we create with
pysvd are enabled for other architectures.
Similarly on how we manage libfdt, you can have meson defines
SVDGEN as:
config_host_data.set('CONFIG_SVDGEN', svd_gen_header.found())
Then declare SVDGEN in Kconfig.host, and finally use in the Kconfigs:
That would force people to install pysvd on the host, which is a pity
for such a small and little-known library. We have used submodules
in the past for much larger and common dependencies, for example
capstone.
As mentioned elsewhere in thsi threads, IMHO we shoud not be running
this generator during the build at all. It should be run once to
create the headers needed for a particular device & the output committed
to QEMU. There after any changes to the header (if any) need reviewing
to ensure they don't imply an impact on guest ABI. This avoids having
the 8.6 MB XML file in QEMU git too, as well as the pysvd dep on the
host. Only the very rare times when we create a new device would need
to have the pysvd code & XML.
OK, fine by me, as long as we don't end in a similar use of dtc where
we use distrib dtc to rebuild outdated dts and emit a bunch of pointless
warnings cluttering the build output and that nobody agrees how to fix.
