Re: [RFC] QEMU as Xcode project on macOS

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

On Thu, Sep 10, 2020 at 12:41:45PM +0200, Paolo Bonzini wrote:
> Il gio 10 set 2020, 11:32 Christian Schoenebeck <qemu_oss@crudebyte.com> ha
> scritto:
> 
> > On Donnerstag, 10. September 2020 09:37:10 CEST Daniel P. Berrangé wrote:
> > > I don't think we want to be adding more 3rd party deps as submodules,
> > quite
> > > the opposite, we want to remove more submodules we currently have.
> > >
> > > Bundling every important dep we use as a submodule and providing build
> > > rules, means we're effectively re-inventing Homebrew / MacPorts and this
> > is
> > > not a sane use of our time.
> >
> > Well, that's actually the whole point of this thread: saving developers'
> > time.
> > And I think the submodule solution is the most sane one.
> >
> 
> You're very welcome to do this, but what you're doing is effectively a
> *distribution of QEMU* that targets the "macOS build from source" scenario,
> for people that don't want to use Homebrew. It is *not* going to be used by
> QEMU developers, because QEMU developers have conflicting requirements:
> 
> * Not getting in the business of maintaining a distribution of all their
> dependencies (glib, pixman, etc.)
> 
> * Not wanting to maintain multiple build systems
> 
> both of which are non-negotiable.
> 
> What you might do is use the configure script and the ninja backend to
> build all generated sources (produced by either configure, meson or make);
> then copy those generated file over to a new build directory, invoke meson
> again with the xcode backend, and distribute the result so that it is ready
> to build from source using xcode. The resulting distribution is not
> appropriate to develop QEMU, but it would be okay to install it and even
> for some simple debugging.
> 
> The above approach still doesn't solve the problem of building glib and
> friends as part of the same xcode project. Perhaps this can be fixed by
> patching the xcodeproj that Meson generated.
> 
> The scripts needed to do so should be relatively stable and can certainly
> be included in the upstream QEMU sources. You can't expect that other
> people will test them unless you also include them somehow in our CI, but
> just having the scripts would be a start.

I'm not convinced we want to take what amounts to distribution packaging
into the main QEMU repo, as QEMU has generally stayed out of this area
leaving it to be done as downstream users/projects desire.

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