qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 2/2] gitlab-ci: Add a job building TCI with Clang


From: Daniel P . Berrangé
Subject: Re: [RFC PATCH 2/2] gitlab-ci: Add a job building TCI with Clang
Date: Thu, 21 Jan 2021 12:02:41 +0000
User-agent: Mutt/1.14.6 (2020-07-11)

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é <f4bug@amsat.org>
> >>>>> ---
> >>>>> 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.


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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]