An OpenGL specifications parser that outputs XML, D, etc.
Python
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
cache
README.rst
gen.py
gl.xml

README.rst

OpenGL Specifications Parser

This project is a one file Python script that parses:

It's aim is mainly to build :

  • Everything to generate bindings in one XML file
  • More complicated D bindings for GL/GLU/GLX/GLEXT in one module

F.A.Q.

Why Khronos does not provide easy-to-parse specifications ?

Khronos DOES finally provide easy-to-parse specifications as of 2013-06-13

XML specifications can be downloaded here: https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml

This quote from the OpenGL's discussion board will be left here for historical purposes :

The specs contain much more information than what is (or can be) used in the C headers. Some of it is said to be used as part of the build process for various drivers. Other parts can be used to create strongly-typed enumerations (unfortunately, functions defined after OpenGL 1.4 use generic GLenum types instead of exact enums - in OpenTK, we've fixed this by hand for every single function up to 3.2). Finally, there's stuff like glx protocol information, display-list compatibility that is simply not exposed in the C headers.

The main issue is that the .spec files change over time. New directives are being added, old ones fall in disuse or start being used inconsistently... Fortunately, things have gotten better after the 3.0 release - several long-standing bugs have been fixed and the editors seem to have gotten much more aggressive. I think the new deprecation directives have played a large part in this.

FYI, there is no problem defining the "perfect spec format" to capture all .spec information (porting everything to XML is less than a day's worth of work). The issue is that drivers have come to rely on the .spec files to build and the IHVs (rightly or not) resist any change to their build process. (No, I'm not making this up - you can search these forums for the exact quote if you wish. It was made by Jon Leech around the 3.0 release, if I remember correctly.)

The irony on the matter is this quote on the registry, added around 2007 [edit: 11/17/2006]: "Yes, these databases should be moved to a modern XML-based format. Patience." :P

Why XML instead of SWIG or any other IDL ?

XML is easy to parse and most languages provide libxml bindings or XML parsers. This way it is very easy to generate bindings for other languages even for SWIG.

License

Boost Software License - Version 1.0 - August 17, 2003

Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following:

The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.