qemu-devel
[Top][All Lists]
Advanced

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

Re: Serious doubts about Gitlab CI


From: Daniel P . Berrangé
Subject: Re: Serious doubts about Gitlab CI
Date: Tue, 30 Mar 2021 14:09:40 +0100
User-agent: Mutt/2.0.5 (2021-01-21)

On Tue, Mar 30, 2021 at 02:09:38PM +0200, Paolo Bonzini wrote:
> On 30/03/21 13:55, Thomas Huth wrote:
> > 
> > Since the build system has been converted to meson, I think the
> > configure script prefers to use the submodules instead of the distro
> > packages. I've tried to remedy this a little bit here:
> > 
> > https://gitlab.com/qemu-project/qemu/-/commit/db0108d5d846e9a8
> > 
> > ... but new jobs of course will use the submodules again if the author
> > is not careful.
> 
> Hmm... it should be the same (or if not it's a bug).
> 
> > Also I wonder whether we could maybe even get rid of the capstone and slirp 
> > submodules in QEMU now
> 
> At least for slirp, we probably want to stay more on the bleeding edge which
> implies having to keep the submodule.  Capstone and libfdt probably can go.

I don't think we need to stay on the bleeding edge per-se in terms of
what we build against

We have a declared minimum version of libslirp that we absolutely must
have in order to get the API we need for core featureset. If new APIs
are introduced, it is quite reasonable for us to make their usage in
QEMU conditional, just as we would for any other 3rd party library we
use.

The reason to have slirp as a submodule is just to avoid a functional
regression on distros which don't have slirp available at all, and
which we don't expect to introduce it.


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]