From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org, programmingkidx@gmail.com,
Gerd Hoffmann <kraxel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [RFC] QEMU as Xcode project on macOS
Date: Wed, 9 Sep 2020 14:40:05 +0100 [thread overview]
Message-ID: <20200909134005.GN1011023@redhat.com> (raw)
In-Reply-To: <2764135.D4k31Gy3CM@silver>
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 :|
next prev parent reply other threads:[~2020-09-09 13:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 12:56 [RFC] QEMU as Xcode project on macOS Christian Schoenebeck
2020-09-09 13:30 ` Peter Maydell
2020-09-09 13:43 ` Liviu Ionescu
2020-09-09 17:32 ` Christian Schoenebeck
2020-09-09 17:45 ` Liviu Ionescu
2020-09-09 18:13 ` Daniel P. Berrangé
2020-09-09 18:56 ` Christian Schoenebeck
2020-09-09 19:03 ` Liviu Ionescu
2020-09-09 19:26 ` Christian Schoenebeck
2020-09-09 19:16 ` Peter Maydell
2020-09-09 20:13 ` Liviu Ionescu
2020-09-10 9:20 ` Paolo Bonzini
2020-09-10 10:21 ` Liviu Ionescu
2020-09-10 7:37 ` Daniel P. Berrangé
2020-09-10 9:32 ` Christian Schoenebeck
2020-09-10 9:39 ` Daniel P. Berrangé
2020-09-10 10:14 ` Christian Schoenebeck
2020-09-10 10:24 ` Liviu Ionescu
2020-09-10 10:35 ` Peter Maydell
2020-09-10 10:45 ` Daniel P. Berrangé
2020-09-10 10:56 ` Liviu Ionescu
2020-09-10 14:40 ` Christian Schoenebeck
2020-09-11 17:19 ` Paolo Bonzini
2020-09-11 17:33 ` Christian Schoenebeck
2020-09-10 10:41 ` Paolo Bonzini
2020-09-10 10:54 ` Daniel P. Berrangé
2020-09-09 13:40 ` Daniel P. Berrangé [this message]
2020-09-09 13:41 ` Thomas Huth
2020-09-09 13:44 ` Daniel P. Berrangé
2020-09-09 15:16 ` Paolo Bonzini
2020-09-09 14:40 ` Programmingkid
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200909134005.GN1011023@redhat.com \
--to=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=programmingkidx@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.