Hi On Mon, Mar 6, 2023 at 2:18 PM Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Mon, 6 Mar 2023 at 10:06, Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > > On Thu, Mar 02, 2023 at 05:18:44PM +0400, marcandre.lur...@redhat.com > wrote: > > > From: Marc-André Lureau <marcandre.lur...@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. > > > > 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. > > Also, it looks like the wrap mechanism is still basically "we have > a file that indicates what the external git URL of the dependency > is and specifies a commit hash to use", it's just changing the > mechanism we use to get the source from git submodules to this > new thing. Maybe the new thing really is better -- certainly > git submodules are absolutely awful -- but we should have one > mechanism, not two. > I think we all experienced git submodules are more intrusive and may break various git workflows. wrap files may indeed point to a git URL with a revision, but they are more versatile than that and can download from released tarball instead, for example. Some projects, like glib, use both submodules and wrap files ( https://gitlab.gnome.org/GNOME/glib/-/tree/main/subprojects), there is no incompatibility with both solutions. As often, use what fits best your needs.
