use GLAD to link OpenGL

[mbaetgen-wup]

Changes

• Add GLAD as vendor lib with static linking
• Replace projectM system GL dependencies with GLAD
• Remove GLEW
• Add C api function for creating projectM with an app supplied resolver for GL function pointers
• Add loader class to handle GL function pointer discovery
• Adjust SOIL2 GL discovery to integrate with projectM/GLAD
• Adjust sdl-test-ui to discover GL functions from SDL

Todo

• Re-generate GLAD with required versions / extensions (currently gl 3.3, gles 3.0, egl 1.4, wgl 1.0, no extensions, alias =true, loader=true)
• Continued testing and clean-up

Test status - OS/GL API

• GLX: ok
• GLES (Linux, Windows): ok
• WGL: ok
• EGL+GL Core Profile (Linux/Wayland): ok
• Android: ok
• Emscripten: ok (must use sdl2 proc resolver)
• MacOS: ok

Test status - framework integrations

• Gstreamer (GLX, EGL, GLES): ok
• SDL2 (GLX, EGL, WGL, GLES): ok
• SDL3: todo
• Qt: todo

[mbaetgen-wup]

@kblaschke I have been testing the glad integration. It's starting to shape up, I was able to run projectM with egl + gl core profile 3.3. Now I am looking at wrapping up the lifecycle management for the resolver. There are 2 options: Using glad with MX (multi-context) or without. Technically, the C api with projectm_create_with_opengl_load_proc(...) allows to pass a different resolver function for each projectM instance. That would require MX, the resolver to be non-static, and each gl call needs the glad context. That would mean storing the glad context somewhere, e.g. on the ProjectM class and passing it around in some way, most likely as a call argument. So question is, either keep it simple, only one resolver is allowed per process (shared by all projectM instances) or allow multi-contexts, deal with the complexity of passing the glad context around (may enable runtime detection of GL/GLES some day though).

[kblaschke]

Just keep it simple for now.

I don't think a single application would use different GL implementations within the same process. Multiple GL contexts, sure, but these would all use the same GL functions and libraries. The only use for this I can imagine would be some development test application which runs projectM on multiple backends in parallel for direct comparison, but this can easily be done with several processes as well. For end users, this is an edge case nobody really needs IMO, so a single set of functions is good for now.

Besides that, changing to multi-context would only require internal refactoring and no API changes as the resolver callback is already per-instance. I'd postpone this and only implement if there's a real-world demand for it.

[rootnotez]

Compiled and ran, with this fix. _SDL2_TARGET_TYPE appears unused, so AND test can never pass. Also, even if the conditional wasn't broken, it would only apply for Static builds.

diff --git a/cmake/SDL2Target.cmake b/cmake/SDL2Target.cmake
index a949078f8..0f0de2a6e 100644
--- a/cmake/SDL2Target.cmake
+++ b/cmake/SDL2Target.cmake
@@ -55,7 +55,7 @@ endif()

 # Temporary fix to deal with wrong include dir set by SDL2's CMake configuration.
 get_target_property(_SDL2_INCLUDE_DIR SDL2::SDL2 INTERFACE_INCLUDE_DIRECTORIES)
-if(_SDL2_INCLUDE_DIR MATCHES "(.+)/SDL2\$" AND _SDL2_TARGET_TYPE STREQUAL STATIC_LIBRARY)
+if(_SDL2_INCLUDE_DIR MATCHES "(.+)/SDL2\$")
     # Check if SDL2::SDL2 is aliased to SDL2::SDL2-static (will be the case for static-only builds)
     get_target_property(_SDL2_ALIASED_TARGET SDL2::SDL2 ALIASED_TARGET)
     if(_SDL2_ALIASED_TARGET)

Built with directions here: https://github.com/projectM-visualizer/projectm/blob/master/BUILDING-cmake.md?plain=1#L21-L26

cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_SDL_UI=ON

cmake --build . --target install --config Release

M1 Mac Air
Sequoia 15.7.2