From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org, "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Thomas Huth <thuth@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 12:14:23 +0200 [thread overview]
Message-ID: <4878996.4JzhbN1UZ4@silver> (raw)
In-Reply-To: <20200910093910.GG1083348@redhat.com>
On Donnerstag, 10. September 2020 11:39:10 CEST Daniel P. Berrangé wrote:
> > Well, that's actually the whole point of this thread: saving developers'
> > time. And I think the submodule solution is the most sane one.
> >
> > Frankly if you compile FOSS software on Mac that asks you to "just"
> > install
> > dependencies with Homebrew and co, it feels like you have 2 jobs: a
> > software developer, and a distribution maintainer. The difference to the
> > submodule though: a much larger amount of developers have to do that
> > maintainer job (manually resolving conflicts & crashes, rollbacks, etc.).
>
> I don't think it saves time. If you look at the bigger picture across
> multiple project it costs time. Every project that depends on glib or
> gtk or gnutls or etc reinvents the wheel figuring out a suitable
> recipe for bundling & building these dependencies. Worse is that they
> will all do it slightly differently, or use a variety of versions, and
> so users get a worse experiance too with different features available
> and different things broken. Projects like HomeBrew exist precisely to
> save developer time because these build steps can be figured out once,
> and every project can now just rely on the well maintained HomeBrew
> packages.
That only works for consumers at most.
For developers it is actually the complete opposite on Mac: you start to
install things from somewhere, then you need to install something from
somewhere else, manually build & install stuff, and you end up in conflicts
and misbehaviours all over the place.
The way to go for devs on Mac is: 3rd party libs should not be installed into
global space, rather be built & linked either as dynamic frameworks (including
assets) or as static libs. Then apps always run with the precise version and
flags of libs they were tested with and never conflict with another app's
version/config of libs.
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2020-09-10 10:15 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 [this message]
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é
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=4878996.4JzhbN1UZ4@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).