Re: [RFC] QEMU as Xcode project on macOS

[Christian Schoenebeck]

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