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.
Just the stuff that touches GL functionality in some way. Which
unfortunately means all of DebugTools and SceneGraph for debug
renderers, which then pull in also all of Primitives and all of
MeshTools.
Fails spectacularly -- the geometry shader is aware only of instanced
object ID, and of vertex ID not at all. The former was a corner case
TODO while I was adding non-instanced object ID visualization in
033e56ec23 and which I kinda forgot about,
the latter was discovered while trying to fix the former.
Fix in the next commit.
With really huge materials it's kinda useless to not know which layer
the error happened in -- and usually it's exactly because the layer
indices were specified wrong.
We don't have a string-to-int API that can take non-null-terminated
string views yet, but we have this. And that's a much better fit in this
case.
This stripped further 4 kB off the release binary size (178 kB before,
158 after). Fully inlined STL containers and algorithms are a very good
idea, yes.
What a stupid idea, cuz now it's impossible to know which attribute has
which ID, so using --only-attributes is just a total guesswork,
resulting in meshes that have no positions or other nightmare scenarios.
NOT a good idea, past mosra.
By the way, removing the std::sort() stripped 16 kB off the release
binary size (178 kB before, 162 after). Fancy, C++, very fancy.
These checks covered the case when the magnum-plugins repository wasn't
installed, but didn't cover the case when it was installed but the
plugins were built against an outdated interface, had ABI issues, or
didn't load at all for various other reasons.
It was a clever harmless trick. Well, it was way more harmless than it
was clever, but even then it caused UBSan to complain. And that's Not A
Good Thing for various reasons, so let's just comply.
The main bad effect of this change is a *slightly* larger list of
exported symbols but until we actually get rid of the major bloats like
<iostream>, <string> and the like, this is not going to have any
measurable impact.
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.
Like, I can't even, why does it warn for function *definitions* for a
deprecated class which don't even use the deprecated class name anywhere
except the fully qualified name? Why does it warn here but not for, say,
ObjectData2D?
Warning that a *deprecated class* copy/move constructor/assignment is
deprecated is useless. Good thing the newer versions fixed that,
nevertheless it's still beyond annoying to see in the CI output.