| Message ID | 20231108183251.80572-2-philmd@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | buildsys: Use host meson on macOS Sonoma (14) | expand |
On Wed, 8 Nov 2023 at 18:33, Philippe Mathieu-Daudé <philmd@linaro.org> wrote: > > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> > --- > configure | 9 +-------- > 1 file changed, 1 insertion(+), 8 deletions(-) > > diff --git a/configure b/configure > index f1456f6123..93735b7661 100755 > --- a/configure > +++ b/configure > @@ -955,15 +955,8 @@ if $python -c 'import sys; sys.exit(sys.version_info >= (3,11))'; then > $mkvenv ensure --dir "${source_path}/python/wheels" \ > 'tomli>=1.2.0' || exit 1 > fi > -$mkvenv ensuregroup --dir "${source_path}/python/wheels" \ > - ${source_path}/pythondeps.toml meson || exit 1 > > -# At this point, we expect Meson to be installed and available. > -# We expect mkvenv or pip to have created pyvenv/bin/meson for us. > -# We ignore PATH completely here: we want to use the venv's Meson > -# *exclusively*. > - > -meson="$(cd pyvenv/bin; pwd)/meson" > +meson="$(which meson)" Presumably the other approach would be to make the pythondeps.toml say "on macos we need at least version X of meson" ? Do we know what the upstream meson issue is that we're running into with the older version on this host ? thanks -- PMM
On Wed, 8 Nov 2023, Peter Maydell wrote: > On Wed, 8 Nov 2023 at 18:33, Philippe Mathieu-Daudé <philmd@linaro.org> wrote: >> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> >> --- >> configure | 9 +-------- >> 1 file changed, 1 insertion(+), 8 deletions(-) >> >> diff --git a/configure b/configure >> index f1456f6123..93735b7661 100755 >> --- a/configure >> +++ b/configure >> @@ -955,15 +955,8 @@ if $python -c 'import sys; sys.exit(sys.version_info >= (3,11))'; then >> $mkvenv ensure --dir "${source_path}/python/wheels" \ >> 'tomli>=1.2.0' || exit 1 >> fi >> -$mkvenv ensuregroup --dir "${source_path}/python/wheels" \ >> - ${source_path}/pythondeps.toml meson || exit 1 >> >> -# At this point, we expect Meson to be installed and available. >> -# We expect mkvenv or pip to have created pyvenv/bin/meson for us. >> -# We ignore PATH completely here: we want to use the venv's Meson >> -# *exclusively*. >> - >> -meson="$(cd pyvenv/bin; pwd)/meson" >> +meson="$(which meson)" Doesn't this revert 66e2c6cbace ? > Presumably the other approach would be to make the pythondeps.toml > say "on macos we need at least version X of meson" ? > > Do we know what the upstream meson issue is that we're running into > with the older version on this host ? Linked from the QEMU ticket in the cover letter: https://github.com/mesonbuild/meson/issues/12399 AFAIU the problem is that macOS has system python in /Library/Frameworks/python.framework (or something like that) but homebrew does not use that but installs its own python somewhere in /opt and meson from homebrew uses that python but configure finds the system python which does not have meson so it then downloads its own meson but that's too old for macOS Sonoma. It should probably check for homebrew or macports locations too or check for meson and get the python that's using. A workaround apparently is to pass --python with the right path to configure. Regards, BALATON Zoltan
Il mer 8 nov 2023, 20:52 BALATON Zoltan <balaton@eik.bme.hu> ha scritto: > AFAIU the problem is that macOS has system python in > /Library/Frameworks/python.framework (or something like that) but homebrew > does not use that but installs its own python somewhere in /opt and meson > from homebrew uses that python but configure finds the system python which > does not have meson so it then downloads its own meson but that's too old > for macOS Sonoma Correct (except s/downloads/installs/), basically --python/$PYTHON is the sole interpreter used to run *any* Python code during the QEMU build. The difference is that QEMU 8.1 would indeed download Meson, while QEMU 8.2 always uses the wheel that is shipped with QEMU. This change was done because the embedded Meson is intended to be a "known good" version that we (and pythondeps.toml) can point users to, in case a newer version from the distro has issues. Of course the other side of the coin is that an older version might not support new OSes as in this case. The workaround below is not just a workaround but the intended solution if one wants to use the Meson and Sphinx packages from homebrew, and cannot modify the PATH to privilege homebrew's Python interpreter. In order to support Sonoma out of the box with the system Python, however, we can bump the shipped version of Meson to 1.2.x (and adjust pythondeps.toml). Paolo It should probably check for homebrew or macports > locations too or check for meson and get the python that's using. A > workaround apparently is to pass --python with the right path to > configure. >
diff --git a/configure b/configure index f1456f6123..93735b7661 100755 --- a/configure +++ b/configure @@ -955,15 +955,8 @@ if $python -c 'import sys; sys.exit(sys.version_info >= (3,11))'; then $mkvenv ensure --dir "${source_path}/python/wheels" \ 'tomli>=1.2.0' || exit 1 fi -$mkvenv ensuregroup --dir "${source_path}/python/wheels" \ - ${source_path}/pythondeps.toml meson || exit 1 -# At this point, we expect Meson to be installed and available. -# We expect mkvenv or pip to have created pyvenv/bin/meson for us. -# We ignore PATH completely here: we want to use the venv's Meson -# *exclusively*. - -meson="$(cd pyvenv/bin; pwd)/meson" +meson="$(which meson)" # Conditionally ensure Sphinx is installed.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- configure | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-)