On 9/14/2026 10:48 AM, Alex Bennée wrote: > Paolo Bonzini <[email protected]> writes: > >> On Mon, Sep 14, 2026 at 6:13 PM Pierrick Bouvier >> <[email protected]> wrote: >>> There might be some confusion with what the series introduced. To make >>> it clear, it does not touch, nor use tests/docker/Makefile.include. >>> >>> Each tests/tcg/arch declares which container it depends on, and we have >>> tests/tcg/meson.build that automatically builds it if needed for tests. >>> Reverting that will not be very easy to be honest, as it's a core part >>> of the new logic. >> >> If it is core, why is it patches 102...105? >> >>> > IMHO it would be nice to replace tests/docker/Makefile.include with >>>> a meson.build too. Yes, that would make it rely on a configured >>>> build tree, but IMHO that's an acceptable tradeoff to get more >>>> stuff into meson natively. >>> >>> That's easy, and would allow us to get rid of >>> tests/docker/Makefile.include completely, by adding matching targets >>> make container-image-debian-*. Also, we can have a top target >>> 'container-images'. With this, people can build them with ninja or make. >>> >>> As Daniel mentioned, the trade off is to run configure first, and I feel >>> it's quite acceptable. What do you think Paolo? >> >> The problem is that right now firmware builds are broken, because all >> the supporting code in configure was removed. I'll review anything >> that fixes it, even moving firmware builds to meson custom_targets >> even though it seems quite intrusive. > > I've reverted those three patches - so leaving the TCG tests still to > run using meson but still generating tests/tcg/$TARGET/config-target.mak > for the benefit of the firmware builds (and also vdso build which uses > the same stuff). >
If vdso rely on this, we need to keep .mak files for now. They definitely would deserve to be buildable using meson though. With the revert, we can still keep the meson options to keep existing functionality, especially cross cflags. I think it's safe to not reintroduce any container mechanic as people building vdso/firmwares can have cross compilers installed. So the partial revert is just for 102 mostly, with additional tweaks to collect cflags from 101. > However I need to test the firmware builds and its not quite clear how > to kick that off. I did try: > > cd pc-bios/s390-ccw > make > > but that works even with the current state of the tree. > > Where is the firmware build documented so I can test the patches before > I post v2 to the list? > With those commands I can reproduce the issue Eric reported. Maybe try with a fresh qemu repository (clone without submodules)? >> >> Paolo >
