CNA-VGAP-015: CNA records and checks no easy-gl or meta-gl revision, although the snapshot needs meta-gl 20c8b2dc or later and easy-gl deda7a42 or later

CNA snapshot 009d40f5  ·  Known Issues › Verification gaps  ·  source links pinned to 009d40f5

EasyGLRenderer.cpp needs meta-gl's InternalFormat::Rgba16 (from 20c8b2dc) and RendererSelection.cmake relies on easy-gl's exception-model variable (from deda7a42), yet nothing pins or checks either sibling revision.

Identifier

CNA-VGAP-015

Category

Verification gap

Subsystem

Build & CI

Status

Open

Verified against

CNA 009d40f5 (009d40f5dd085c4e674d3479675fac84b12b3e0a)

Evidence basis

Source-verified: read at TARGET, not executed

Tests touching this area

None

Affected contract

GL-family builds (OPENGLES2, OPENGLES3, OPENGL33, WEBGL1, WEBGL2) consuming ../easy-gl and ../meta-gl

Expected behaviour

A build that depends on sibling features records the sibling revision it needs, or fails clearly at configure time when given an older one.

Actual behaviour at TARGET

EasyGLRenderer.cpp names ::easygl::InternalFormat::Rgba16 in several SurfaceFormat mappings (Rg32, Rgba64 and their sibling paths), unguarded by any feature test; easygl::InternalFormat is an alias of metagl::InternalFormat, whose Rgba16 enumerator first appears in meta-gl 20c8b2dc (2026-09-03), before CNA began using it on 2026-09-08. Under Emscripten RendererSelection.cmake sets EASYGL_EMSCRIPTEN_EXCEPTION_MODEL=JS with FORCE; easy-gl before deda7a42 (2026-08-22) ignores that variable and applies -fwasm-exceptions unconditionally, to itself and to meta-gl, which would mix exception ABIs with CNA's JS-lowered ABI. The build adds whatever sits at ../easy-gl and ../meta-gl; CI clones branch heads through clone_siblings.sh. The newest sibling SHAs the snapshot records (FINAL_RECONCILIATION.md: meta-gl 571d3a62, easy-gl 0b46d35c, commit dates both 2026-07-19; other integration records name older ones) predate both requirements, and that document itself says dependency resolution is sibling-path based, not a branch, commit pin, FetchContent revision or submodule.

Source locations

• modules/renderers/easygl/src/EasyGLRenderer.cpp — InternalFormat::Rgba16 uses in the render-target format mapping
• cmake/RendererSelection.cmake — EASYGL_EMSCRIPTEN_EXCEPTION_MODEL forced to JS before add_subdirectory(../easy-gl)
• cmake/BuildPerformance.cmake — cna_emscripten_exception_abi: CNA's JS-lowered exception ABI
• scripts/ci/clone_siblings.sh — branch-head cloning of easy-gl and meta-gl
• integration/FINAL_RECONCILIATION.md — the only recorded easy-gl/meta-gl SHAs

Evidence

Checked by reading at 009d40f5 and the easy-gl (develop @ deda7a42) and meta-gl (develop @ 20c8b2dc) histories in the local checkouts; nothing built. Not established: the concrete failure of a build against the recorded revisions.

Focused reproduction

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

Current tests

No configure check or test verifies a sibling revision or feature.

Regression test

Configure-time feature probes (for example check_cxx_source_compiles on metagl::InternalFormat::Rgba16, and a check that easy-gl honours EASYGL_EMSCRIPTEN_EXCEPTION_MODEL), or a recorded sibling lock that CI consumes.

Blast radius

GL-family builds from a stale sibling checkout: a compile failure (meta-gl) or, on the web, silently mixed exception ABIs (easy-gl). Builds from current sibling heads are unaffected.

Workaround

Update ../easy-gl and ../meta-gl to their develop heads before building.