Right now, without find_package(Magnum REQUIRED), FindMagnum just
continued after the FPHSA call even if the configure file wasn't found,
leading to another error right below at file(READ).
There's also a CMake policy push/pop and the newly added early return()
would cause a PUSH happen without a corresponding POP. Move that below
to fix this.
I thought I went over all these several years ago already, but
apparently not or maybe back then not all websites were HTTPS-ready. Now
they mostly are, except for maybe one or two.
So far it contains just the uniform definitions and utilities related
to line drawing, nothing else, but especially the line utilities were
needed to be able to build MeshTools tests on a GL-less build.
SDL 2.24 started adding a SDL2::SDL2 alias, which would avoid some of the
extra branching I had to do in the Find module. Unfortunately, on CMake
before 3.18 it causes static SDL to be marked as not found because the
alias isn't an alias but rather an INTERFACE that links to
SDL2::SDL2-static, which means it doesn't have the
INTERFACE_LINK_LIBRARIES property, which it fails on.
So I'm detecting that and undoing it in order to not fail.
This involves checking if MAGNUM_BUILD_STATIC is set and deciding based
on that. Plugins don't have this treatment so far as they are a pure
runtime dependency, and the assumption is that they get built with
dependencies linked in statically. OTOH, they also need the per-plugin
configure.h read in order to support automatic plugin import, so that
bit of code is moved above alongside the other include path logic.
In short this means the users no longer need to care about FindSDL2 etc.,
it'll just get done automatically. They don't need to drag along
FindMagnum / FindCorrade anymore either, but having them gives a much
more reasonable error message if the library cannot be located at all, so
I still recommend having them.
Before, if e.g. find_package(Magnum REQUIRED Vk) was called and the
installed Magnum didn't have Magnum::Vk enabled at all, it would still
try to call find_package(Vulkan) and do all other setup which could then
fail as well, resulting in way too many noise printed.
Now the decision about the _FOUND variable is moved all the way to the
top, and the actual target setup is only done afterwards.
Microsoft should fire all versioning scheme managers and then start
over. Why a single product needs
- a marketing version that's just a year number
- a major.minor.patch marketing version because the year was too coarse
to be meaningful for anything, and that version being also completely
unrelated to the year for good measure
- a runtime library version that used to match the major.minor marketing
version a decade ago but then it somehow got out of sync
- a _MSC_VER macro that was in sync with the short marketing version
last time in 1989 and never again
- an internal build number that feels like a countermeasure to "sorry,
can't have reproducible builds so be sure to ship the artifact number
194033811, that one we tested"
Originally (2012? 2013?) I expected that there would eventually be
OpenGL ES 4.0, thus it made sense to differentiate between ES2, ES3 and
something else ES yet unknown. But as ES4 was increasingly unlikely to
happen, the internal code treated MAGNUM_TARGET_GLES3 as a simple
inverse of MAGNUM_TARGET_GLES2, and only in a very few places,
only adding confusion.
Thus it's now deprecated and defined as a simple inverse of
MAGNUM_TARGET_GLES2 on MAGNUM_TARGET_GLES builds, and none of the
internal code uses it anymore.
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.
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.
Vladimír Vondruš