-
Notifications
You must be signed in to change notification settings - Fork 4
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
Build Application with dependencies saved in the application's folders #11
Comments
I agree that as a user you shouldn't have to care about them (nor about
I definitely don't want building Owl to sneakily build Wayland and epoll-shim. They are the dependencies, you either install prebuilt versions, or build them beforehand. Perhaps you use a package manager like Homebrew or MacPorts, once they start shipping these libraries. If the package managers decide to start shipping Owl itself as one of the packages (which I'm not sure that they want to do), they'd make Owl have a dependency on those libraries. So the question here is really, how do we distribute Owl, and how do we distribute various Wayland clients. |
I wonder if the comparison really should be to Xquartz, which does ship all dependent libraries (X11, etc) as part of the package. The XQuartz packaging assumes that all of those other packages are built alongside, as per https://github.com/XQuartz/XQuartz/blob/master/compile.sh And I'd note that Xquartz also goes ahead and sets I would however diverge from XQuartz and install the packages inside the Owl.app folder, just like XCode does, instead of going the XQuartz route and putting all dependencies in Maybe @jeremyhu has thoughts on how package distribution for Wayland in macOS ought to be architected exclusive of a package manager which lives outside of the macos installer package ecosystem? |
I think that the analogy with XQuartz is apt. For X11, clients have two options:
I could see the appeal in "just" distributing the server-side components and leaving clients to figure it out themselves, but there is also value in providing a single distribution that others can build on top of. I think it would be best to install the client libraries to /opt/wayland. Regarding WAYLAND_DISPLAY, yeah it looks like the format of that envvar is not compatible with the way launchd works, but we could maybe introduce another envvar for wayland that is based on the path to the socket (eg: WAYLAND_DISPLAY_PATH). Recall that X11 didn't work with launchd at first either and we needed to provide patches to various parts of X11 (and libxcb) to support the new format. |
Actually this should just work for Wayland too: since https://gitlab.freedesktop.org/wayland/wayland/-/commit/1b6521e695de79a838c75e6bc5feba85e8aab13a, This mostly sorts out launchd integration (still need to support picking up the launchd-provided socket in Owl), but
Right. So I'm now thinking the answer to "how do we distribute Owl" is: in a package ( So there'd be |
One shouldn't have to install epoll-shim and wayland manually for Owl to work. Ideally one could just have those relevant libraries generated during build and saved inside the app's resource folders. This would hopefully make the app resilient to changes in those underlying libraries.
At the moment I'm only seeing dependencies on these non-system libraries:
libepoll-shim.0.dylib
libffi.8.dylib
libwayland-server.0.dylib
The text was updated successfully, but these errors were encountered: