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

[Marc-André Lureau]

Hi

On Mon, Mar 6, 2023 at 2:33 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> 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.

The combinations of versions used by developers is already virtually
limitless. I don't think adding a specific upstream version/revision
to the mix is making the situation worse. It could be even the
opposite, if we manage to build an "official" static version of qemu
for example (with specific dependencies).

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

That doesn't change that policy.

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

yes, I would consider this a tier 2 support, since it aims at
developers, and not having to cover it in CI.

-- 
Marc-André Lureau