Plans for MacOs overlays?

[jrhadams]

This is a great project, and exactly what I am looking for.

I was curious if you had any plans for a macos overlay in the future?

[flyx]

I'm afraid I am not working with this project currently, but I might take it up again.

Doing macOS support poses some challenges:

• Which package manager to use for dependencies? Homebrew is probably the most wide-spread one, but operates on build formulae with a backing binary cache („bottles“ as they call them). One would need to access those bottles to pull dependencies, but I have no idea how to do that outside of Homebrew.

  There's also MacPorts and Fink, I haven't checked them for a long time and don't know how up-to-date they are. And Nix itself has a binary cache of macOS binaries, of course. Since stuff is sometimes patched to fit into Nix, I'd rather avoid directly using that for non-Nix targets.

• Can we cross-compile code as a universal binary (amd64/aarch64) for macOS? I have no idea. Possibly building both architectures and then merging the results would be possible but that would require the tooling for that being available on our host.
• Can we build apps (i.e. MyThing.app) on non-macOS hosts? I think that should be doable since an .app is just a glorified folder that contains the binary, supporting data, and all dependencies. However we might need to patch the rpath of our binaries to find the dependencies inside the folder, or write a wrapper script setting LD_LIBRARY_PATH (which would be a rather dirty hack). A possible resource would be GNOME's gtk-mac-bundler which they use for bundling GTK-based binaries into a macOS .app.
• Can we do code-signing on a non-macOS host?

I think most of those challenges are solvable, but are probably more involved than hacking some bash lines. I don't think it makes sense to ignore .app and code-signing and just build the raw binary, since the use-case would mostly be „spread read-to-launch packages to end users“. So there's a lot of work to be done before it's usable, and certainly more than the current overlays needed. I don't think I want to tackle that in the near future.