The whole class was a bad idea, why create something that's 99% similar
to another application and has just one platform-specific workaround? Of
course it resulted in this code being completely untested and not even
built anywhere, because it served a tiny insignificant use case.
To avoid losing all the code, I did my best in attempting to merge this
into the WindowlessEglApplication. But since, again, EGL isn't
really used on any Windows platform, I can't even say it builds
properly. Maybe not even the original code built.
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
The GLES3 macOS CI build was added exactly because of this, but this
wasn't caught. Only now when I added a GLES3 macOS build for the
integration repos.
Originally I thought this was caused by the changes that happened in the
previous commit, but apparently not, and it was due to an unrelated
system upgrade I did -- the 1.2.202 Arch package had libvulkan.so link
to libpthread.so, but the 1.2.203 build not (and I couldn't reproduce
when rebuilding the 1.2.203 package from scratch, so I guess there was
some weird hiccup on the machine that used to build the package?). And
to make things worse, this caused a problem only when passing
`--magnum-device cpu` to select SwiftShader, which (unlike other
drivers, apparently) relies on pthread being linked in.
Nevertheless, Magnum should be immune against such issues same as it's
trying to be immune against Assimp regressions, so let's just link to
pthread always in the Find module, and do it via -pthread instead of
-lpthread so the same issue with the reference DCEd doesn't happen to
us.
Such as telling people Sdl2Application is not available on Android, or
that EmscriptenApplication needs WITH_EMSCRIPTENAPPLICATION enabled in
order to be built and installed.
With blackjack and actually working properly on all platforms.
Seriously, did nobody ever try to use the vanilla version on Mac or MSYS
since it was added several years ago in CMake 3.7?
Basically using the same idea as with the discrete version -- having the
second dimension dynamic, together with restricting the implementation to
just Float and Double.
According to the SubdivideRemoveDuplicatesBenchmark, this makes the
implementation slightly slower. I presume this is due to how minmax and
offsets are calculated which is quite cache-inefficient as it goes over
the same memory block multiple times. Added a TODO for later.
Same as in Corrade. Because BUILD_STATIC is independent between Corrade
and Magnum this option is also independent -- the corner cases and bad
interactions would be otherwise too complex to handle (e.g., in case of
a dynamic Corrade and static Magnum it would be impossible to enable
this option for Magnum etc etc).