Meson: gl dependency is extremely incomplete, and should be improved or removed

[ystreet]

Abstracting all the OpenGL silliness into a single dependency('gl') call will almost certainly only work for small/hobby projects. Anything even remotely cross-platform or complex needs to deal with all the shenanigans itself with how it needs to deal with it. e.g. They may generate their own GL headers from the XML or they need only some of the Khronos-provided headers or they need vendor-provided headers. There are also all the platforms that may or may not need to be supported (WGL, EGL, GLX, CGL, etc) and the complex combination of those the GL API's and windowing systems and compatibility layers (e.g. ANGLE on windows, or MESA's software renderer on windows/macOS).

I would propose simply removing it as it's full of FIXME's that confuse users of the API and it cannot deal with all these combinations.

[jpakkane]

Are these features something that could be made to work with extra kwargs to the dependency call or do they need something more drastic?

[ystreet]

You could attempt to add all the possible combinations to the dependency call however that will quickly get out of hand and result in a combinatorial explosion of arguments that would need to be tested separately and together. Attempting to boil down all of OpenGL into a few meson calls with any abstraction is bound to fail for any moderately-sized project due to all the corner cases and hacks and things projects might use to get around brokenness in any layer of the build process.

Just for reference, here is ~400 lines of meson.build for detecting OpenGL on Linux and Windows (only basic stuff) that would need to be replicated in python code (and more) if you really want to keep the GLDependency.

[nirbheek]

For reference, this is what libepoxy does: https://github.com/anholt/libepoxy/blob/master/meson.build#L166

I am not sure why their checks are much simpler, but it seems like there might be some benefit to consolidating the work in one place (inside meson)?

[ystreet]

Those epoxy checks are actually incomplete for the auto case when deps aren't actually installed. epoxy is also simpler because it doesn't attempt to use any translation layers or the need to check if GL headers actually work (they generate them from XML) or the need to deal with the window system in any meaningful capacity. It also doesn't support CGL or EAGL on the GL platform side and doesn't check for gbm, dispmanx, wayland, vivante, dmabuf. There are also other checks above those referenced (attempting auto option like support) as well as in the src/meson.build.

TL;DR epoxy does less.

Here's a short list of what GStreamer would need from any OpenGL dependency system:

1. Choose (yes/no/maybe) multiple OpenGL API's OpenGL vs OpenGL 3.x, vs OpenGL ES 2.x vs OpenGL ES 3.x along with their possible extensions (all in different headers)
2. Choose (yes/no/maybe) multiple OpenGL platforms (EGL, WGL, CGL, EAGL, GLX)
3. Choose (or supply) a list of window systems to use (wayland, x11, win32, cocoa, dispmanx, gbm, ios, dispmanx, android)
4. Be able to combine 1 2 and 3 in pretty much any way depending on the platform. e.g. Mesa can be built anywhere at the very least as a software renderer. The ANGLE project can translate GLES2 to DirectX on windows.
5. Be able to check for extensions (vendor specific or otherwise) like vivante, mali or dmabuf.

I really don't think there is a place for meson attempting to abstract the GL problems of all the platforms away and the current solution of assuming that OpenGL libraries are available on windows and macOS without even checking for headers is confusing.

[jpakkane]

The correct solution here is that we need to provide a way to expose a proper API for all those use cases. Possibly we could add an opengl module with custom code to specify all that which would then return a suitable dependency object. Once we have that we can add a deprecation warning for dependency('gl') and eventually make it an error.