On 7/20/2026 6:14 AM, Alex Bennée wrote:
> Pierrick Bouvier <[email protected]> writes:
>
>> Those options were useful a few years ago, before containers were
>> available as an alternative for missing cross compilers. Simplify the
>> workflow by removing those options and maintaining only the container
>> based approach.
>
I was expecting some discussion around this patch, and to start it when
the comment comes. Question is "Should we provide this feature or not?".
I totally agree with you that we need to support other configurations we
have in our CI, like MacOS and compilers from homebrew.
However, instead of implementing this by keeping --cross-* options, I
would be more keen to turn 'cc' into a list, instead of fixed choice.
For instance, instead of:
# tests/tcg/aarch64/meson.build
tcg_tests += {
'aarch64-linux-user': {
'cc': 'aarch64-linux-gnu-gcc',
...
We could have:
tcg_tests += {
'aarch64-linux-user': {
'cc': ['aarch64-linux-gnu-gcc', 'some_other_variant-gcc'],
...
I think it's a saner choice, because one problem with --cross-* is that
it allows people and maintainers to have their "own" setup, that are not
documented anywhere. By forcing compilers to be added to dockerfiles and
paths to be explicit in arch files, we make sure the same CI is
reproducible for everyone.
A good example of that is xtensaeb, which was not in docker container
file because it could be set with cross-cc-xtensaeb.
> I'm confused here - I thought we wanted to keep local cross compilers
> and provide containers as the fallback. Otherwise it will be very
> difficult to test against newer compilers without having to rebuild the
> containers.
>
That's exactly the point. By making it hard, you force by design things
to be reproductible by anyone and documented. In this case, by forcing
the people who wants a newer compiler to provide a dockerfile patch for it.
Another example is the aarch64 test with have require a bleeding gcc-16.
It's not even installable via debian repositories at the moment, it
means the test is just always skipped in CI. So basically, it's not
testing anything out of the original developer's machine who has the
"right" setup. In this case, the right fix is not rely on latest gcc,
but add manual the needed opcode so it works on any version (see patch
included in current series).
For those reasons, I'm really much more in favor to provide a default
that works out of the box, instead of "it works on my machine with a
custom configure option".
What do you think?
> Currently the MacOS build relies on local compilers built via brew.
>
Let me know which compiler is used on MacOS for cross compiling every
arch, and I can add those to next version, so it can work out of the box.
Regards,
Pierrick
