It fails on a linker error otherwise. There's a bit of annoying logic
needed for pre-GLVND systems as there it's not possible to link to GLX
without dragging the whole libGL in as well, causing bad conflicts with
libGLES. Which means I can't test this on the CI yet as there CMake is
forced to version 3.5 and finding GLVND is only in 3.10.
Interesting that neither GlxApplication nor XEglApplication was actually
built on the CI. Also test all EGL applications and contexts on GLX
builds as well, as those should work there too. For GLX on EGL builds
it's a different story.
Such as Emscripten or Android. The hypothetical use case is converting
shader files directly on an Android device to debug things, or having a
Node.js build of a scene/image converter for "portability".
Static plugins can be linked to these if Magnum is built together with
Magnum Plugins in a CMake superproject and the plugins are then linked
via the MAGNUM_*CONVERTER_STATIC_PLUGINS CMake variable.
The fontconverter and distanceconverter tools cause a CMake error on
Emscripten as it's not currently possible to access the GPU through a
command-line Node.js app. On Android they work though.
It compiles on GLES2 as well, but there it hits the massive PITA of
being unable to render to LUMINANXCE formats and GL_RED formats not
really being available everywhere.
I don't have the patience to fix that, and almost nobody needs to use
ES2 platforms nowadays, so this isn't really a priority.
Except the base GL and Vulkan one. Because usually the nondeprecated
builds needs the most iterations and any builds that run after it failed
are just wasting credits.
Currently contains just one very silly Phong->PBR conversion utility,
but eventually it'll provide tools for simplifying, merging and
deduplicating materials.
Take the linux-gl, linux-vulkan and linux-nondeprecated builds as the
main sanity checks. If they pass, then the rest gets scheduled as well,
with further dependencies between them (such as WebGL2 tests being run
only if GLES3 passes).
Otherwise it often happens that until I'm able to push a fix for GCC
4.8 or an ES2-specific build failure, it already consumes 10 minutes on
15 jobs, which is quite a lot, especially for the macOS jobs.
INSTEAD IT JUST TAKES THE NEXT ARGUMENT (WHICH IS -R IN THIS CASE) AS
THE PARALLELISM VALUE, WITHOUT FAILING, AND THEN IGNORES THE FOLLOWING
VALUE (WHICH IS THE ARGUMENT TO -R), HOT FUCKING DAMN HOW DARE YOU
WRITE SUCH BROKEN COMMAND LINE PARSING FOR SUCH AN ESSENTIAL
APPLICATION!!!
Of course I discovered it only now that I *finally* managed to work
around all test failures on my new machine. FFS.
These two options were mutually exclusive, and both were doing the same
thing -- switching to EGL on desktop GL, or switching away from EGL on
GLES. That made all logic vastly more complicated than it should be, and
unfortunately it took me half a decade to realize that. The new logic is
significantly simpler everywhere.
As usual, the old options are still recognized by CMake on a deprecated
build (with a warning), and are still exposed both as CMake variables
and a preprocessor define. But the logic for them was quite complicated,
so I don't guarantee all cases are covered.
I also tried to clean up the dependent CMake options to allow building
GLX and WGL apps on GLES independently of whether EGL is used, but it's
quite a mess due to the limitations of CMake < 3.22. Build directories
that have the options switched randomly over a long time might start
misbehaving, but the initial build should work well.
Vladimír Vondruš