So far, we have always had the situation, that no project needs to generate protocol bindings from a protocol extension defined in another project. Libwayland's wayland.xml is only used in libwayland, and the full protocol is exposed in the public library. Weston's special protocols are only used by Weston and its demos. Therefore we have not seen a problem yet. Except maybe for wl_drm sharing between Mesa and libva? And Qt projects? Protocol XML files need to be installed and discoverable, perhaps via pkg-config. We need to define the standard way to offer the protocol XML files for both build time and runtime. This is essential for non-C language bindings, which need to be able to find wayland.xml to generate their bindings. Interpreted or dynamic languages may need the XML files also during runtime. It is also possible, that a server will offer a public protocol extension. In that case, to be able to build clients using it, we need at least the protocol XML file. For C, we might also install the generated headers (in dev packages), but the XML file is essential, also for runtime. Also a server plugin could expose a public protocol extension. Then this plugin, which is possibly a project separate to the server, needs to install the XML file. The current situation: - no XML files are installed by libwayland nor weston. Libwayland does install wayland.xml under share/doc/, but that is perhaps for docs only? Does not sound like the right place in any case. - there is no way to find the XML files, if they were installed - the current wayland-scanner.m4 and wayland-scanner.mk files from libwayland assume that there is only a single directory for XML files in the project being built, so they do not support installed XML files at all - (OT: wayland-scanner.mk does not support non-recursive makefiles, where the generated C files should be put in a subdirectory instead of the cwd)
Just adding my 0.02€ as discussed on IRC. When we developed a custom extension for a client, our *own* developers requested that I include all the XML files in our packages, both stock and the ones we had written, for general convenience. Sure - the raw protocol descriptions are technically useless for C/C++ code where the bindings are known at build time, and code is always built against generated headers. But I can see the case for something higher-level where the core protocol is implemented statically and the server extensions are discovered at runtime.
After discussion with krh, this feature should be implemented when first needed, even though libva already duplicates Mesa's wl_drm protocol. Unless someone actually implements sharing that xml file, or any other, this is not a Wayland 1.0 item.
Looks like xwayland needs to have the same xserver.xml maintained identical in both the X server and Weston trees.
true, XWayland needs drm.xml and xserver.xml copied there.
We do this now as of 1.3 (ba90497b872720d42a63c090be24f339679c6706)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.