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. > 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 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. -- Alex Bennée Virtualisation Tech Lead @ Linaro
