Eric Farman <[email protected]> writes: > On 9/14/26 1:48 PM, 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). >> 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? > > Are there some artifacts left behind from the before times, that let > things work as they used to? I don't think the steps I'm using are > particularly weird. If I check out v11.1.0, I get... > > [qemu]# rm -rf build/ > [qemu]# mkdir build > [qemu]# cd build/ > [build]# ../configure > ...snip... > [build]# cd pc-bios/s390-ccw/ > [s390-ccw]# make > -Wno-stringop-overflow detected > -fno-stack-protector detected > -Wno-array-bounds detected > -Wno-gnu detected > -march=z900 detected > Assembling start.o > Compiling main.o > ...etc... > > Compared to the error I'd mentioned earlier. > > The best I can do to reproduce your behavior is to do the above on > v11.1.0, checkout master, re-configure, touch > /path/to/qemu/build/pc-bios/s390-ccw/Makefile, and then redo the make. > But if I do a make clean, or throw away my build directory and re-do > everything, I end up failing again. > > Having said all that, I'll happily test what you have.
I should have something posted soon. I just need to work out why the ppc vof build is failing. > > Thanks, > Eric -- Alex Bennée Virtualisation Tech Lead @ Linaro
