On Thu, Jan 21, 2021 at 11:08:29AM +0100, Thomas Huth wrote: > On 10/01/2021 17.27, Philippe Mathieu-Daudé wrote: > > Split the current GCC build-tci job in 2, and use Clang > > compiler in the new job. > > > > Signed-off-by: Philippe Mathieu-Daudé <[email protected]> > > --- > > RFC in case someone have better idea to optimize can respin this patch. > > > > .gitlab-ci.yml | 22 ++++++++++++++++++++-- > > 1 file changed, 20 insertions(+), 2 deletions(-) > > I'm not quite sure whether we should go down this road ... if we wanted to > have full test coverage for clang, we'd need to duplicate *all* jobs to run > them once with gcc and once with clang. And that would be just overkill. > > I think we already catch most clang-related problems with the clang jobs > that we already have in our CI, so problems like the ones that you've tried > to address here should be very, very rare. So I'd rather vote for not > splitting the job here.
We can't possibly cope with the fully expanded matrix of what are theoretically possible combinations. Thus I think we should be guided by what is expected real world usage by platforms we target. Essentially for any given distro we're testing on, our primary focus should be to use the toolchain that distro will build QEMU with. IOW, for Windows and Linux distros our primary focus should be GCC, while for macOS, and *BSD, our focus should be CLang. If there are other combinations that are known to hit bugs not covered by the standard distro patterns above, we might add a few more jobs. The latter should be the exception though, otherwise our number of jobs will grow without bound. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
