On 5/19/23 19:01, Peter Maydell wrote:
Can you send your config-host.mak after a failed rebuild? I think
what's happening is that the path to meson has changed but Makefile
still tries the old one (which could be the system meson in
/usr/bin).
Attached; it has
MESON=/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/x86-tgts/pyvenv/bin/meson
That meson says: $
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/x86-tgts/pyvenv/bin/meson --version>
1.1.0 is neither the system meson (which is 0.61.2) nor the version
the build system wants (0.63.0) nor the version that it complains
that it's found (0.61.5), so I'm not sure what's going on there...
1.1.0 must be something you have cached somewhere, but 0.61.5 comes from
the old submodule. You should be able to find it with
grep -wA2 'rule REGENERATE_BUILD' ../build.ninja
You should be able to unhose the directory with
pyvenv/bin/meson setup --reconfigure ../..
(where ../.. should be the path to the sources) or even with the patch:
diff --git a/Makefile b/Makefile
index 3c7d67142f13..08fb6a3b058a 100644
--- a/Makefile
+++ b/Makefile
@@ -115,15 +115,15 @@ Makefile.ninja: build.ninja
$(NINJA) -t query build.ninja | sed -n '1,/^ input:/d; /^
outputs:/q; s/$$/ \\/p'; \
} > $@.tmp && mv $@.tmp $@
-include Makefile.ninja
+endif
+ifneq ($(MESON),)
# A separate rule is needed for Makefile dependencies to avoid -n
build.ninja: build.ninja.stamp
$(build-files):
build.ninja.stamp: meson.stamp $(build-files)
- $(NINJA) $(if $V,-v,) build.ninja && touch $@
-endif
+ $(MESON) setup --reconfigure $(SRC_PATH) && touch $@
-ifneq ($(MESON),)
Makefile.mtest: build.ninja scripts/mtest2make.py
$(MESON) introspect --targets --tests --benchmarks | $(PYTHON)
scripts/mtest2make.py > $@
-include Makefile.mtest
Paolo
