Here's a patch that makes the gl_API.xml "stuff" use XInclude. Right
now, only GL_EXT_framebuffer_object is handled this way. The idea is
that individual extensions (or core versions) will be put in their own
XML files. These files will then be included in a "master" file that is
used to generate the API info. There are a couple neat advantages to
doing it this way.
Right now, gl_API.xml is around 12,000 lines. For a file that is
hand-edited, that's just evil. Breaking it up into to multiple small
files should make it easier to deal with.
There is currently no way to generate a "subset" of the whole API. For
example, no hardware driver or software Mesa implements (or is likely to
ever implement) SGIS_texture4D. However, since gl_API.xml is the
authoritative source of API offsets, every libGL or stand-alone Mesa
build gets stuck with entry-points for glTexImage4DSGIS and
glTexSubImage4DSGIS. If each extension were in its own XML file, we
could have multiple API "profiles" that included different subsets of
the full API. A "kitchen sink" profile would include SGIS_texture4D,
but the "common" or "lite" profiles would not.
This can also be used to have different profiles for generating
client-side and server-side code. We may want to include GLX protocol
for NV_register_combiners on the client-side but not on the server-side.
There is, however, a catch. All of the GL API scripts (in
src/mesa/glapi) use Python's xml.sax* modules. These do not support
XInclude natively. This leaves 3 options:
1. Re-write all the code to use libxml2 (which uses DOM instead of SAX).
I tried just using libxml2's SAX interface, but it caused Python to
core dump when processing gl_API.xml. :(
2. Hand-code our own XInclude support in our classes. Yuck.
3. Use another program to process the XInclude mark-up and create a new
Since it was by far the easiest option, I picked #3. $(API) gets passed
through "xmllint --xinlcude" to process all the XInclude elements and
create API.xml. The unmodified scripts then process API.xml (instead of
So, my question is, what do people think of this approach? Is there a
4th option that I missed?
If there are no strong objections (or better ideas!), I'm going to
commit this and start ripping the less commonly used extensions (e.g.,
SGIS_texture4D, SGIX_sprite, SGIX_reference_plane, etc.) to separate XML
files. This causes me to wonder if src/mesa/glapi is still the right
place for all this to live.