Somehow I find it a bit more appealing to have a proliferation of alternatives derivable
from a complete source distribution, than having the code generation scripts handle
all the scenarios.
A code generator is much easier to maintain. You way, you have to maintain a code generation system (to generate the original source) and this pre-processing system that removes the extra stuff.
Also, it’s very easy to screw up the pre-processing system due to a simple lack of the proper information. For example, how do you decide to include the enums for ARB_tessellation_shader? Remember: it’s a 4.0 core extension, so it’s very much part of 4.0+. But it’s also an extension.
The GLEW headers, for example, consider it an extension; it lives under a comment that says “GL_ARB_tessellation_shader”. No mention is made of the fact that it’s also core 4.0+ functionality and should be included in any headers that use 4.0+ regardless of whether the user asks for it or not. Without knowledge of what is and is not a core extension, your ability to get clean headers from 3.0+ with this system is diminished.
The OpenGL spec files, the source that the GLEW headers are built from, actually has this info. Enums from ARB_tessellation_shader are specifically stated to come from the extension and the version.
GLEW headers are a lossy code generation system. Generating code from such a system is probably not the best idea.
Granted, the .spec files alone don’t have enough information to do this properly either. Enums are correctly classified, but functions are not. Which is why my loader systems have to keep a manually-updated list of what the core OpenGL extensions are.
Even so, it’s still a lot easier to make this stuff from first principles than to parse someone else’s headers.
Anyway, the main suggestion I have for GL loading is to support Core context well,
it’s a long-standing limitation of GLEW.
GLEW is pretty much the only extension loader still supported today that doesn’t support core contexts. All of my styles handle core contexts.