CNA-BUG-225: Two EasyGL comments still describe runtime GL profiles (phase P11) as future work

CNA snapshot 009d40f5  ·  Known Issues › Current bugs  ·  source links pinned to 009d40f5

EasyGLRendererDescriptor.cpp's file header and the CNA_RENDERER_SHARED_EASYGL comment in RendererCombinations.cmake say a runtime GL profile is still to come, although both files implement or record it.

Identifier

CNA-BUG-225

Category

Bug

Subsystem

Documentation & release tooling

Status

Open

Verified against

CNA 009d40f5 (009d40f5dd085c4e674d3479675fac84b12b3e0a)

Severity

Low (a triage suggestion, not a project priority)

Evidence basis

Source-verified: read at TARGET, not executed

Tests touching this area

Yes: see Current tests

Affected contract

Maintainer comments in EasyGLRendererDescriptor.cpp and cmake/RendererCombinations.cmake (EasyGL identities sharing one binary)

Expected behaviour

In-source comments describe the code beside them; they are what a maintainer reads before changing the EasyGL descriptor or the combination rules.

Actual behaviour at TARGET

The file header of EasyGLRendererDescriptor.cpp says the five identities are "told apart by the CNA_GL_PROFILE_* compile definition" and that "Making the profile itself a RUNTIME choice -- which is what would let two GL profiles coexist in one binary -- is plans/plan_runtimerenderer.md phase P11, not this task." The same file declares CreateGraphicsRendererForProfile(args, GlProfile) ("plans/plan_runtimerenderer.md P11"), and every descriptor passes its own identity's profile at run time. In cmake/RendererCombinations.cmake the comment above CNA_RENDERER_SHARED_EASYGL says two EasyGL identities in one binary would be "an ODR violation" and that "Lifting this is plans/plan_runtimerenderer.md phase P11", while cna_validate_renderer_combination records that P11 "REMOVED the rule that used to sit here"; the list is still defined and validated by scripts/check_renderer_combinations.py, but no rule reads it.

Source locations

• modules/renderers/easygl/src/EasyGLRendererDescriptor.cpp — file header versus CreateGraphicsRendererForProfile and the per-identity descriptors
• cmake/RendererCombinations.cmake — comment on CNA_RENDERER_SHARED_EASYGL versus the P11 note in cna_validate_renderer_combination
• scripts/check_renderer_combinations.py — still validates CNA_RENDERER_SHARED_EASYGL as a rule list
• docs/runtime-renderer-selection.md — CNA's own verified OPENGLES3;OPENGLES2;OPENGL33 combination

Evidence

Checked by reading at 009d40f5; not executed. CNA's own docs/runtime-renderer-selection.md lists OPENGLES3;OPENGLES2;OPENGL33;SOFTWARE;HEADLESS as a verified combination ("Three EasyGL GL profiles in one binary") and says that after phase P11 the profile branches are compiled either way. Only the comments are wrong.

Focused reproduction

No focused reproduction is known. Nothing has been invented here; the evidence above is what exists.

Current tests

scripts/check_renderer_combinations.py keeps the rule lists and the documentation in step but checks identity names, not comments.

Regression test

No test is needed; rewrite both comments, and either use or drop CNA_RENDERER_SHARED_EASYGL (updating the checker's list with it).

Blast radius

Maintainers only. A reader who trusts either comment would believe two EasyGL profiles cannot share a binary, or that the profile is a compile-time define, and could reintroduce a rule or a build-time branch that P11 removed. No runtime behaviour is affected.

Workaround

No workaround is known.