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>, Liviu Ionescu <ilg@livius.net>,
qemu-devel@nongnu.org, 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 10:39:10 +0100 [thread overview]
Message-ID: <20200910093910.GG1083348@redhat.com> (raw)
In-Reply-To: <2421928.3WNMogbLRJ@silver>
On Thu, Sep 10, 2020 at 11:32:35AM +0200, Christian Schoenebeck wrote:
> On Donnerstag, 10. September 2020 09:37:10 CEST Daniel P. Berrangé wrote:
> > I don't think we want to be adding more 3rd party deps as submodules, quite
> > the opposite, we want to remove more submodules we currently have.
> >
> > Bundling every important dep we use as a submodule and providing build
> > rules, means we're effectively re-inventing Homebrew / MacPorts and this is
> > not a sane use of our time.
>
> 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.
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-10 9:40 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é [this message]
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é
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=20200910093910.GG1083348@redhat.com \
--to=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=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 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).