Correct way to access GL on both Linux and MacOS

[helenginn]

Hi meson community,

I have a problem: I have a repository that requires the GL dependency. I use GLEW to wrangle the extensions, so I have both dependencies gl and glew. I cannot find a meson.build script which successfully acquires libraries on both systems, or perhaps I have poorly installed them. on MacOS X, glew is installed via brew, and the correct gl library is the Framework version.

Option 1: method auto

On MacOS X, if I use gl = dependency('gl', method: 'auto', required: true) then it acquires a brew-installed openGL dependency, "link_args": ["/usr/local/Cellar/mesa/22.0.5_1/lib/libGL.dylib"]. However, on executing the program, it immediately crashes on the first gl-related call.

Linux build works perfectly using method: 'auto'.

Option 2: method system

On MacOS X, if I use gl = dependency('gl', method: 'system', required: true) then it acquires the .Framework version and this works perfectly.

However, on Linux, method: 'system' is not allowed at all, and meson does not execute configuration. This means I cannot even rectify this using an if statement.

Any hint in the right direction would be a great help.

[eli-schwartz]

You can check if host_machine.system() is Darwin and define gl_method = 'system', then pass it to the dependency as method: gl_method.

Although I wonder why a brew-provided gl fails? Is it just incompatible with the way glew was configured?

[helenginn]

Right, I see it. But as you say, there's no guarantee of GL shipping with the OS, so just throwing in ['-lGL'] could fail unpleasantly, right?

If I have a C compiler then I could confirm with gcc --print-file-name=libGL.so to throw back a full file path if it's found in the default system library locations, but I doubt this would work on every system or play nicely with different versions, and many people won't be using a C compiler within the meson build system anyway.

Or do we simply add '-lGL' and hope for the best, and the compiler will complain later if it cannot be found? Presumably, by that point, it won't have even found the headers if they're not present on the system, so it wouldn't even get to the point of failure.

[eli-schwartz]

Many "system" type dependencies have to check whether a library is installed rather than guaranteeing that the OS always includes it and hardcoding the flags. The dependency abstraction we use provides a self.clib_compiler attribute which provides the backend methods that power cc.find_library('GL', required: true). This also works if the project is C++ only -- a C++ compiler is clib-compatible at that low level in meson.

So for a system dependency you can do

lib = self.clib_compiler.find_library('GL', environment, [])
if lib:
    self.is_found = True
    ...

[helenginn]

So, I have attempted to make a pull request with an alteration here. It's the first time I'm submitting a pull request anywhere and I'm not a natural Python coder, but I tried to follow the contribution guidelines and hope it's alright. I would not be sure how to write a suitable unit test for this either.

[eli-schwartz]

Thanks, it looks quite decent. :)

Unittests are actually pretty easy, because they are always written as test projects using meson.build. In this case:

test cases/failing/80 gl dependency with version/meson.build

can be extended.

[helenginn]

Thanks! It is not quite obvious to me what the test should be altered to. As per your comments on the pull request, I'm expanding the range of operating systems it can attempt to find the GL library on. This means I don't know for certain if other flavours of systems listed should be expected to fail or not, as it will now depend if they ship with OpenGL. I've had a quick check, but there's no clear indication to me whether any of the remaining host systems would definitely fail.