[xml] enum parameters in <commands> without group attribute

[SunSerega]

There are 180 of these:
enum_without_group.txt
P.S. This might become outdated again, here is an auto-updating version.
(I only counted parameters with GLenum or GLbitfield type)

I'm not entirely sure if it's worth fixing, with its scale. Because it can't really be fully automated, someone needs to check every function individually.

But I guess it should be at least documented, that you can't rely on the group attribute being there...

[oddhack]

This is something @Perksey might pick up as part of the improvements they've been working on.

[Perksey]

Ah, thanks for the ping. I'll add this to the list 👍

[Perksey]

After looking at this, I don't think this particular issue warrants a fix. It's too big of a job and involves changing a lot of historical content which likely is surrounded with lots of unknowns.

This issue may be closed as wontfix.

[oddhack]

@SunSerega are you OK doing as @Perksey suggests above?

[SunSerega]

Well, i'm okay with not fixing this for commands of deprecated extensions and such.

But from what listed here - some are from relevant extensions. And some are from core.

Maybe it makes sense to break this issue in multiple once, so that core can be fixed with more priority?

And about extension commands - i think, for it to be manageable, .xml first need to have a way to mark extension as non-relevant.

[Perksey]

Groups are not, and should not, be a requirement for the entirety of the gl.xml and are really just niceties left over from the demise of Silicon Graphics. As such, unless you personally intend to fix this issue, I don’t advise taking this further.

[SunSerega]

I'm not saying they are required for C/C++ gl header generation. And so i'm not implying in any way that khronos needs to deal with this. Group are needed only for high lvl languages binding, so, obviously, this issue should be dealt by someone who does this kind of binding.

Do you think that because it's not required for what khronos directly manages - this is not a place to make such issues? Do you know better place?

unless you personally intend to fix this

I thought i said it already, i'm going to fix everything i post when i have time. I haven't had much of it recently, with all the irl stuff... But i'm not forgetting about these issues.

It's too big of a job

And i think this is wrong way of thinking. Only result should dictate if work needs to be done, not things like amount of work or how interesting it is.

If it's too big - it needs to be broken up into smaller jobs. This is why i started suggesting things like separating core functions and starting from them.

And if you just don't want to deal with this yourself - there is no point talking about it. Though i would be interested in listening how you deal with missing groups in your own bindings, if you actually do.

[Perksey]

I'm not saying they are required for C/C++ gl header generation. And so i'm not implying in any way that khronos needs to deal with this. Group are needed only for high lvl languages binding, so, obviously, this issue should be dealt by someone who does this kind of binding.

I wasn't saying they're required for C/C++ GL header generation, I was saying they aren't required at all and Khronos acknowledges this. I maintain an OpenGL bindings library for C# (a high-level languge) and in almost every case groupings are a nicety and not a requirement - just have one big GLenum like C/C++ do and like most bindings do.

Also, if it's too big of a job for us, it is too big of a job for us no matter what way you put it. Khronos aren't gonna fix it, I (despite my best efforts) aren't gonna fix it; the groupings are only maintained by volunteers. Improper group maintenance is not an issue as it is not a requirement, so in my opinion it should not be reported as such.

Do you think that because it's not required for what khronos directly manages - this is not a place to make such issues? Do you know better place?

While this is, strictly speaking, the correctish place, I think it's probably better to minimise the flood of issues that are coming in - perhaps coalesce them into one issue in the future? You should probably just make PRs rather than open issues for it, perhaps maintain an internal to-do list like we do at the Silk Working Group. Thanks.

[SunSerega]

if it's too big of a job for us, it is too big

It would clearly be less effort then when i parsed specs and manually created groups, being unaware of .xml's. And i'm saying that breaking up into smaller jobs will help because it only seem big and scary right now, while it's a monumental list of 200+ commands.

But, again, i would do it even if you think it's too big of a job even after it's made into a structured task.

perhaps coalesce them into one issue

Well yeah, if i would again have something like 355-359 - i would combine them. I understand that i should've first found all groups like that and then posted as single issue.

perhaps maintain an internal to-do list

I already do. But, as i already said, internal to-do list can't have discussion. So please, while i think it matters to discuss meta, let's keep being on topic in issues.

If you want to go meta - again, i'm open at sunserega2@gmail.com or other places, including non-private, you name it. Besides that, i often cut my thoughts here, because i don't want to flood much of off-topic. So i may be earthier to understand each other when i'm not focusing on trying to make it short.