Makefile: Rename targets for make recursion
We make a few sub-directories recursively, in particular
$(TARGET_DIRS).
For goal "all", we do it the nice way: "all" has a prerequisite
subdir-T for each T in $(TARGET_DIRS), and T's recipe runs make
recursively. Behaves nicely with -j and -k.
For other goals such as "clean" and "install", the recipe runs make
recursively in a for loop. Ignores -j and -k.
The next commit will fix that for "clean" and "install". This commit
prepares the ground by renaming the targets we use for "all" to
include the goal for the sub-make. This will permit reusing them for
goals other than "all".
Targets subdir-T for T in $(TARGET_DIRS) run "make all" in T. Rename
to T/all, and declare phony.
Targets romsubdir-R for R in $(ROMS) run "make" in pc-bios/R. Default
goal is "all" for all R. Rename to pc-bios/R/all, and declare phony.
The remainder are renamed just for consistency.
Target subdir-dtc runs "make libbft/libfdt.a" in dtc. Rename to
dtc/all, and declare phony.
Target subdir-capstone runs make $(BUILD_DIR)/capstone/$(LIBCAPSTONE)
in $(SRC_PATH)/capstone. Rename to capstone/all, and declare phony.
Target subdir-slirp runs "make" in $(SRC_PATH)/slirp. Default goal is
all, which builds $(BUILD_DIR)/libslirp.a. Rename to slirp/all, and
declare phony.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190528082308.22032-4-armbru@redhat.com>
[Add compatibility gunk to keep make working across the rename]
2019-05-28 10:23:07 +02:00
|
|
|
# -*- Mode: makefile -*-
|
2017-08-10 10:50:25 +02:00
|
|
|
|
|
|
|
|
.PHONY: check-help
|
|
|
|
|
check-help:
|
|
|
|
|
@echo "Regression testing targets:"
|
2022-05-27 17:30:54 +02:00
|
|
|
@echo " $(MAKE) check Run block, qapi-schema, unit, softfloat, qtest and decodetree tests"
|
|
|
|
|
@echo " $(MAKE) bench Run speed tests"
|
2018-11-09 16:07:10 +01:00
|
|
|
@echo
|
2021-03-10 17:46:12 +01:00
|
|
|
@echo "Individual test suites:"
|
2022-05-27 17:30:54 +02:00
|
|
|
@echo " $(MAKE) check-qtest-TARGET Run qtest tests for given target"
|
|
|
|
|
@echo " $(MAKE) check-qtest Run qtest tests"
|
|
|
|
|
@echo " $(MAKE) check-unit Run qobject tests"
|
|
|
|
|
@echo " $(MAKE) check-qapi-schema Run QAPI schema tests"
|
|
|
|
|
@echo " $(MAKE) check-block Run block tests"
|
2021-02-02 14:39:57 +01:00
|
|
|
ifneq ($(filter $(all-check-targets), check-softfloat),)
|
2022-05-27 17:30:54 +02:00
|
|
|
@echo " $(MAKE) check-tcg Run TCG tests"
|
|
|
|
|
@echo " $(MAKE) check-softfloat Run FPU emulation tests"
|
2020-05-22 19:25:00 +02:00
|
|
|
endif
|
2022-05-27 17:30:54 +02:00
|
|
|
@echo " $(MAKE) check-avocado Run avocado (integration) tests for currently configured targets"
|
2018-11-09 16:07:10 +01:00
|
|
|
@echo
|
2022-05-27 17:30:54 +02:00
|
|
|
@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"
|
2017-08-10 10:50:25 +02:00
|
|
|
@echo
|
2020-07-01 15:56:51 +02:00
|
|
|
@echo "The following are useful for CI builds"
|
2022-05-27 17:30:54 +02:00
|
|
|
@echo " $(MAKE) check-build Build most test binaries"
|
|
|
|
|
@echo " $(MAKE) get-vm-images Downloads all images used by avocado tests, according to configured targets (~350 MB each, 1.5 GB max)"
|
2020-03-17 15:16:54 +01:00
|
|
|
@echo
|
2017-08-10 10:50:25 +02:00
|
|
|
@echo
|
|
|
|
|
@echo "The variable SPEED can be set to control the gtester speed setting."
|
2017-11-21 10:55:10 +01:00
|
|
|
@echo "Default options are -k and (for $(MAKE) V=1) --verbose; they can be"
|
2017-08-10 10:50:25 +02:00
|
|
|
@echo "changed with variable GTESTER_OPTIONS."
|
|
|
|
|
|
|
|
|
|
ifneq ($(wildcard config-host.mak),)
|
2012-03-08 12:29:00 +01:00
|
|
|
export SRC_PATH
|
|
|
|
|
|
2012-03-28 15:42:01 +02:00
|
|
|
SPEED = quick
|
2012-01-10 20:10:43 +01:00
|
|
|
|
2021-02-02 14:39:58 +01:00
|
|
|
# Per guest TCG tests
|
2022-04-19 11:10:11 +02:00
|
|
|
BUILD_TCG_TARGET_RULES=$(patsubst %,build-tcg-tests-%, $(TCG_TESTS_TARGETS))
|
|
|
|
|
CLEAN_TCG_TARGET_RULES=$(patsubst %,clean-tcg-tests-%, $(TCG_TESTS_TARGETS))
|
2022-09-29 13:42:01 +02:00
|
|
|
DISTCLEAN_TCG_TARGET_RULES=$(patsubst %,distclean-tcg-tests-%, $(TCG_TESTS_TARGETS))
|
2022-04-19 11:10:11 +02:00
|
|
|
RUN_TCG_TARGET_RULES=$(patsubst %,run-tcg-tests-%, $(TCG_TESTS_TARGETS))
|
2018-04-06 23:08:36 +02:00
|
|
|
|
2022-04-19 11:10:11 +02:00
|
|
|
$(foreach TARGET,$(TCG_TESTS_TARGETS), \
|
2022-04-19 11:10:10 +02:00
|
|
|
$(eval $(BUILD_DIR)/tests/tcg/config-$(TARGET).mak: config-host.mak))
|
2018-06-08 13:12:46 +02:00
|
|
|
|
2022-04-19 11:10:12 +02:00
|
|
|
.PHONY: $(TCG_TESTS_TARGETS:%=build-tcg-tests-%)
|
|
|
|
|
$(TCG_TESTS_TARGETS:%=build-tcg-tests-%): build-tcg-tests-%: $(BUILD_DIR)/tests/tcg/config-%.mak
|
|
|
|
|
$(call quiet-command, \
|
2022-09-29 13:42:00 +02:00
|
|
|
$(MAKE) -C tests/tcg/$* $(SUBDIR_MAKEFLAGS), \
|
2022-04-19 11:10:12 +02:00
|
|
|
"BUILD","$* guest-tests")
|
|
|
|
|
|
|
|
|
|
.PHONY: $(TCG_TESTS_TARGETS:%=run-tcg-tests-%)
|
2022-05-27 17:35:45 +02:00
|
|
|
$(TCG_TESTS_TARGETS:%=run-tcg-tests-%): run-tcg-tests-%: build-tcg-tests-%
|
2022-04-19 11:10:12 +02:00
|
|
|
$(call quiet-command, \
|
2022-09-29 13:42:00 +02:00
|
|
|
$(MAKE) -C tests/tcg/$* $(SUBDIR_MAKEFLAGS) SPEED=$(SPEED) run, \
|
2022-04-19 11:10:12 +02:00
|
|
|
"RUN", "$* guest-tests")
|
|
|
|
|
|
|
|
|
|
.PHONY: $(TCG_TESTS_TARGETS:%=clean-tcg-tests-%)
|
|
|
|
|
$(TCG_TESTS_TARGETS:%=clean-tcg-tests-%): clean-tcg-tests-%:
|
|
|
|
|
$(call quiet-command, \
|
2022-09-29 13:42:00 +02:00
|
|
|
$(MAKE) -C tests/tcg/$* $(SUBDIR_MAKEFLAGS) clean, \
|
2022-04-19 11:10:12 +02:00
|
|
|
"CLEAN", "$* guest-tests")
|
2018-04-06 23:08:36 +02:00
|
|
|
|
2022-09-29 13:42:01 +02:00
|
|
|
.PHONY: $(TCG_TESTS_TARGETS:%=distclean-tcg-tests-%)
|
|
|
|
|
$(TCG_TESTS_TARGETS:%=distclean-tcg-tests-%): distclean-tcg-tests-%:
|
|
|
|
|
$(call quiet-command, \
|
|
|
|
|
$(MAKE) -C tests/tcg/$* $(SUBDIR_MAKEFLAGS) distclean, \
|
|
|
|
|
"CLEAN", "$* guest-tests")
|
|
|
|
|
|
2018-04-06 23:08:36 +02:00
|
|
|
.PHONY: build-tcg
|
|
|
|
|
build-tcg: $(BUILD_TCG_TARGET_RULES)
|
|
|
|
|
|
|
|
|
|
.PHONY: check-tcg
|
2022-05-27 17:35:45 +02:00
|
|
|
.ninja-goals.check-tcg = all $(if $(CONFIG_PLUGIN),test-plugins)
|
2019-02-28 11:15:29 +01:00
|
|
|
check-tcg: $(RUN_TCG_TARGET_RULES)
|
2018-04-06 23:08:36 +02:00
|
|
|
|
|
|
|
|
.PHONY: clean-tcg
|
|
|
|
|
clean-tcg: $(CLEAN_TCG_TARGET_RULES)
|
2012-03-28 15:42:01 +02:00
|
|
|
|
2022-09-29 13:42:01 +02:00
|
|
|
.PHONY: distclean-tcg
|
|
|
|
|
distclean-tcg: $(DISTCLEAN_TCG_TARGET_RULES)
|
|
|
|
|
|
2018-10-18 17:31:32 +02:00
|
|
|
# Python venv for running tests
|
|
|
|
|
|
2021-11-05 16:53:53 +01:00
|
|
|
.PHONY: check-venv check-avocado check-acceptance check-acceptance-deprecated-warning
|
2018-10-18 17:31:32 +02:00
|
|
|
|
2022-04-19 11:10:11 +02:00
|
|
|
# Build up our target list from the filtered list of ninja targets
|
|
|
|
|
TARGETS=$(patsubst libqemu-%.fa, %, $(filter libqemu-%.fa, $(ninja-targets)))
|
|
|
|
|
|
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)",
2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for
tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when
using a distro-provided package and wanting a "==" constraint when
installing Avocado from PyPI; this would provide the best of both worlds
in terms of resiliency for both distros that have required packages and
distros that don't.
The conflict is visible also for meson, where we would like to install
the latest 0.63.x version but also accept a distro 1.1.x version.
But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv
includes a system avocado. The distro will package plugins that have
"==" constraints on the version that is included in the distro, and, using
"pip install avocado==88.1" on a venv that includes system packages will
result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system
avocado, because that would result in the installation of v101.0 which
is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked)
tuple, like this hypothetical TOML that would be committed inside
python/ and used by mkvenv.py:
[meson]
meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs]
# 6.0 drops support for Python 3.7
sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" }
sphinx_rtd_theme = { minimum = "0.5" }
[avocado]
avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in
pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora
and CentOS Stream (the only distros where it's available). But until
this is implemented, keep avocado in a separate venv. There is still the
benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-05 17:30:38 +02:00
|
|
|
TESTS_VENV_DIR=$(BUILD_DIR)/tests/venv
|
2018-10-18 17:31:32 +02:00
|
|
|
TESTS_VENV_REQ=$(SRC_PATH)/tests/requirements.txt
|
2018-10-18 17:31:33 +02:00
|
|
|
TESTS_RESULTS_DIR=$(BUILD_DIR)/tests/results
|
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)",
2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for
tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when
using a distro-provided package and wanting a "==" constraint when
installing Avocado from PyPI; this would provide the best of both worlds
in terms of resiliency for both distros that have required packages and
distros that don't.
The conflict is visible also for meson, where we would like to install
the latest 0.63.x version but also accept a distro 1.1.x version.
But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv
includes a system avocado. The distro will package plugins that have
"==" constraints on the version that is included in the distro, and, using
"pip install avocado==88.1" on a venv that includes system packages will
result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system
avocado, because that would result in the installation of v101.0 which
is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked)
tuple, like this hypothetical TOML that would be committed inside
python/ and used by mkvenv.py:
[meson]
meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs]
# 6.0 drops support for Python 3.7
sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" }
sphinx_rtd_theme = { minimum = "0.5" }
[avocado]
avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in
pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora
and CentOS Stream (the only distros where it's available). But until
this is implemented, keep avocado in a separate venv. There is still the
benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-05 17:30:38 +02:00
|
|
|
TESTS_PYTHON=$(TESTS_VENV_DIR)/bin/python3
|
2021-09-23 18:11:41 +02:00
|
|
|
ifndef AVOCADO_TESTS
|
2021-11-05 16:53:54 +01:00
|
|
|
AVOCADO_TESTS=tests/avocado
|
2021-09-23 18:11:41 +02:00
|
|
|
endif
|
2018-10-18 17:31:33 +02:00
|
|
|
# Controls the output generated by Avocado when running tests.
|
|
|
|
|
# Any number of command separated loggers are accepted. For more
|
|
|
|
|
# information please refer to "avocado --help".
|
2019-03-12 18:18:05 +01:00
|
|
|
AVOCADO_SHOW=app
|
2021-09-23 18:11:39 +02:00
|
|
|
ifndef AVOCADO_TAGS
|
|
|
|
|
AVOCADO_CMDLINE_TAGS=$(patsubst %-softmmu,-t arch:%, \
|
|
|
|
|
$(filter %-softmmu,$(TARGETS)))
|
|
|
|
|
else
|
|
|
|
|
AVOCADO_CMDLINE_TAGS=$(addprefix -t , $(AVOCADO_TAGS))
|
|
|
|
|
endif
|
2018-10-18 17:31:32 +02:00
|
|
|
|
2022-05-26 02:09:17 +02:00
|
|
|
quiet-venv-pip = $(quiet-@)$(call quiet-command-run, \
|
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)",
2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for
tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when
using a distro-provided package and wanting a "==" constraint when
installing Avocado from PyPI; this would provide the best of both worlds
in terms of resiliency for both distros that have required packages and
distros that don't.
The conflict is visible also for meson, where we would like to install
the latest 0.63.x version but also accept a distro 1.1.x version.
But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv
includes a system avocado. The distro will package plugins that have
"==" constraints on the version that is included in the distro, and, using
"pip install avocado==88.1" on a venv that includes system packages will
result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system
avocado, because that would result in the installation of v101.0 which
is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked)
tuple, like this hypothetical TOML that would be committed inside
python/ and used by mkvenv.py:
[meson]
meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs]
# 6.0 drops support for Python 3.7
sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" }
sphinx_rtd_theme = { minimum = "0.5" }
[avocado]
avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in
pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora
and CentOS Stream (the only distros where it's available). But until
this is implemented, keep avocado in a separate venv. There is still the
benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-05 17:30:38 +02:00
|
|
|
$(TESTS_PYTHON) -m pip -q --disable-pip-version-check $1, \
|
2022-05-26 02:09:17 +02:00
|
|
|
"VENVPIP","$1")
|
|
|
|
|
|
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)",
2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for
tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when
using a distro-provided package and wanting a "==" constraint when
installing Avocado from PyPI; this would provide the best of both worlds
in terms of resiliency for both distros that have required packages and
distros that don't.
The conflict is visible also for meson, where we would like to install
the latest 0.63.x version but also accept a distro 1.1.x version.
But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv
includes a system avocado. The distro will package plugins that have
"==" constraints on the version that is included in the distro, and, using
"pip install avocado==88.1" on a venv that includes system packages will
result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system
avocado, because that would result in the installation of v101.0 which
is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked)
tuple, like this hypothetical TOML that would be committed inside
python/ and used by mkvenv.py:
[meson]
meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs]
# 6.0 drops support for Python 3.7
sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" }
sphinx_rtd_theme = { minimum = "0.5" }
[avocado]
avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in
pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora
and CentOS Stream (the only distros where it's available). But until
this is implemented, keep avocado in a separate venv. There is still the
benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-05 17:30:38 +02:00
|
|
|
$(TESTS_VENV_DIR): $(TESTS_VENV_REQ)
|
|
|
|
|
$(call quiet-command, $(PYTHON) -m venv $@, VENV, $@)
|
2022-05-26 02:09:18 +02:00
|
|
|
$(call quiet-venv-pip,install -e "$(SRC_PATH)/python/")
|
2022-05-26 02:09:17 +02:00
|
|
|
$(call quiet-venv-pip,install -r $(TESTS_VENV_REQ))
|
2018-10-18 17:31:32 +02:00
|
|
|
$(call quiet-command, touch $@)
|
|
|
|
|
|
2018-10-18 17:31:33 +02:00
|
|
|
$(TESTS_RESULTS_DIR):
|
|
|
|
|
$(call quiet-command, mkdir -p $@, \
|
|
|
|
|
MKDIR, $@)
|
|
|
|
|
|
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)",
2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for
tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when
using a distro-provided package and wanting a "==" constraint when
installing Avocado from PyPI; this would provide the best of both worlds
in terms of resiliency for both distros that have required packages and
distros that don't.
The conflict is visible also for meson, where we would like to install
the latest 0.63.x version but also accept a distro 1.1.x version.
But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv
includes a system avocado. The distro will package plugins that have
"==" constraints on the version that is included in the distro, and, using
"pip install avocado==88.1" on a venv that includes system packages will
result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system
avocado, because that would result in the installation of v101.0 which
is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked)
tuple, like this hypothetical TOML that would be committed inside
python/ and used by mkvenv.py:
[meson]
meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs]
# 6.0 drops support for Python 3.7
sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" }
sphinx_rtd_theme = { minimum = "0.5" }
[avocado]
avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in
pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora
and CentOS Stream (the only distros where it's available). But until
this is implemented, keep avocado in a separate venv. There is still the
benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-05 17:30:38 +02:00
|
|
|
check-venv: $(TESTS_VENV_DIR)
|
2018-10-18 17:31:32 +02:00
|
|
|
|
2021-02-26 00:21:21 +01:00
|
|
|
FEDORA_31_ARCHES_TARGETS=$(patsubst %-softmmu,%, $(filter %-softmmu,$(TARGETS)))
|
|
|
|
|
FEDORA_31_ARCHES_CANDIDATES=$(patsubst ppc64,ppc64le,$(FEDORA_31_ARCHES_TARGETS))
|
2020-03-17 15:16:54 +01:00
|
|
|
FEDORA_31_ARCHES := x86_64 aarch64 ppc64le s390x
|
|
|
|
|
FEDORA_31_DOWNLOAD=$(filter $(FEDORA_31_ARCHES),$(FEDORA_31_ARCHES_CANDIDATES))
|
|
|
|
|
|
|
|
|
|
# download one specific Fedora 31 image
|
|
|
|
|
get-vm-image-fedora-31-%: check-venv
|
|
|
|
|
$(call quiet-command, \
|
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)",
2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for
tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when
using a distro-provided package and wanting a "==" constraint when
installing Avocado from PyPI; this would provide the best of both worlds
in terms of resiliency for both distros that have required packages and
distros that don't.
The conflict is visible also for meson, where we would like to install
the latest 0.63.x version but also accept a distro 1.1.x version.
But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv
includes a system avocado. The distro will package plugins that have
"==" constraints on the version that is included in the distro, and, using
"pip install avocado==88.1" on a venv that includes system packages will
result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system
avocado, because that would result in the installation of v101.0 which
is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked)
tuple, like this hypothetical TOML that would be committed inside
python/ and used by mkvenv.py:
[meson]
meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs]
# 6.0 drops support for Python 3.7
sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" }
sphinx_rtd_theme = { minimum = "0.5" }
[avocado]
avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in
pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora
and CentOS Stream (the only distros where it's available). But until
this is implemented, keep avocado in a separate venv. There is still the
benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-05 17:30:38 +02:00
|
|
|
$(TESTS_PYTHON) -m avocado vmimage get \
|
2020-03-17 15:16:54 +01:00
|
|
|
--distro=fedora --distro-version=31 --arch=$*, \
|
2021-11-05 16:53:53 +01:00
|
|
|
"AVOCADO", "Downloading avocado tests VM image for $*")
|
2020-03-17 15:16:54 +01:00
|
|
|
|
|
|
|
|
# download all vm images, according to defined targets
|
|
|
|
|
get-vm-images: check-venv $(patsubst %,get-vm-image-fedora-31-%, $(FEDORA_31_DOWNLOAD))
|
|
|
|
|
|
2021-11-05 16:53:53 +01:00
|
|
|
check-avocado: check-venv $(TESTS_RESULTS_DIR) get-vm-images
|
2023-06-03 23:54:57 +02:00
|
|
|
$(call quiet-command, \
|
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)",
2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for
tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when
using a distro-provided package and wanting a "==" constraint when
installing Avocado from PyPI; this would provide the best of both worlds
in terms of resiliency for both distros that have required packages and
distros that don't.
The conflict is visible also for meson, where we would like to install
the latest 0.63.x version but also accept a distro 1.1.x version.
But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv
includes a system avocado. The distro will package plugins that have
"==" constraints on the version that is included in the distro, and, using
"pip install avocado==88.1" on a venv that includes system packages will
result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system
avocado, because that would result in the installation of v101.0 which
is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked)
tuple, like this hypothetical TOML that would be committed inside
python/ and used by mkvenv.py:
[meson]
meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs]
# 6.0 drops support for Python 3.7
sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" }
sphinx_rtd_theme = { minimum = "0.5" }
[avocado]
avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in
pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora
and CentOS Stream (the only distros where it's available). But until
this is implemented, keep avocado in a separate venv. There is still the
benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-05 17:30:38 +02:00
|
|
|
$(TESTS_PYTHON) -m avocado \
|
2023-06-03 23:54:57 +02:00
|
|
|
--show=$(AVOCADO_SHOW) run --job-results-dir=$(TESTS_RESULTS_DIR) \
|
|
|
|
|
$(if $(AVOCADO_TAGS),, --filter-by-tags-include-empty \
|
|
|
|
|
--filter-by-tags-include-empty-key) \
|
|
|
|
|
$(AVOCADO_CMDLINE_TAGS) \
|
|
|
|
|
$(if $(GITLAB_CI),,--failfast) $(AVOCADO_TESTS), \
|
2021-11-05 16:53:54 +01:00
|
|
|
"AVOCADO", "tests/avocado")
|
2018-10-18 17:31:33 +02:00
|
|
|
|
2021-11-05 16:53:53 +01:00
|
|
|
check-acceptance-deprecated-warning:
|
|
|
|
|
@echo
|
|
|
|
|
@echo "Note '$(MAKE) check-acceptance' is deprecated, use '$(MAKE) check-avocado' instead."
|
|
|
|
|
@echo
|
|
|
|
|
|
|
|
|
|
check-acceptance: check-acceptance-deprecated-warning | check-avocado
|
|
|
|
|
|
2012-03-28 15:42:01 +02:00
|
|
|
# Consolidated targets
|
|
|
|
|
|
2022-03-10 08:50:48 +01:00
|
|
|
.PHONY: check check-clean get-vm-images
|
2020-09-01 15:31:56 +02:00
|
|
|
check:
|
|
|
|
|
|
2021-10-06 10:18:27 +02:00
|
|
|
check-build: run-ninja
|
2020-07-01 15:56:51 +02:00
|
|
|
|
2013-09-26 02:42:56 +02:00
|
|
|
check-clean:
|
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)",
2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for
tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when
using a distro-provided package and wanting a "==" constraint when
installing Avocado from PyPI; this would provide the best of both worlds
in terms of resiliency for both distros that have required packages and
distros that don't.
The conflict is visible also for meson, where we would like to install
the latest 0.63.x version but also accept a distro 1.1.x version.
But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv
includes a system avocado. The distro will package plugins that have
"==" constraints on the version that is included in the distro, and, using
"pip install avocado==88.1" on a venv that includes system packages will
result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system
avocado, because that would result in the installation of v101.0 which
is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked)
tuple, like this hypothetical TOML that would be committed inside
python/ and used by mkvenv.py:
[meson]
meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs]
# 6.0 drops support for Python 3.7
sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" }
sphinx_rtd_theme = { minimum = "0.5" }
[avocado]
avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in
pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora
and CentOS Stream (the only distros where it's available). But until
this is implemented, keep avocado in a separate venv. There is still the
benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-05 17:30:38 +02:00
|
|
|
rm -rf $(TESTS_VENV_DIR) $(TESTS_RESULTS_DIR)
|
2013-09-26 02:42:56 +02:00
|
|
|
|
2022-03-01 09:59:00 +01:00
|
|
|
clean: check-clean clean-tcg
|
2022-09-29 13:42:01 +02:00
|
|
|
distclean: distclean-tcg
|
2012-07-18 19:22:27 +02:00
|
|
|
|
2017-08-10 10:50:25 +02:00
|
|
|
endif
|