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