From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Liviu Ionescu" <ilg@livius.net>,
"G 3" <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: Thu, 10 Sep 2020 16:40:55 +0200 [thread overview]
Message-ID: <5694401.8H58FrkmUv@silver> (raw)
In-Reply-To: <CAFEAcA_CPNppKwwJSu4O6U6qF-rfHR2NtG=hWBFatZmD4aiMdg@mail.gmail.com>
On Donnerstag, 10. September 2020 12:35:46 CEST Peter Maydell wrote:
> Does Apple (or anybody else) provide a framework for doing this
> so that developers of individual applications can just say "my
> app needs libs X, Y, Z" and they don't have to mess around
> finding, figuring out how to compile, and shipping the sources of
> libs X, Y, Z? If there's a better mechanism than Homebrew for this
> that's great, but at the moment what you seem to be saying is
> "you should do a lot more work to manually set something up where
> you ship the sources to all your dependencies and then build them
> all". There's no way we're ever going to do that, it is just
> way too much work for very little gain.
On Mac I have 'framework'ed & Xcoded the FOSS libs I need. And when I need to
compile a new FOSS lib/app that requires libs x,y,z then I just drag those
already existing Xcode projects as referenced subprojects into that new Xcode
project:
https://developer.apple.com/library/archive/documentation/ToolsLanguages/
Conceptual/Xcode_Overview/WorkingonRelatedProjects.html
For instance if I have to compile some new app that needs gtk(mm), all I need
to do is pulling in gtkmm.xcodeproj (e.g. per drag & drop) which in turn
already references all its own dependencies (subsubsub..projects) like glib,
cairo, etc. So I just click 'Run' and that's it.
And if the app triggers a crash in some of the subprojects, Xcode stops at the
precise lib's source location, you fix it, click 'Run' and you're done in
seconds. With the regular 'make' approach you would spend hours for that.
So that's a highly modular end-to-end-from-source approach. The precise
location of the individual xcode projects does not matter BTW as Xcode
references subprojects by UDID. You can move them around as you want and it
still works. No need to install them at global space, predefined structures,
or even hard coded locations, and no duplication of sources either.
I know, all this sounds very unorthodox what I am doing at first glance. But
if you think about it, all it would take is if individual FOSS projects would
start maintaining an .xcodeproj file, which in turn could then be referenced
by UUID from other FOSS project's .xcodeproj file as dependency and you would
get a low cost end-to-end-by-source solution, already on upstream level, i.e.
without the need of having dedicated projects managing "distributions".
On Donnerstag, 10. September 2020 12:41:45 CEST Paolo Bonzini wrote:
> 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:
Okay, no problem. I will see where to go from here. I am not even sure yet
whether all those source generating scripts of QEMU would be a show stopper
for what I have planned. I mean (counting): ... yes, still just 2 hands here.
If it turns out to work fine, then maybe I just push a branch of QEMU for Mac
developers somewhere for a while, as I think it would lower the entry level
for new developers on Mac tremendously. Apparently there is still more changes
with Meson ahead anyway (getting rid of the Makefiles or whatever else is
planned). So we'll see ...
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2020-09-10 14: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 [this message]
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é
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=5694401.8H58FrkmUv@silver \
--to=qemu_oss@crudebyte.com \
--cc=berrange@redhat.com \
--cc=ilg@livius.net \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=programmingkidx@gmail.com \
--cc=qemu-devel@nongnu.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).