-
Notifications
You must be signed in to change notification settings - Fork 457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not all Enums have a group #241
Comments
Yes master branch is glad 1. The reason is, there is no group defined in the XML: <enums namespace="GL" start="0x0000" end="0x7FFF" vendor="ARB" comment="Mostly OpenGL 1.0/1.1 enum assignments. Unused ranges should generally remain unused.">
<enum value="0x0000" name="GL_POINTS"/>
<enum value="0x0001" name="GL_LINES"/> Compare with: <enums namespace="GL" start="0x8B30" end="0x8B3F" group="ShaderType" vendor="ARB">
<enum value="0x8B30" name="GL_FRAGMENT_SHADER"/>
<enum value="0x8B30" name="GL_FRAGMENT_SHADER_ARB"/>
<enum value="0x8B31" name="GL_VERTEX_SHADER"/>
<enum value="0x8B31" name="GL_VERTEX_SHADER_ARB"/>
<unused start="0x8B32" end="0x8B3F" comment="For shader types"/>
</enums> So you probably have to fallback for these enums to global defines or other methods. I recommend you to look into glad2, it may be a bit more work to get into since it is a little bit less straightforward, but this is what makes it better and easier to use in the long run. Using a template engine to generate code (jinja2) helps as well. Additionally it has a plugin system which should make it easier to hook into. |
Unrelated, (or perhaps partially related?) have you seen: KhronosGroup/OpenGL-Registry#335 and, the pr of KhronosGroup/OpenGL-Registry#343 |
I have not, thanks for bringing this to my attention. This seems like a reasonable change and should be compatible with glad. Unfortunate that I haven't been tagged originally. I'll have to update the parser for this, but this should be a minimal change and help your cause massively. |
My apologies for not tagging you in sooner, I originally only tagged the known GitHub handles of the authors in the "Language bindings" section of the Khronos website. Let me know how you get on with the new schema once it's merged in. :) |
@Perksey no worries, there is no way you'll find every tool that is out there using the specs, but that's part of the issue. Looking forward to your changes! |
@MinusGix since the Khronos MR has been merged I updated the parser accordingly in glad and glad2 and it should now report the correct enum group. |
(Note: This is from master branch, which I assume is glad-1.)
I'm currently trying to write a C++ generator for Glad (more in line with normal C++ ways of writing things, such as using
enum class name : underlying type {}
rather than many, many#define
s).One thing I noticed while modifying the
CPPGenerator(Generator)
(for the most part, a direct copy of the C generator), in thewrite_enums
method is that some enums don't have a group property even though it seems as if they should.For example:
GL_POINTS
is an entry inside of the groupPrimitiveType
, but it's group value is not set (None
), and thus I can't properly get it's group and generate the enumeration.I currently build with:
python3 -m glad --out-path=buildcpp --spec=gl --api="gl=,gles1=,gles2=" --generator=cpp
To show this, with the normal C generator:
Modify the normal C generator
write_enums
method to have:Inside the for loop, and when ran it will print out:
When ran with
python3 -m glad --out-path=buildc --spec=gl --api="gl=,gles1=,gles2=" --generator=c
Is there any obvious reason for this that I am missing, or ways to make it work as expected?
The text was updated successfully, but these errors were encountered: