Which makes libc++ since version 16 not use transitive includes for
backwards compatibility, both for faster build times and to detect if
some code is missing a transitive include (which could blow up for the
user even w/o this macro defined, as compiling with -std=c++23 also
removes quite a lot such includes).
This affects Android, macOS/iOS and Emscripten. On the CI right now all
VMs use older libc++, which means it does nothing, but it's done there
anyway to future-proof. Locally on Arch it affects the Android and
Emscripten builds already, as well as an explicit clang + libc++ build.
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.
I kinda get the point, to avoid rogue third parties tainting my
ŕepositories with nasty backdoors, yes, but unless *everything* on the
way to the server including DNS queries is encrypted, then it's still
just a half of the solution and any silly corporate firewall can still
prevent me from cloning stuff from github dot com.
Took me a while (several years?) to figure out a way to benchmark this
without basically duplicating the testing effort and without new
variants being too hard to add.
It's not using Android's native Vulkan library because that's only since
Android 24 and emulator for that version doesn't even start. So we use
our own minimal driver instead.
This makes it possible to:
- finally use Magnum as a CMake subproject on Windows and have your
executables not fail to run with a "DLL missing" error (and the
setting is put to cache so superprojects just implicitly make use of
that)
- run tests on Windows without having to install first
- use dynamic plugins from a CMake subproject on any platform without
having to install first or load them by filename --- and the plugin
directory is now easily discovered as relative to
libraryLocation() of the library implementing given plugin interface
Currently a separate job with everything that depends on GL disabled.
And against a minimal Vulkan driver that has just four symbols, because
I can't run the stuff there anyway.
Vladimír Vondruš