[waffle] [PATCH 1/4] waffle: put waffle_enum items in a macro

[Chad Versace]

On Wed 06 May 2015, Jordan Justen wrote:
> On 2015-05-05 21:18:52, Chad Versace wrote:
> > Since the only dynamically generated portion of waffle.h (for now, at
> > least) will be the enum definitions, there's no reason to use XML if you
> > feel it's overkill. (I'm also not opposed to XML, if you do want to go
> > that route).
> 
> Chad, you worked on piglit parsing of Khronos's OpenGL XML, right?

Yes, I wrote that.

> I know that XML format might be overkill for waffle, but would it
> work? Would it be something where we could leverage the parsing code
> from piglit, and the XML format from Khronos?

The Khronos XML format isn't very suitable for Waffle's API. Its
complexity is oriented towards tracking the set of extensions, API
profiles, and API versions that defined each entrypoint and enum. And
Piglit's Python scripts are overwhelmingly complex for Waffle's use
case; after consuming the Khronos XML, the scripts then apply
workarounds, determine which similarly named entrypoints are aliases of
eachother, and sorts all items in a non-obvious way that makes dispatch
resolution order happy. 

In short, I'm not opposed to encoding Waffle's API in XML or any other
format. And there are lessons to be learned from the Khronos XML and
Piglit scripts, if one wants to venture down the path of XML. But,
attempting to actually *reuse* the Khronos XML format and Piglit's
scripts is probably more painful and less maintainable than designing
a simpler XML format from scratch.

> One thing that capturing the function prototypes might enable is the
> ability to create language bindings.

XCB does this with its XML description. The primary language binding is,
of course, C. But the project also produces Python bindings from the
same XML source. Maybe XCB's XML format has some lessons to teach us,
but I haven't yet looked at it myself.