On 7/23/2026 11:02 AM, Alex Bennée wrote: > Pierrick Bouvier <[email protected]> writes: > >> On 7/23/2026 8:55 AM, Alex Bennée wrote: >>> Pierrick Bouvier <[email protected]> writes: >>> >>>> 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. >>>> > <snip> >> >> The way I see it is that we offer native cross compilers (with a focus >> on debian at the moment), and the containerized ones: people have a choice. >> We can add any additional compiler name for other distros. >> Also, as Ilya mentioned before, cross compiler on fedora, for instance, >> are not providing any sysroot. So it makes them unusable in our case. > > No sysroot at all - even for compiler headers? We don't need the linux > sysroot for building softmmu tests. >
No header nor any library, a sysroot is both. I'm not sure why they implemented it this way, but that's what Ilya mentioned and that I could check (see his report on previous version that it was not working on fedora). >> So I'm not sure which other distro you would like to support that is not >> (alpine, arch, slack, other?). >> >> In all cases, just let me know what are your exact requirements (distro >> list and set of compilers) and I would be happy to make it work just as >> you expect on all those platforms. > > That's not really the point. I use Debian, partly because its range of > supported cross compilers is so great. But we don't have a > comprehensive survey of all the systems potential developers could have > and with this change we now say they have to jump through hoops to be > able to compile something when they likely have a cross-compiler > available. > > And of course non-Linux systems are far less likely to have podman or > docker available. MacOS doesn't by default, Windows? BSDs? BeOS? > I feel that it's not an impossible task, but I see there is too much resistance to remove it. I'll implement the existing -cross-cc-* options. >> >>>> 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. >>> >>> I agree the ideal is everything is dockerised for CI but there are times >>> its not practical: >>> >>> - working with very new features on bleeding edge compilers >>> - binary only toolchains for the more niche architectures >>> - unable to run any containers >>> - running the test inside containers (this is why >>> debian-all-test-cross has qemu-minimal pre-reqs) >>> >> >> The point of containerization is to hide those details in a reproducible >> recipe. For instance, we could definitely provide bleeding edge gcc to >> have the latest features. >> >> If test relies on a specific machine setup, it's basically dead code: CI >> and other devs can't run it. That's why containerization is important. > > For CI yes - but not for someone developing something and writing tests > they may never even upstream. > Thanks, Pierrick
