Reverses this session's approach. Gating X11 out kept producing failures in a
new syntactic shape each build -- API calls, else-chains, standalone statements,
inert #ifdef guards, bare X11/xcb includes, namespace definitions -- six shapes,
each needing its own rule in gate-kx11extras.py. Providing the real headers and
libraries removes the cause rather than adding a seventh rule.
The stack was already ported and building; it was just parked in recipes/wip.
Verified before promoting: xcb-proto, libxcb, libx11, x11proto and xtrans cook
(cached from earlier builds), libxrender and libxft built successfully, and the
key headers are staged -- xcb/xcb.h, X11/Xlib.h, X11/Xft/Xft.h -- with 25 libs
and 33 headers from libxcb alone. Real upstream releases pinned by blake3
(libxcb 1.17.0, libX11 1.8.12), not stubs.
Promoted: x11proto-kb, xtrans, xcb-proto, libxcb, libx11, libxdmcp, libxext,
libxfixes, libxi, libxrender, libxft, libice, libsm (recipes/x11/) and
libpthread-stubs (recipes/libs/). x11proto was already in the config.
xcb is needed on Wayland too -- Qt's xcb platform plugin, libxkbcommon-x11 and
KDE's XWayland integration all reference it -- so this is not X11-only value.
These remain CLIENT libraries: isPlatformX11() stays false at runtime and the
X11 paths do not execute unless Xwayland is up. The port buys compilation
compatibility, not X11 functionality.
vasilito
218a1f86b0