Skip to content
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

Closed
MinusGix opened this issue Jan 11, 2020 · 6 comments
Closed

Not all Enums have a group #241

MinusGix opened this issue Jan 11, 2020 · 6 comments

Comments

@MinusGix
Copy link

MinusGix commented Jan 11, 2020

(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?

@Dav1dde
Copy link
Owner

Dav1dde commented Jan 11, 2020

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.

@MinusGix
Copy link
Author

Unrelated, (or perhaps partially related?) have you seen: KhronosGroup/OpenGL-Registry#335 and, the pr of KhronosGroup/OpenGL-Registry#343

@Dav1dde
Copy link
Owner

Dav1dde commented Jan 12, 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.

@Perksey
Copy link

Perksey commented Jan 12, 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. :)

@Dav1dde
Copy link
Owner

Dav1dde commented Jan 12, 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
Copy link
Owner

Dav1dde commented Apr 5, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants