On 9/14/2026 10:16 AM, Pierrick Bouvier wrote: > On 9/14/2026 9:57 AM, Paolo Bonzini wrote: >> 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? >> > > The container build logic is introduced in patch 28. > Then, in review, it was asked to honor existing configure options, thus > they were added on top. Same for cross cflags. (patches 100-101). > >>> > 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. >> > > roms/Makefile find cross compilers by itself without relying on > config-host.mak. > If my analysis is correct, the only components that need to be fixed > are: pc-bios/vof, pc-bios/s390x, and pc-bios/optionrom. > > If it works for you, I can replicate roms/Makefile logic for cross > compilers directly for those components, which would remove the need to > reintroduce anything on configure side. > > By the way, why do those pc-bios components have not been added to roms > like the rest? >
If we go this way, I won't replicate all the cross containers logic for those pc-bios. We don't need this for roms/* and it does not seem to be a problem. I can also just revert the patch as you asked first to quickly unlock things, and discuss further if we should move those firmwares to roms/. >> Paolo >> > > Regards, > Pierrick
