Glad: Not all Enums have a group

Created on 11 Jan 2020 · 6Comments · Source: Dav1dde/glad

(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 #defines).

One thing I noticed while modifying the CPPGenerator(Generator) (for the most part, a direct copy of the C generator), in the write_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 group PrimitiveType, 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:

if enum.name == "GL_POINTS":
    print('{} - {}'.format(enum.name, enum.group))

Inside the for loop, and when ran it will print out:

GL_POINTS - None
GL_POINTS - None
GL_POINTS - None

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?

glad1 question

Source

MinusGix

Most helpful comment

@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.

Dav1dde on 5 Apr 2020

👍2

All 6 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.

Dav1dde on 11 Jan 2020

Unrelated, (or perhaps partially related?) have you seen: https://github.com/KhronosGroup/OpenGL-Registry/issues/335 and, the pr of https://github.com/KhronosGroup/OpenGL-Registry/pull/343

MinusGix on 11 Jan 2020

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.

Dav1dde on 12 Jan 2020

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 on 12 Jan 2020

@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!

Dav1dde on 12 Jan 2020

@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.

Dav1dde on 5 Apr 2020

👍2

Was this page helpful?

0 / 5 - 0 ratings