Version of gl3w that generates complete stand-alone .h file

[laranzu]

For those of us who have to write code on MS Windows, it's often more convenient to have the GL command loader be all you need without relying on a system <GL/glcorearb.h>.

Attached is a modified version of gl3w_gen that adds the necessary typedefs and #defines to gl3w.h. (Plus some unnecessary commenting and replacement of tabs by spaces.) Hope it is useful, either to merge bits of code into gl3w_gen or distribute as a separate program.

gl3w_gencomplete.py.txt

[skaslev]

Hi Hugh,

Thank you for the code and for catching the missing PFNGLGETBOOLEANV function.

gl3w is meant to use the glcorearb.h file that gets downloaded besides the gl3w.h header and is working fine on Windows as is if you have gl3w/include in your include path.

I'm not convinced that inlining all needed #defines and typedefs is worth it since it might be a source of more flakiness (such as the PFNGLGETBOOLEANV case you caught). Also, imo it's better to limit gl3w just to extension loading and let glcorearb.h define the OpenGL API as it's designed for.

The tabs are there because the generated gl3w's C code follows the Linux kernel coding style. I might reconsider this since it's not the first time that this is being brought up and most Python developers (and IDEs) frown upon tabs in Python source.

Lastly, would you consider sending pull requests in the future instead of uploading complete files since it's easier to track what exactly got changed.

[skaslev]

On second look, the current version of gl3w does correctly expose glGetBooleanv.

[laranzu]

I'm not convinced that inlining all the #defines and typedefs is always worth it either, just sometimes. For my project I wanted a single header, so modified gl3w_gen. Once I'd done so, offering the code back seemed the right thing to do. You could either merge the extra code into gl3w_gen and add a CLI option to select between the two, or leave it as a separate program, or whatever else you decide.

Yes glGetBooleanenv works. I think my approach of selecting the PF--PROC typedefs out with a regex causes the problem. I'd have done better to generate them from the GL command names instead.