Bug 55183

Summary:	protocol: XML files need to be installed and discoverable
Product:	Wayland	Reporter:	Pekka Paalanen <ppaalanen>
Component:	wayland	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	medium
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Pekka Paalanen 2012-09-21 08:45:17 UTC

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)

Comment 1 Mika Boström 2012-09-23 16:44:02 UTC

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.

Comment 2 Pekka Paalanen 2012-10-17 12:06:26 UTC

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.

Comment 3 Pekka Paalanen 2012-11-20 08:17:15 UTC

Looks like xwayland needs to have the same xserver.xml maintained identical in both the X server and Weston trees.

Comment 4 Tiago Vignatti 2012-11-20 12:55:25 UTC

true, XWayland needs drm.xml and xserver.xml copied there.

Comment 5 Kristian Høgsberg 2013-10-27 04:41:49 UTC

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.