Pursuant to the resolution of bug 693:
> I believe all those functions are listed in the "Dependencies on EXT_direct_state_access" section at the bottom.
Function prototypes should always be listed in the `New Procedures and Functions`. Certain spec parsing systems that pull data from the specification files (rather than the .spec files) will assume that functions are defined in the `New Procedures and Functions`.
Every other extension that has similar dependencies lists all the function prototypes there. And some specialized parsing tools work directly from the `New Procedures and Functions` section, and will therefore be broken by this change.
So at least for consistency's sake, this should be changed in the extension specification.
I have asked if we can move the DSA-style entry points out of ARB extensions
and into the EXT_dsa spec itself, which would in part address this. It
is also consistent with NVIDIA's take on these functions as belonging to
DSA. If there's agreement there will be a flock of spec updates to shuffle
DSA language out of ARB extensions and into DSA. It will probably take a
while for this to bubble to the top of the agenda.
We discussed this bug at the October 2015 f2f (Houston).
1) GLEW only returns true for an extension being supported if EVERY listed entry point is supported. This is definitely incorrect for EXT_direct_state_access where entry points advertised depends on the set of other extensions advertised. In other words, selector-free API is added by EXTdsa if the corresponding extension functionality is exposed.
2) The XML file maintained by Jon Leech @ Khronos doesn't have an attribute for functions saying what other extensions the function depends on being supported, but the consensus was that would be a good thing to have.
3) I took the action item of contacting the GLEW maintainer (Nigel) and seeing if we could have GLEW at some point support the XML file to improve this.