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
XML Type Issues #717
Comments
Woops my first question seem to be a duplicate of: #679 |
Okay, those are relevant to the later half of the question. It just does not seem great to rely on values that are generated at compile time. Yea definitely makes it harder for other languages since they have to generate sane values for what the compiler/system would. However, still why are these constants marked with enum tags? While an enum can be similar to a constant it's also akin to a class. It's odd that this is different from other enums, and there is no tag marking it as such. I have read through this. https://www.khronos.org/registry/vulkan/specs/1.1/registry.html#tag-enums I don't see anything allowing such construction. Moreover the comment for this enum section even says "not an enumerated type". It's just seems like the schema could be better organized so when parsing the XML one does not have to know the enums section named "API Constants" is not really a enum. I just found the use of the type marked as a define, and this enums block inconsistent from what the schema documentation explained. |
They're marked as <enum> types because that's a legacy of the OpenGL XML schema this started with, where every GLenum is actually a compile-time constant, not an enumerant. This could stand to be changed, but changes to the schema are very disruptive to all the downstream SDK and external consumers that depend on stability of the XML, and we're cautious about doing that due to painful internal experience. We'll take this under advisement along with other feedback, but we're unlikely to do anything about it in the near future. |
N.b. the way the dependency-driven approach to generating interfaces works, the only time an "enums" block is required is when the corresponding enumerated type is being defined, and at that point it spits out all the contents of that block as the corresponding type. For a block like this one, the individual "enum" tags are required, and in that case a #define is generated. The description in registry.html could also stand to be improved as you note. |
Closing as non-actionable. The constant values are now all explicitly typed as uint32_t, uint64_t, or float which should help with FFI. Schema changes of larger scope, beyond additions such as this explicit tagging, are unlikely to happen due to disruption to us and everyone downstream from us consuming the XML. |
Why are these marked as a define?
Although, reading over the schema doc I don't see how you would describe a forward declared struct? Does the struct/union type have any thing to mark them as a forward declaration? Otherwise a separate category.
Additionally, why are these constants specified as enums if they are not an enum type? Moreover, some of these values are compile time dependent is that intended? For instance (~0U) may have a different bit width on 32 bit system vs a 64 bit system.
The text was updated successfully, but these errors were encountered: