Re: [RFC] QEMU as Xcode project on macOS

[Daniel P . Berrangé]

On Wed, Sep 09, 2020 at 02:56:46PM +0200, Christian Schoenebeck wrote:
> I've recently been thinking about how feasible a stripped down Xcode project 
> for QEMU would be, i.e. you just get the QEMU sources, click on 
> qemu.xcodeproj, Cmd + B, done. No extra installation, no configure, nothing.
> 
> I've done this before for gtk(mm), which you might know, depends on approx. 
> 24 
> individual libraries (glib, jpeg, png, pixman, atk, gdk, cairo, pixman, 
> graphene, sigcpp, ... gtk, gtkmm) that you would usually all need to download 
> and
> 
>       ./configure && make & make install
> 
> each individually on macOS. Or right, you could alternatively "just install" 
> them from Homebrew, MacPorts, Fink. But no matter which solution you choose, 
> it easily ends up in a mess (conflicts, misbehaviours) on macOS to install 
> libs and apps globally. And I think that's the problem why there are 
> currently 
> relatively little contribution for QEMU coming from devs on macOS. Because 
> you 
> don't want to install things globally on a macOS system, it's simply not 
> working well there as it does with Linux distros.
> 
> And the other thing is: I've tested the waters with Apple and filed a QEMU 
> related macOS bug with them. The response was like expected; they basically 
> said 'if there's no Xcode project, then we don't investigate it'.
> 
> The question is, and I don't have the big picture of QEMU yet to judge that, 
> how much is auto generated for QEMU i.e. with custom scripts that would 
> probably destroy this plan? There are these trace calls that are auto 
> generated, is there more like the TCG part for instance?
> 
> What I could imagine: a hand crafted Xcode project as a starting point, and 
> if  
> that works out, switching to auto generating that Xcode project from the 
> Meson 
> inftrastructure to avoid multiplication of maintenance effort.

The current way we generate a makefile from ninja output is not our
long term desired approach. Eventually the intent is that we should
be able to use  meson + ninja exclusively.

The ninja -> make convertor we currently rely on introduces maint
problems of its own. So I don't think we want to introduce a
ninja -> Xcode converter, as that is still effectively giving us
1 + 1/2 different build systems, so is a new maint burden.

Ideally any xcode setup would just invoke whatever our standard
build tools are IMHO, so it has zero possibility of introducing
new build problems.


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