The one place for your designs
To enable design management, you'll need to meet the requirements. If you need help, reach out to our support team for assistance.
Simulataneous requirement for code generation (wayland-scanner) and dynamic invocation (libffi) is unnecessarily roundabout, complicated, and problematic
Currently, it appears that using a wayland protocol requires code generation with wayland-scanner, and in addition internal dynamic dispatching with libffi. Why does it have to complex? In particular, while a wayland client doesn't have to care about the fact that libffi is apparently used internally, the code generation with wayland-scanner is roundabout and complicates the build system.
It's made even worse by wayland-scanner generation two parts (a header and a .c file). Also, you can't just include all the generated .c files in a single .c file (to simplify the build process), because there are completely unnecessary symbol collisions. And even much worse, the .c files are tiny, while the .h files contain significant amounts of code (like inline functions).
If libffi is already used, why require wayland-scanner? It feels like there could be a more streamlined concept for protocol support.
I suggest one of the following alternatives:
- Provide pre-built protocol libraries, like anyone else does it. (X11, Windows, Android, OSX, iOS, none require you to auto-generate code.)
- Use code-generation only. Make it simpler; generate only a .h file, or make the .h file minimal so compile time and binary code is minimized. Carefully consider impact on build systems.
- Use dynamic dispatch only.