On Wed, 29 Jun 2022 13:41:24 +1000 Campbell Barton <ideasma...@gmail.com> wrote:
> On Wed, Jun 29, 2022 at 12:38 PM Thiago Macieira <thi...@kde.org> wrote: > > > > On Tuesday, 28 June 2022 19:00:26 PDT Campbell Barton wrote: > > > Hi, recently I was looking into dynamically loading libwayland to be > > > able to support both X11 and Wayland, without requiring libwayland. > > > For our project is currently a requirement for adopting Wayland. > > > > Simplify your problem by dynamically loading a plugin that links to > > libwayland, instead of dynamically loading libwayland. > > Right, this is an option, but a much bigger change on our end. > > > > From what I can tell there is no portable way to wrap > > > `wl_proxy_marshal_flags` see [0], > > > Using GCC's `__builtin_apply` does work but this isn't available in > > > CLANG so I'd prefer to avoid it. > > > > > The only portable way I found to handle this was to create a header > > > that needs to be included before any of the headers generated by > > > wayland-scanner (which make calls to `wl_proxy_marshal_flags`), which > > > can be replaced by a reference to a function pointer instead of > > > requiring the function to exist and link at build time. > > > > How is this different from any other function from libwayland, variadic or > > not? > > If your code isn't linking to libwayland, then it can't call any of those > > functions. Therefore, you must be using a code generator that is calling > > something other than those functions. > > Those functions are defined locally, when wayland is present - > function pointers are set which the local functions call into. > > The complication with variadic functions is there isn't a portable way > of forwarding the arguments to the dynamically loaded wayland versions > as none of them take a `va_list`. They all take either `...` or > `wl_argument`. > As the function to convert `va_list` into `wl_argument` is private, I > don't think there is a way to forward a `va_list` currently. Probably all language bindings to non-C-compatible languages have hit the same problem, which is why the parallel binding API using wl_argument was added. The code generators for non-C languages use that API instead of the variadic API. It's just that wayland-scanner itself is still using the variadic API. Instead of exposing wl_argument_from_va_list() a more "clean" solution would be to have a code generator for C using the wl_argument API. I bet several projects would be happy to use that, if they haven't implemented it already. At least personally I would be open to the idea of getting such a generator into upstream libwayland. I wonder what others would think? There are more things that might be nice to do differently from wayland-scanner, but would break the way wayland-scanner generated files are used, so needs to be either a separate tool or a separate mode in wayland-scanner. Having to generate and use a .c file in addition to headers is one such inconvenience, but I'm not sure how easy that would be to get rid of. If the new generator was written in, say, Python, like Meson is which we already use, then we'd avoid a lot of inconvenience for cross-builds if you can skip building wayland-scanner for the build architecture and then how to find that when building stuff for the host architecture. The new generator could also take the dynamic loading problem into account from the start, and offer easy ways to use custom function pointers instead of directly calling the libwayland functions. Taking the Python idea even further, libwayland could offer a Python module for parsing and validating Wayland XML files, and offer an API for writing custom code generators more easily for any language. And not just for language bindings but documentation generators, too. Thanks, pq
pgp5JehtqAe2q.pgp
Description: OpenPGP digital signature
