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.
Paolo
