On Wed, 8 Nov 2023, Peter Maydell wrote:
On Wed, 8 Nov 2023 at 18:33, Philippe Mathieu-Daudé <phi...@linaro.org> wrote:
Signed-off-by: Philippe Mathieu-Daudé <phi...@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
