Re: [PATCH 0/4] Add meson wrap fallback for slirp & dtc

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Mar 06, 2023 at 02:19:25PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Mon, Mar 6, 2023 at 2:06 PM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> 
> > On Thu, Mar 02, 2023 at 05:18:44PM +0400, marcandre.lureau@redhat.com
> > wrote:
> > > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > >
> > > Hi,
> > >
> > > Meson "wrap" is a mechanism to build dependencies that doesn't rely on
> > git
> > > submodules and integrate external dependencies as subproject()s.
> > >
> > > This offers developpers a simpler way to build QEMU with missing system
> > > dependencies (ex, libslirp in my case), but also simplify the fallback
> > build
> > > definition of dtc/libfdt.
> >
> > Do we actually need this facility though ? We've already determined
> > that every platform we need has libslirp now, and IIUC Thomas determined
> > recently that dtc is also available everywhere we need it to be.
> >
> 
> The main benefit is for developers: you have the source code of
> QEMU-related projects with the source tree. Code navigation, debugging, or
> various build tests are easier (compilation flags, static build etc). You
> don't have to "pollute" your system with (what could be) QEMU-specific
> libraries.

That's pushing developers to use builds of 3rd party libararies
that don't actually match what our users are going to end up
deploying with though.

> > So why would we want to continue to special case these two libraries,
> > out of all the many many many other libraries we also have deps on.
> >
> 
> They are more often updated, or developped with QEMU? For the reasons I
> listed, I would welcome more wrapped subprojects.

I don't think that they actually have more frequent updates that other
libraries. In any case from QEMU's POV it doesn't matter how often upstream
does releases. We're targetting the existing versions available in the OS
and so don't want to use bleeding edge upstream releases.

This also significantly expands our testing matrix. For each library
we have the possiblity that users have the distro version vs the wrapped
version. That is many new combinations users are exposed to, that we are
realistically never going to have the bandwidth to test in CI.

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