I’ve written a small C++ parser for opengl extension specs, but considering the omissions in SGI’s extension registry (see my post here about old extensions and in particular ARB_multitexture) I think I wasted my time and I will revert to parsing glext.h instead.
Is anyone interested by the parser’s source code, or should I just delete the files?
Julien.
I forgot to say why it does:
It takes a stream (std::istream, likely an ifstream of the spec file) and parse it, producing a list (std::list) of opengl tokens along with their values and a list of functions with info about their prototype.
Julien.
Hmm, mine actually parsers all the extension files directly off the registry web page itself, and produces glext.h/c files with all the extensions in there + loading/binding functions + wrappers to deal with extension absenses. The layout of the prototype pointer declaration/definitions are userdefinable too + multiple configs (for win32/linux/irix whatever).
Nobody seemed interested though, so it remains one of my personal tools.
I sympathise with you on the fact that the registry is in a bit of mess for parsing, but it can be done.
Hi
Do you use the gl*.spec files or the *.txt files for generating the headers ?
I’m thinking about writing a flex/bison parser for the *.spec files. It would parse the files and then sends the data to a dll-plugin which does the real code generation.
Because the spec files also contain various other information about the functions, e.g. alias names of core and ARB names it would be easy to support them.
With the plugin system, each user could write his own generator. As I’m using GL under Win32 with its old version 1.1 I would like to write a dll wich loads all function pointers from the opengl32.dll at runtime.
@deepmind :
if I understand correctly: You use the spec files and you generate a tonek list. Thats exactly that what I would like to do, so please don’t delete the files. I think I could use them for reference or as a base for my system. Can you mail send them via mail or do you have webspace.
@kieranatwork:
I’m also interested in your system. I remember that you posted abput your system sone time ago, but at that moment I had other worries … Would be interersting so see it working…
Bye
ScottManDeath
Originally posted by kieranatwork:
Hmm, mine actually parsers all the extension files directly off the registry web page itself, and produces glext.h/c files with all the extensions in there + loading/binding functions + wrappers to deal with extension absenses. The layout of the prototype pointer declaration/definitions are userdefinable too + multiple configs (for win32/linux/irix whatever).
Nobody seemed interested though, so it remains one of my personal tools.
I sympathise with you on the fact that the registry is in a bit of mess for parsing, but it can be done.
I would like that. Post it on a webpage.
Your tool looks very complete.
I have been looking a good ext maker for linux. There are a few people that provide extensions for linux, but I always need to fix a few things, specially for NV_vertex_array_range.
Originally posted by kieranatwork:
Hmm, mine actually parsers all the extension files directly off the registry web page itself, and produces glext.h/c files with all the extensions in there + loading/binding functions + wrappers to deal with extension absenses. The layout of the prototype pointer declaration/definitions are userdefinable too + multiple configs (for win32/linux/irix whatever).
I was planning to release the same kind of tool, but it cannot be done since there are too big omissions in the registry (e.g. ARB/multitexture.txt does not contain infos about ARB_multitexture any more, and it’s not the lone extension affected)
I sympathise with you on the fact that the registry is in a bit of mess for parsing, but it can be done.
My parser is functional. I had no problem parsing the registry.
Julien.
Originally posted by ScottManDeath:
Do you use the gl*.spec files or the *.txt files for generating the headers ?
The .txt.
if I understand correctly: You use the spec files and you generate a tonek list. Thats exactly that what I would like to do, so please don’t delete the files. I think I could use them for reference or as a base for my system. Can you mail send them via mail or do you have webspace.
I’ve put the code at http://files.brainlex.com/pub/brainlex3d/opengl%20ext%20parser/
Julien.
Hi
THX 
Bye
ScottManDeath
Originally posted by deepmind:
[b] My parser is functional. I had no problem parsing the registry.
Julien.[/b]
Mmm, there are some function definitions (such as wglAllocateMemoryNV) which are embedded in the ‘description’ sections of the specs, as far as I remember - this makes things a little awkward (I’m not using any external tools like bison).
The ommitted extensions such as multitexture can easily just be added manually by creating your own mini spec files for them, and appending those files after parsing the web site…bit of a frig, but it works fine considering there’s so few ommitted extensions.
I’ll tidy it up and post it on our website when I get chance.
Originally posted by kieranatwork:
[…]
there are some function definitions (such as wglAllocateMemoryNV) which are embedded in the ‘description’ sections of the specs
[…]
The ommitted extensions such as multitexture can easily just be added manually by creating your own mini spec files for them
This makes it impossible to get a real fully automated process: that’s why I’m reverting to parse glext.h, wglext.h, and glxext.h: every needed info is in there, and the grammar is much more consistent then the one from the registry specs files.
Julien.