On 17/06/2021 12.42, Alex Bennée wrote:
Philippe Mathieu-Daudé <f4...@amsat.org> writes:
The --without-default-devices configure option removes the
'default=y' from Kconfig files. It is useful to test missing
Kconfig dependencies for users wanting to have QEMU (system)
binaries with a particular subset of machines builtin.
If a machine can be built standalone, it can certainly be
built as part of a set. So the best way to test for regressions
is to test each machine individually.
As this is painful to test manually, add CI jobs to do it [*].
Since all jobs follow the same template, to ease maintenance
we generate the jobs using the jsonnet tool, which emit a YAML
file filled with all our jobs.
Since there is no "--enable-my-config" option, we have to write
the standalone config manually, overwritting each target .mak
file in default-configs/devices/.
I'd appreciate if we could get such a --enable-config option first - that
would also be very helpful for downstream RHEL where we also modify the
default-configs with downstream-only patches.
+
+{
+ include: { "local": "/.gitlab-ci.d/standalone-jobs-template.yml" },
+
+ "alpha dp264": param_job("alpha-softmmu", "CONFIG_DP264=y"),
+ "avr arduino": param_job("avr-softmmu", "CONFIG_ARDUINO=y"),
+ "hppa dino": param_job("hppa-softmmu", "CONFIG_DINO=y"),
+ "nios2 10m50": param_job("nios2-softmmu", "CONFIG_NIOS2_10M50=y"),
+ "nios2 nommu": param_job("nios2-softmmu", "CONFIG_NIOS2_GENERIC_NOMMU=y"),
+ "or1k sim": param_job("or1k-softmmu", "CONFIG_OR1K_SIM=y"),
+ "rx gdbsim": param_job("rx-softmmu", "CONFIG_RX_GDBSIM=y", "-bios
/dev/null"),
+ "triboard": param_job("tricore-softmmu", "CONFIG_TRIBOARD=y"),
+ "xtensa sim": param_job("xtensaeb-softmmu", "CONFIG_XTENSA_SIM=y
CONFIG_SEMIHOSTING=y"),
+ "xtensa virt": param_job("xtensa-softmmu", "CONFIG_XTENSA_VIRT=y
CONFIG_SEMIHOSTING=y"),
Do we really have a plethora of users running trimmed down custom
configurations that we need to defend each of these exotic build
combinations in the CI?
I think I agree with Alex - in our CI, we should test what users really
need, and not each and every distantly possible combination.
So what I'd really would like to see:
1) Introduce a "--with-build-configs" switch (feel free to bikeshed on the
name) to the configure script that allows us to use a folder with a
different set of config files.
2) rename default-configs/ to configs/default/
3) Introduce some useful alternate config sets, e.g. configs/rhel or
configs/lean-kvm or whatever people want to use, and change some of the CI
jobs to work with those configs.
Thomas
