CNA-BUG-195: The SDL2-only guard inspects only CNA_GRAPHICS_RENDERER, so a multi-renderer list containing an SDL3-linked family is not refused

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

Sdl2OnlyConfiguration.cmake checks the scalar CNA_GRAPHICS_RENDERER but never the CNA_GRAPHICS_RENDERERS list, so an SDL2-only build whose list includes an SDL3-linked family passes the guard meant to keep two SDL majors apart.

Identifier

CNA-BUG-195

Category

Bug

Subsystem

Build & CI

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

cmake/Sdl2OnlyConfiguration.cmake's protection against linking SDL2 and SDL3 into one binary

Expected behaviour

The guard exists to keep an SDL2-only configuration from linking SDL3 as well, because “SDL2 and SDL3 export identically named entry points ... a binary linking both leaves the SDL2 backend's calls bound to whichever library the loader reached first.” CNA supports a multi-renderer build through CNA_GRAPHICS_RENDERERS, so the guard should consider the whole compiled-in renderer set, not only the default. The SDL-availability gate already reads CNA_GRAPHICS_RENDERERS for exactly this reason.

Actual behaviour at TARGET

Sdl2OnlyConfiguration.cmake tests only if(CNA_GRAPHICS_RENDERER IN_LIST _cna_renderers_with_direct_sdl3). It never inspects CNA_GRAPHICS_RENDERERS, and RendererCombinations.cmake validates only renderer-versus-renderer pairings, not platform compatibility. A configuration with CNA_PLATFORM=SDL2, CNA_AUDIO_PLATFORM=SDL2, a default such as OPENGLES3 and CNA_GRAPHICS_RENDERERS="OPENGLES3;SDL_GPU" passes the guard and still sets CNA_SDL2_ONLY_CONFIGURATION=ON, so the very family the guard is meant to exclude is compiled in through the list.

Source locations

• cmake/Sdl2OnlyConfiguration.cmake — checks CNA_GRAPHICS_RENDERER only; sets CNA_SDL2_ONLY_CONFIGURATION
• cmake/SdlAvailability.cmake — reads CNA_GRAPHICS_RENDERERS with IN_LIST for the same families, showing the list matters
• cmake/RendererCombinations.cmake — validates renderer-vs-renderer only, no platform gate

Evidence

Checked by reading the guard, SdlAvailability.cmake (which does read the list) and RendererCombinations.cmake at 009d40f5. Executed, scoped to the guard: running cmake -P cmake/Sdl2OnlyConfiguration.cmake with CNA_PLATFORM=SDL2 CNA_AUDIO_PLATFORM=SDL2 CNA_GRAPHICS_RENDERER=OPENGLES3 CNA_GRAPHICS_RENDERERS="OPENGLES3;SDL_GPU;SDL_RENDERER" in the shared probe directory produced CNA_SDL2_ONLY_CONFIGURATION=ON with no error (cmake 3.31). The full build was not configured, so whether SDL3 is then actually linked into the SDL2 binary, or whether the list member instead fails later for a different reason, was not established.

Focused reproduction

The scoped probe above; illustrative configure line:

cmake -S . -B build \
  -DCNA_PLATFORM=SDL2 -DCNA_AUDIO_PLATFORM=SDL2 \
  -DCNA_GRAPHICS_RENDERER=OPENGLES3 \
  -DCNA_GRAPHICS_RENDERERS="OPENGLES3;SDL_GPU"
# the guard does not object, though SDL_GPU links SDL3

Current tests

Sdl2OnlyRendererGate.cmake drives the guard only through the scalar CNA_GRAPHICS_RENDERER; no case sets CNA_GRAPHICS_RENDERERS.

Regression test

Extend Sdl2OnlyRendererGate.cmake with CNA_GRAPHICS_RENDERERS containing an SDL3-linked family: the guard must refuse it, exactly as it does for the scalar. The fix is to iterate the list as SdlAvailability.cmake does.

Blast radius

Multi-renderer SDL2 builds that name an SDL3-linked renderer family in the list. Single-renderer SDL2 builds are checked by the existing scalar branch.

Workaround

In an SDL2-only build keep CNA_GRAPHICS_RENDERERS free of SDL_GPU, SDL_RENDERER, FNA3D and FREEDIRECT.