On 1/21/21 1:02 PM, Daniel P. Berrangé wrote: > On Thu, Jan 21, 2021 at 12:48:21PM +0100, Philippe Mathieu-Daudé wrote: >> On 1/21/21 12:21 PM, Daniel P. Berrangé wrote: >>> On Thu, Jan 21, 2021 at 12:18:18PM +0100, Philippe Mathieu-Daudé wrote: >>>> On 1/21/21 11:32 AM, Daniel P. Berrangé wrote: >>>>> 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. >>>> >>>> Sounds good. >>>> >>>> Do we need a TCI job on macOS then? >>> >>> TCI is only relevant if there is no native TCG host impl. >>> >>> macOS only targets aarch64 and x86_64, both of which have TCG, so there >>> is no reason to use TCI on macOS AFAICT >> >> Yes, fine by me, but Wataru Ashihara reported the bug... ¯\_(ツ)_/¯ > > It doesn't look like they were using macOS - the message suggests > Ubuntu host, and AFAIK, all Ubuntu architectures have support > for TCG, so using TCI shouldn't have been required in the first > place. > > I guess we could benefit from a TCI job of some kind that uses > CLang on at least 1 platform, since none exists. > > This does yet again open up the question of whether we should be > supporting TCI at all in this particular user's scenario though, > since both KVM and TCG are available on Ubuntu x86 hosts already.
I understand Stefan envisions other use cases for TCI, which is why it is still maintained. See: https://www.mail-archive.com/[email protected]/msg461131.html I agree with your previous comment: > 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. This rarely used config does not justify adding yet another CI job. Thanks, Phil.
