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.
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:
* Not getting in the business of maintaining a distribution of all their dependencies (glib, pixman, etc.)
* Not wanting to maintain multiple build systems
both of which are non-negotiable.
What you might do is use the configure script and the ninja backend to build all generated sources (produced by either configure, meson or make); then copy those generated file over to a new build directory, invoke meson again with the xcode backend, and distribute the result so that it is ready to build from source using xcode. The resulting distribution is not appropriate to develop QEMU, but it would be okay to install it and even for some simple debugging.
The above approach still doesn't solve the problem of building glib and friends as part of the same xcode project. Perhaps this can be fixed by patching the xcodeproj that Meson generated.
The scripts needed to do so should be relatively stable and can certainly be included in the upstream QEMU sources. You can't expect that other people will test them unless you also include them somehow in our CI, but just having the scripts would be a start.
Thanks,
Paolo
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.).
Best regards,
Christian Schoenebeck