@sassy-crick Tests aren't happy since we're already using the osmesa variants as a dependency elsewhere...

Maybe @Micket or @bartoldeman can pitch in here w.r.t. the difference between the osmesa and egl variants of glew?

Well, they are different graphics interfaces. osmesa is off-screen-mesa (headless rendering, CPU only, something Mesa invented themselves and has been around for a long time). EGL is standard, used by e.g. Wayland. I've used to to achieve off-screen (and on-screen) rendering with both GPU and CPU, so, i think that's the future we want to head towards, and let OSMesa die.

Unfortunately, glew requires you to pick a backend upfront. If you have it installed on your desktop, it's almost certainly using GLX (on-screen GPU (or CPU) rendering only).
I suppose we could consider renaming libs and binaries "glewinfo_egl" and "libglewegl" or something nonstandard, which seems to be what MuJoCo does actually

# MuJoCo bundles 3 variants of glew using non-standard sonames:
# - libglew with GLX
# - libglewegl with EGL
# - libglewosmesa with OSMESA
# Softare depending on MuJoCo expect these non-standard sonames, so they should not be removed
# - libglew and libglewegl seem to work with Mesa and X11 in this toolchain
# - libglewosmesa has to be replaced as it links to an old libOSMesa

It's all pretty unfortunate, this is one thing where you'd really like all software to be able to select the "backend" at runtime, but no, they have to be specially built for one use only.
In a glorious future, i think EGL could really just replace everything. It's only downside I've seen in my experience is that it typically expects you to specify which GPU you wish to render on (making it impossible to select llvmpipe, since this (valid) option just isn't exposed). I'm also not 100% sure what happens with on-screen GUI applications over VNC with EGL (I haven't tested our Wayland packages at all..)

@Micket Thanks a lot for the detailed info!

So, how do you suggest we proceed here?
Should we add an exception to the test suite to allow for 2 variants of glew being used as a dependency in this easyconfigs generation?

yes, an exception seems fine here. Even if we could make a bunch of nonstandard libs via libglewegl, libglewosmesa, the symbols will conflict, so while modules could coexist, any libraries using these must all link to the same variant.

The only other solution is if libglew could be rewritten so support all 3 in one build.. but that's a big ask.
So, exception is the only option i think.

Thanks both for the very detailed information. These were things I did not know about it.
With the exception: is there a chance we might shoot ourselves into the foot at one point as two different programs require different versions of glew, i.e. the EGL and OSMESA one?
What I want to avoid is that in a few months we realise: that was maybe not the best way forward.
Personally, I rather have a sound solution in place, even though that might be painful to implement, than having to do constant workarounds.
Maybe something to discuss at the next EasyBuild meeting?

@sassy-crick Let's deal with that when we actually have a case like that...