On 7/20/2026 10:53 AM, Pierrick Bouvier wrote: > 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). >
See patch 37 (test) and 38 (comment on this test in meson.build). > 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
