Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plans for MacOs overlays? #2

Open
jrhadams opened this issue Jul 16, 2024 · 1 comment
Open

Plans for MacOs overlays? #2

jrhadams opened this issue Jul 16, 2024 · 1 comment

Comments

@jrhadams
Copy link

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
Copy link
Owner

flyx commented Jul 16, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants