Build Application with dependencies saved in the application's folders

[satmandu]

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

[bugaevc]

One shouldn't have to install epoll-shim and wayland manually for Owl to work.

I agree that as a user you shouldn't have to care about them (nor about XDG_RUNTIME_DIR), you should be able to just install Owl, the relevant clients, and have things work. So maybe the relevant libraries should be distributed & installed alongside Owl, a lot like an XQuartz distribution includes various X11 libraries and support files.

Ideally one could just have those relevant libraries generated during build and saved inside the app's resource folders.

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.

[satmandu]

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 DISPLAY through launchd, so one could set the location for the wayland socket in /private/tmp like XQuartz, or maybe set WAYLAND_DISPLAY to a socket directly? I'm not sure if that is possible...

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 /usr/X11. (One has to grant that was a decision made ~ 15 years ago, and as such, maybe things have changed, and also, XQuartz was an "official" Apple release, so that changes things too.)

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?

[jeremyhu]

I think that the analogy with XQuartz is apt. For X11, clients have two options:

1. Use the system-provided client libraries from /opt/X11
2. Package client-libraries with the app (eg; Gimp.app/Contents/Resources/lib/libX11.dylib)

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.

[bugaevc]

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).

Actually this should just work for Wayland too: since https://gitlab.freedesktop.org/wayland/wayland/-/commit/1b6521e695de79a838c75e6bc5feba85e8aab13a, WAYLAND_DISPLAY can simply be set to an absolute socket path.

This mostly sorts out launchd integration (still need to support picking up the launchd-provided socket in Owl), but XDG_RUNTIME_DIR is used for a lot more than just placing the Wayland sockets there. I.e., Wayland itself would work without it, but non-trivial clients would still want it for other things.

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.

Right. So I'm now thinking the answer to "how do we distribute Owl" is: in a package (.pkg) that includes base Wayland libraries, Wayland tools (the scanner, wayland-info, what else?), Owl itself, and maybe even wl-clipboard and the Weston clients as selectable install options. What do you think?

So there'd be /opt/wayland/lib/libwayland-server.dylib, /opt/wayland/bin/wl-copy, etc., while Owl.app would go into /Applications.