Enums, bitfields and wl_arrays

Bryce Harrington bryce at osg.samsung.com
Fri Oct 2 15:31:11 PDT 2015


On Fri, Oct 02, 2015 at 03:48:33PM +0300, Pekka Paalanen wrote:
> On Fri, 2 Oct 2015 12:53:13 +0100
> Auke Booij <auke at tulcod.com> wrote:
> 
> > On 1 October 2015 at 20:00, Nils Chr. Brause <nilschrbrause at gmail.com> wrote:
> 
> > > I would prefer, if the enum attributes would also name the interface,
> > > where the enum can be found, e.g.:
> > >     <arg name="format" type="uint" enum="wl_shm.format"/>
> > > If two enums in different interfaces happen to have the same name (if
> > > that's possible?), this would lead to ambiguities otherwise. Also a
> > > scanner wouldn't have to look up the interface name that way.
> > 
> > While in principle I think this is a great idea, this will need a few
> > specifications, which is why I decided not to add those in just yet.
> > Are cross-XML references allowed in this sense? In that case, the
> > scanner cannot verify their correctness, since only the current XML
> > file is available to it. Additionally, moving a certain interface from
> > xdg_shell to the core wayland protocol would now mean potentially
> > having to weaken the type safety of an interface, or having to copy
> > the enum over.
> 
> Hi,
> 
> yeah, adding the interface name makes perfect sense. It could be
> optional if wanted. No dot would mean the enum is in the same
> interface, a dot would signify a specific interface. I don't think
> there is any use for an anonymous global namespace like Bill mentioned.
> 
> As for link validity check, I could live with checking it only if the
> mentioned or implied interface is defined in the same XML file. This
> should cover most cases, and the rest would manifest as compile errors
> on non-C language bindings.
> 
> It's really all we can do anyway. XML files are perfectly allowed to
> reference interfaces defined elsewhere, even in XML files not available
> at the time.
> 
> A generator could have an extended check mode, where you can feed it a
> bunch of XML files for reference, while generating the code just for
> one, but I don't think it would be a good idea to absolutely require
> that on the XML language spec level, because it would again break old
> build systems.

Sounds like might be something worth adding to distcheck.
 
> Btw. when xdg-shell or any other new extension gets promoted to Wayland
> as stable, it will not be appended into wayland.xml. It will simply be
> yet another XML file to be installed by libwayland. Furthermore,
> libwayland will not install pre-generated C-bindings for it. All
> projects using the extension need to run wayland-scanner or any other
> generator during their build.

Do you expect that might pose problems for anyone?

Bryce


More information about the wayland-devel mailing list