I assume you eventually plan to target binaries that don't already exist on Linux? Where do you think you'll start?
Well, of course, most of all I would like to achieve full-fledged support for Xcode Tools (including building iOS applications) and the macOS version of Homebrew. But, of course, there is still a lot of work ahead to get to this point. Thank you!
I would look at osxcross[0] if you haven't looked into it already. It can at least do the "build stuff targeting macos" part (well, relatively speaking). Swift support kinda breaks down, unfortunately, and actually getting it set up is a bit of a hassle. but it does work.
Would be nice to have a "sanity check the resulting binary" tool though like you can use Wine for Windows builds.
And it’s an endlessly moving target, look at how many apps break every major release (and use it to justify regular, expensive paid upgrades)
That's true. But if we can achieve support for the current stable version, it will be much easier to add new features later or rework the ones that were replaced (unless Apple changes everything on purpose :)
Historically, I’d say that the chances of this being successful are exceptionally low given how large the ABI surface is — and it will wildly change out from underneath you on a near yearly cadence.
Perhaps LLMs change that calculation. I really couldn’t say.
I'm curious: how large is it really? As I understand it, Kakehashi is targeting command line programs, especially Xcode-tools. How much non-POSIX/Mach/BSD interface do Mac command line programs use? How much of that is not already open source. How much of that changes yearly? The only thing that comes to mind is process security for codesign and notarization but I'm just guessing.
The Xcode Tools are written by Apple to run on Macs; they have no reason to avoid internal APIs, and when dealing with App Store-related concerns, they probably do use them heavily.
Even React Native tools used by tons of companies struggle to keep up with Xcode build tool changes on mac itself.