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.
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.
I'm running out of the 400k free monthly credits and since macOS takes
50 credits per minute vs 5 for the Linux Docker, it's the obvious
candidate. ARM and Android take 10 instead of 5 and since we don't have
any ARM-specific code and the Android ES3 build doesn't run GL tests,
it's also non-essential.
Will revert this at the start of Junly.
The main part of the build time is fetching packages (where I doubt
multithreading can help anything) and running tests, which is serial to
have the output reasonably ordered. The actual build time takes less
than a half of the total time so going with the smallest resource class
instead of the medium shouldn't make that much of a difference. But it
uses half the credits, and that's what matters.
Required for Buffer::data()/subData() used by GLES3 tests. Otherwise
all the tests would have to check the Emscripten version and skip if
it's too old.
Vladimír Vondruš