The policy makes it work for all find_package(OpenGL) calls,
possibly even in subprojects, without having to copypaste the same
OpenGL_GL_PREFERENCE override code to each.
Same as the corresponding change in Corrade, this allows each function
to explicitly specify its dependencies, making it no longer depending on
what a particular Emscripten version decides to include by default, or
forcing users to painstakingly fill the EXPORTED_FUNCTIONS array when
linking the final executable.
It also allows the code to eventually get conditionally included or not
with preprocessor branches, for example to not include environment
queries for code that won't ever access Node.js console.
Optionally, because the TestSuite-related APIs such as CompareImage
aren't even built if the TestSuite library isn't built. Is a bit
brittle, but I don't feel like adding some kind of internal option to
configure.h just for this alone.
That's a second deprecation of this API in a short while, sorry. This
variant is hopefully the final one, with the previous one I still had
the problem that it contained a verb, which implied that it'd
*transform* the SceneData in some way which (unlike combineFields(),
filterFields() etc.) it didn't, it just extracts some data in a certain
way. This would all cause problems when there are APIs that actually do
perform hierarchy flattening.
It's also moved to a new, more general Hierarchy.h header which will
contain other hierarchy-related APIs. It doesn't make sense to have a
tiny header with just a single function, especially given it doesn't
depend on any heavy headers on its own.
Besides that it also makes the UnsignedInt overloads the main ones, and
the Trade::SceneField secondary, as is already done everywhere else (and
the opposite way was just bad inheritance from flattenMeshHierarchy()
it seems).
The glTF importer plugin contains functionality that's present only in
deprecated builds (backwards compatibility for skinning mesh
attributes), which isn't causing any API signature difference but rather
a difference in behavior. So expand the docs to say it's not limited to
just APIs but features in general.
Currently contains just one very silly Phong->PBR conversion utility,
but eventually it'll provide tools for simplifying, merging and
deduplicating materials.
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.
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.
Vladimír Vondruš