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.
FUCKING stupid defaults. CMake's default no less stupid. I'm MAD, why
would anybody even want to have the build run sequentially on todays
machines?! If your build is crap and can't run in parallel, FIX YOUR
CODE, but don't make the other 99% users suffer!!
It's just not worth the pain. I have to reduce the parallelism from 24
to 6, and yet it still sometimes gets stuck. And at that point it's
about twice as slow, so there's not really any gain from this costing
half the credits.
This reverts commit 9d61a63553.
This reverts commit 9c4f2ceea2.
This reverts commit 80b7694468.
Vladimír Vondruš