VTK EGL, OSMesa variants will soon be unnecessary in 9.4

[jspanchu]

Hi,

I'm a VTK developer and wanted to inform about an upcoming change which affects your build variants.

We're in the process of removing the need to compile VTK separately for GLX/OSMesa/EGL window system support starting from 9.4. I've announced the plans in our community discourse.vtk.org and the merge request is https://gitlab.kitware.com/vtk/vtk/-/merge_requests/11367.

The new change makes VTK able to compile support for all GLX, EGL and OSMesa on Linux in one build. There is also no need to have libegl/libosmesa installed at compile time. These libraries are instead loaded at runtime if necessary. The idea being that VTK will automatically fallback to libEGL/OSMesa if it fails to open an X window or fails to find a GPU capable of OpenGL.

On windows, the idea is to compile support for both Win32 OpenGL and OSMesa. Of course, it is the responsibility of the users to obtain and install libosmesa.dll.

I'm opening this so you can track changes and start a discussion.

[traversaro]

Thanks a lot, this is great!

[Tobias-Fischer]

Hi @jspanchu - now that 9.4 has landed, do you have any more information/tips how we should modify the build scripts here to reflect the upstream changes?

Also, do you think we should still have multiple variants that pull in the required run dependencies?

[larsoner]

Also, do you think we should still have multiple variants that pull in the required run dependencies?

FWIW as a consumer (mostly) of VTK, if the wheels have all the osmesa etc. baked in then I would expect conda-forge's builds to work the same way, including whatever nice OSMesa fallback magic functionality the VTK folks got working.

[jspanchu]

Hi @Tobias-Fischer I just got back. No need for multiple variants. I would suggest getting rid of osmesa and egl variants and remove all lines that have -DVTK_OPENGL_HAS_OSMESA:BOOL=XX or -DVTK_OPENGL_HAS_EGL:BOOL=XX.

I would be curious to see how it pans out when you have a PR ready.

[Tobias-Fischer]

I don’t have plans to work on this anytime soon in case someone else is interested

[larsoner]

I looked into this a tiny bit... is it worth having noqt and qt variants still (or offscreen and qt or something)? It would really simplify things from a recipe standpoint to have a single, qt-enabled build. But that pulls in all X dependencies etc. on Linux so not sure if an "offscreen optimized" build would be worth it.

I don't have a ton of experience / knowledge to offer here but from a consistency-with-pip standpoint I'd vote for trying a single, unified build with osmesa/qt/EGL and only add a "offscreen only" if it turns out to be a problem for people to use it.

[traversaro]

I looked into this a tiny bit... is it worth having noqt and qt variants still (or offscreen and qt or something)? It would really simplify things from a recipe standpoint to have a single, qt-enabled build. But that pulls in all X dependencies etc. on Linux so not sure if an "offscreen optimized" build would be worth it.
I don't have a ton of experience / knowledge to offer here but from a consistency-with-pip standpoint I'd vote for trying a single, unified build with osmesa/qt/EGL and only add a "offscreen only" if it turns out to be a problem for people to use it.

Unless someone else express the desire (and the willingness to put the effort on maintaining) the offscreen build, I totally agree in just having a single qt-enabled build. If possible, I would suggest not to add a dependency on osmesa on that build: if we enable libEGL users can already load their system mesa-based software driver, and if they really want to load explicitly osmesa at runtime, they can install the mesalib conda package, but I am not sure if it make sense to add osmesa explicitly as a dependency.