Re: [PATCH v5 13/16] tests: remove "make check-venv" target

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Feb 06, 2026 at 05:41:35PM -0500, John Snow wrote:
> On Thu, Feb 5, 2026 at 12:09 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >
> > John Snow <jsnow@redhat.com> writes:
> >
> > > With the qemu.qmp and qemu.machine dependencies now installed by default
> > > at configure time and additional dependencies required by functional
> > > testing installed on demand, there is no longer any reason to have an
> > > explicit target.
> > >
> > > FIXME: This forces image regeneration for vm tests whenever Make
> > > determines that the image needs to be rebuilt; which is a regression
> > > over the previous behavior.
> > >
> > > Signed-off-by: John Snow <jsnow@redhat.com>
> > > ---
> > >  tests/Makefile.include    | 22 ++--------------------
> > >  tests/vm/Makefile.include | 24 +++++++-----------------
> > >  2 files changed, 9 insertions(+), 37 deletions(-)
> > >
> > > diff --git a/tests/Makefile.include b/tests/Makefile.include
> > > index f28c9e329aa..2a203e23718 100644
> > > --- a/tests/Makefile.include
> > > +++ b/tests/Makefile.include
> > > @@ -21,7 +21,6 @@ ifneq ($(filter $(all-check-targets), check-softfloat),)
> > >  endif
> > >       @echo
> > >       @echo " $(MAKE) check-report.junit.xml   Generates an aggregated XML test report"
> > > -     @echo " $(MAKE) check-venv               Creates a Python venv for tests"
> > >       @echo " $(MAKE) check-clean              Clean the tests and related data"
> > >       @echo
> > >       @echo "The following are useful for CI builds"
> > > @@ -92,33 +91,16 @@ clean-tcg: $(CLEAN_TCG_TARGET_RULES)
> > >  .PHONY: distclean-tcg
> > >  distclean-tcg: $(DISTCLEAN_TCG_TARGET_RULES)
> > >
> > > -# Python venv for running tests
> > > -
> > > -.PHONY: check-venv
> > > -
> > >  # Build up our target list from the filtered list of ninja targets
> > >  TARGETS=$(patsubst libqemu-%.a, %, $(filter libqemu-%.a, $(ninja-targets)))
> > >
> > > -TESTS_VENV_TOKEN=$(BUILD_DIR)/pyvenv/tests.group
> > > -
> > > -quiet-venv-pip = $(quiet-@)$(call quiet-command-run, \
> > > -    $(PYTHON) -m pip -q --disable-pip-version-check $1, \
> > > -    "VENVPIP","$1")
> > > -
> > > -$(TESTS_VENV_TOKEN): $(SRC_PATH)/pythondeps.toml
> > > -     $(call quiet-venv-pip,install -e "$(SRC_PATH)/python/")
> > > -     $(MKVENV_ENSUREGROUP) $< tooling functests
> > > -     $(call quiet-command, touch $@)
> > > -
> > > -check-venv: $(TESTS_VENV_TOKEN)
> > > -
> > >  FUNCTIONAL_TARGETS=$(patsubst %-softmmu,check-functional-%, $(filter %-softmmu,$(TARGETS)))
> > >  .PHONY: $(FUNCTIONAL_TARGETS)
> > > -$(FUNCTIONAL_TARGETS): check-venv
> > > +$(FUNCTIONAL_TARGETS):
> > >       @$(MAKE) SPEED=thorough $(subst -functional,-func,$@)
> > >
> > >  .PHONY: check-functional
> > > -check-functional: check-venv
> > > +check-functional:
> > >       @$(NINJA) precache-functional
> > >       @$(PYTHON) $(SRC_PATH)/scripts/clean_functional_cache.py
> > >       @QEMU_TEST_NO_DOWNLOAD=1 $(MAKE) SPEED=thorough check-func check-func-quick
> > > diff --git a/tests/vm/Makefile.include b/tests/vm/Makefile.include
> > > index 14188bba1c6..095ec2eefa3 100644
> > > --- a/tests/vm/Makefile.include
> > > +++ b/tests/vm/Makefile.include
> > > @@ -1,14 +1,5 @@
> > >  # Makefile for VM tests
> > >
> > > -# Hack to allow running in an unconfigured build tree
> > > -ifeq ($(realpath $(SRC_PATH)),$(realpath .))
> > > -VM_PYTHON = PYTHONPATH=$(SRC_PATH)/python /usr/bin/env python3
> > > -VM_VENV =
> > > -else
> > > -VM_PYTHON = $(PYTHON)
> > > -VM_VENV = check-venv
> > > -endif
> > > -
> >
> > It's a shame to loose this because the build directory should have no
> > influence on what we build in the VM. Surely if we have qmp installed on
> > the system (and therefor its deps) we should still want the ability to
> > build in the src dir. Currently I get:
> >
> >   ➜  make vm-build-netbsd V=1
> >   tests/vm/netbsd  --debug     --source-path . --image "/home/alex/.cache/qemu-vm/images/netbsd.img" --force --build-image /home/alex/.cache/qemu-vm/images/netbsd.img
> >   Traceback (most recent call last):
> >     File "/home/alex/lsrc/qemu.git/tests/vm/netbsd", line 19, in <module>
> >       import basevm
> >     File "/home/alex/lsrc/qemu.git/tests/vm/basevm.py", line 32, in <module>
> >       from qemu.machine import QEMUMachine
> >   ModuleNotFoundError: No module named 'qemu'
> >   make: *** [tests/vm/Makefile.include:86: /home/alex/.cache/qemu-vm/images/netbsd.img] Error 1
> 
> Ah, I see.... it used to be possible to run the VM tests *without a
> build directory at all*.
> 
> So, this used to work because of this bit in tests/vm/Makefile.include:
> 
> # Hack to allow running in an unconfigured build tree
> ifeq ($(realpath $(SRC_PATH)),$(realpath .))
> VM_PYTHON = PYTHONPATH=$(SRC_PATH)/python /usr/bin/env python3
> VM_VENV =
> else
> VM_PYTHON = $(PYTHON)
> VM_VENV = check-venv
> endif
> 
> What this did was effectively treat qemu.git/python/ as an installed
> package directory and picked the most likely culprit for your actual
> python interpreter location. (Note that the configure script is a bit
> more thorough in picking a python interpreter to use that is bypassed
> here.) It's possible we can continue to do this, however, it will
> begin requiring that you just-so-happen to have qemu.qmp available in
> your python environment. The list of dependencies you might need for
> this to work successfully may increase as the years go by, so this is
> a little bit "porcelain". I'm not sure I like this, just because I
> don't wanna be on the hook for mysterious failures down the line.
> 
> Otherwise, to get all of the dependencies and python configuration
> managed for you, you have to do this:
> 
> mkdir build && pushd build && ../configure && make vm-test-netbsd
> 
> ... But you don't actually have to build, and in fact you don't even
> really need to actually run configure either, so, hm.... yeah, how
> about this, using a new "vm-venv" folder in the source tree as the
> virtual environment location, using a dependency hook like check-venv
> but now localized specifically for VM tests benefit and only when it
> is run from the source tree:

IMHO just keep life simple and expect configure to be run so we
have the regular venv setup.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|