On 9/14/2026 11:04 AM, Pierrick Bouvier wrote:
> 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.
>
For vdso, we could simply build them as part of tests/tcg and tcg-tests
target, without having tests associated. This way they are always built,
and people can update them by simply copying them if needed.
For firmwares, if we move pc-bios/{vof, optionroms, s390x-ccw} to roms/,
this solves the problem also.
> 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
>>
>
