SFPEW is a C++20 CMake shared-library project. Its build includes trimmed glslang and SPIRV-Cross submodules for the GLSL translation path. A host build needs CMake, a C++20 compiler, dl, and, for the graphics smoke tests, EGL plus GLESv2 development libraries. Android builds use the Android toolchain and omit the host test executables.
git clone --recurse-submodules https://github.com/MobileGL-Dev/SimpleFPEWrapper.git
cd SimpleFPEWrapper
cmake -S . -B build -G Ninja -DSFPEW_LTO=OFF
cmake --build buildSFPEW_LTO defaults to ON for a shipping library. Turn it off for normal edit/test iteration because the translation dependencies make LTO links materially slower.
cmake -S . -B build -G Ninja -DBUILD_TESTING=ON -DSFPEW_LTO=OFF
cmake --build build
ctest --test-dir build --output-on-failureTests that create an EGL/GLES context report skip code 77 when no usable headless context exists. The pure loader/error/list tests still exercise the library boundary without a renderer. See Validation & Diagnostics for coverage categories.
SFPEW is loaded by a host that has already arranged EGL and a current context. The host obtains GL procedures from SFPEW's eglGetProcAddress (or the corresponding GLX resolver aliases), then calls those returned pointers. SFPEW resolves its backend through the host's EGL implementation; it does not call eglBindAPI, create a context, or pick GLES versus desktop GL.
For a nonstandard EGL loader, point SFPEW at the exact library before the wrapper first resolves a backend entry point:
SFPEW_EGL=/absolute/path/to/libEGL.so your-hostThis value is read once by lazy backend initialization. Changing it after the first wrapped call has no effect in that process.
The root build.gradle packages the CMake project for Android. The Android path links logging support and uses the same source-level backend contract; native CTest targets are disabled by ANDROID. The launcher/plugin remains responsible for loading the shared object early enough that its resolver functions are the ones used by the target application.
If loading succeeds but calls appear inert, first check that an EGL context is current when the application first uses a wrapped entry point. SFPEW avoids throwing across its C ABI: failure to load EGL or the required backend function table is logged and the guarded paths degrade instead of blindly calling a null pointer. Then verify the backend against Backend Profile.