Re: [RFC] QEMU as Xcode project on macOS

[Christian Schoenebeck]

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