Change Details

Add CMake option `WITH_GHOST_WAYLAND_DYNLOAD` which loads `libwayland-{egl/cursor/client}` at run-time. Needed so official releases can be built with Wayland without preventing Blender from starting on systems that don't have wayland libraries installed. Note that there was one complication with `wl_proxy_marshal_flags` which is a variadic function that doesn't have a version that takes a `va_list`. As far as I can see it's not possible to wrap these functions without resorting to overly complex & non-portable solutions. Instead a workaround that replaces functions that use variadic arguments needs to be included immediately after `<libwayland-client.h>`. Tested with gcc-12.1 and clang-13.0.1. ---- Other notes: - This wrapper library needs to be updated by hand, although the core of Wayland used by Blender is quite small (20 functions & 15 interfaces). Generated API's such as tablet-support make use of existing primitive functions, so supporting additional extension API's isn't likely to increase the number of API calls. If it's important I could look into extracting the API's. - I was hoping to make this more generic (similar to `extern/sdlew` for example), however the workaround needed for `wl_proxy_marshal_flags` made it more difficult to keep this as an isolated module. If it could be done neatly I'd still be interested to split this out into a stand-alone module.

Add CMake option `WITH_GHOST_WAYLAND_DYNLOAD` which loads `libwayland-{egl/cursor/client}` at run-time. Needed so official releases can be built with Wayland without preventing Blender from starting on systems that don't have wayland libraries installed. Note that there was one complication with `wl_proxy_marshal_flags` which is a variadic function that doesn't have a version that takes a `va_list`. As far as I can see it's not possible to wrap these functions without resorting to overly complex & non-portable solutions. Instead a workaround that replaces functions that use variadic arguments needs to be included immediately after `<libwayland-client.h>`. Tested with gcc-12.1 and clang-13.0.1. ---- Other notes: - This wrapper library needs to be updated by hand, although the core of Wayland used by Blender is quite small (20 functions & 15 interfaces). Generated API's such as tablet-support make use of existing primitive functions, so supporting additional extension API's isn't likely to increase the number of API calls. It may still be good to updating this wrapper automatically from headers. - I was hoping to make this more generic (similar to `extern/sdlew` for example), however the workaround needed for `wl_proxy_marshal_flags` made it more difficult to keep this as an isolated module. If it could be done neatly I'd still be interested to split this out into a stand-alone module.

Add CMake option `WITH_GHOST_WAYLAND_DYNLOAD` which loads `libwayland-{egl/cursor/client}` at run-time. Needed so official releases can be built with Wayland without preventing Blender from starting on systems that don't have wayland libraries installed. Note that there was one complication with `wl_proxy_marshal_flags` which is a variadic function that doesn't have a version that takes a `va_list`. As far as I can see it's not possible to wrap these functions without resorting to overly complex & non-portable solutions. Instead a workaround that replaces functions that use variadic arguments needs to be included immediately after `<libwayland-client.h>`. Tested with gcc-12.1 and clang-13.0.1. ---- Other notes: - This wrapper library needs to be updated by hand, although the core of Wayland used by Blender is quite small (20 functions & 15 interfaces). Generated API's such as tablet-support make use of existing primitive functions, so supporting additional extension API's isn't likely to increase the number of API calls. If it's important I could look into extracting the API'sIt may still be good to updating this wrapper automatically from headers. - I was hoping to make this more generic (similar to `extern/sdlew` for example), however the workaround needed for `wl_proxy_marshal_flags` made it more difficult to keep this as an isolated module. If it could be done neatly I'd still be interested to split this out into a stand-alone module.