Re: [PyOpenGL-Devel] using ctypes and parsing gl.h & friends.
Brought to you by:
mcfletch
Menu
▾
▴
Re: [PyOpenGL-Devel] using ctypes and parsing gl.h & friends.
|
From: Mike C. F. <mcf...@ro...> - 2004-01-19 06:30:27
|
Rene Dudfield wrote:
...
> Made a simple 'parser' using a few regex. Which extracts the
> constants, and function prototypes from my gl.h
>
> A more generic parser would be lots better of course, however this was
> just to test the concept, and it probably will not work with most gl.h
> files. However with a little bit of modification it could work.
I've been playing about with the swig 1.3.20 xml generator, seems as
though it can produce a fairly decent XML description from the Mesa
headers. For example, here's a function from the gl.h header file:
<cdecl id="11299" addr="7f1c60" >
<attributelist id="11300" addr="7f1c60" >
<attribute name="sym_name" value="glCopyTexImage2D"
id="11301" addr="836070" />
<attribute name="name" value="glCopyTexImage2D"
id="11302" addr="836070" />
<attribute name="decl"
value="f(GLenum,GLint,GLenum,GLint,GLint,GLsizei,GLsizei,GLint)."
id="11303" addr="836070" />
<parmlist id="11304" addr="7f1820" >
<parm id="11305">
<attributelist id="11306" addr="7f1820" >
<attribute name="name" value="target"
id="11307" addr="836070" />
<attribute name="type" value="GLenum"
id="11308" addr="836070" />
</attributelist >
</parm >
<parm id="11309">
<attributelist id="11310" addr="7f18b0" >
<attribute name="name" value="level"
id="11311" addr="836070" />
<attribute name="type" value="GLint"
id="11312" addr="836070" />
</attributelist >
</parm >
<parm id="11313">
<attributelist id="11314" addr="7f1940" >
<attribute name="name"
value="internalformat" id="11315" addr="836070" />
<attribute name="type" value="GLenum"
id="11316" addr="836070" />
</attributelist >
</parm >
<parm id="11317">
<attributelist id="11318" addr="7f19d0" >
<attribute name="name" value="x" id="11319"
addr="836070" />
<attribute name="type" value="GLint"
id="11320" addr="836070" />
</attributelist >
</parm >
<parm id="11321">
<attributelist id="11322" addr="7f1a60" >
<attribute name="name" value="y" id="11323"
addr="836070" />
<attribute name="type" value="GLint"
id="11324" addr="836070" />
</attributelist >
</parm >
<parm id="11325">
<attributelist id="11326" addr="7f1af0" >
<attribute name="name" value="width"
id="11327" addr="836070" />
<attribute name="type" value="GLsizei"
id="11328" addr="836070" />
</attributelist >
</parm >
<parm id="11329">
<attributelist id="11330" addr="7f1b80" >
<attribute name="name" value="height"
id="11331" addr="836070" />
<attribute name="type" value="GLsizei"
id="11332" addr="836070" />
</attributelist >
</parm >
<parm id="11333">
<attributelist id="11334" addr="7f1c10" >
<attribute name="name" value="border"
id="11335" addr="836070" />
<attribute name="type" value="GLint"
id="11336" addr="836070" />
</attributelist >
</parm >
</parmlist >
<attribute name="storage" value="extern" id="11337"
addr="836070" />
<attribute name="type" value="void" id="11338"
addr="836070" />
<attribute name="sym_symtab" value="4e0198" id="11339"
addr="4e0198" />
<attribute name="sym_overname" value="__SWIG_0"
id="11340" addr="836070" />
</attributelist >
</cdecl >
whereas here's one from the glext.h header:
<cdecl id="36477" addr="c96660" >
<attributelist id="36478" addr="c96660" >
<attribute name="sym_name"
value="glPixelTransformParameteriEXT" id="36479" addr="d3a940" />
<attribute name="name"
value="glPixelTransformParameteriEXT" id="36480" addr="d3a940" />
<attribute name="decl" value="f(GLenum,GLenum,GLint)."
id="36481" addr="d3a940" />
<parmlist id="36482" addr="c96580" >
<parm id="36483">
<attributelist id="36484" addr="c96580" >
<attribute name="type" value="GLenum"
id="36485" addr="d3a940" />
</attributelist >
</parm >
<parm id="36486">
<attributelist id="36487" addr="c965d0" >
<attribute name="type" value="GLenum"
id="36488" addr="d3a940" />
</attributelist >
</parm >
<parm id="36489">
<attributelist id="36490" addr="c96620" >
<attribute name="type" value="GLint"
id="36491" addr="d3a940" />
</attributelist >
</parm >
</parmlist >
<attribute name="storage" value="extern" id="36492"
addr="d3a940" />
<attribute name="type" value="void" id="36493"
addr="d3a940" />
<attribute name="sym_symtab" value="4e0198" id="36494"
addr="4e0198" />
<attribute name="sym_overname" value="__SWIG_0"
id="36495" addr="d3a940" />
</attributelist >
</cdecl >
the mesa headers don't define argument names for the arguments in the
naturally-named function definitions. They do for the
PFNGLPIXELTRANSFORMPARAMETERIEXTPROC definitions, however, so that's
readily worked around. Not sure if there's a real advantage here, it
just seems like it would be a fairly robust mechanism for producing the
ctypes function wrappers.
Writing a script to process the XML into a reasonable format would seem
fairly doable. Doesn't work for the mesa_wgl.h file, btw, but that's a
pretty small and static library. Also won't run on the MS Win32 GL.h
headers, but oh well, Mesa's headers would seem fine for this kind of
task. At the least, this should get the ctypes wrappers up to the same
level as a straight run of swig over the headers would provide.
Enjoy,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
|