It warns inside <type_traits> for some reason. Happens on Emscripten
5.0.2 all the way until latest 6.0.3, didn't happen on 5.0.1, and the
random Clang revision it's using isn't even released as a version 23 yet
so I can't tell if this is specific to Emscripten's filesystem layout or
is something that'll happen when building natively as well. So just omit
those few for now.
The <emscripten/version.h> header is now taken care of by Corrade's
configure.h, along with providing macro aliases for backwards
compatibility, so I can delete a lot of duplicated code everywhere.
Until now, if Magnum was found with, say,
find_package(Magnum REQUIRED DebugTools)
and then linked with
target_link_libraries(app PRIVATE Magnum::DebugTools)
the Find module correctly looked up also Corrade::PluginManager and
added it as a dependency of Magnum::DebugTools. However, DebugTools
themselves rely on the PluginManager only transitively, through Trade,
and dependency of Trade on the PluginManager isn't specified anywhere.
Which results in CMake happily putting CorradePluginManager earlier on
the linker command line than MagnumTrade, resulting in linker errors.
So instead the logic at the top is only used for finding the Corrade
dependencies, and the direct (non-transitive) dependency association
with a concrete target is done below, along with inter-Magnum-component
dependencies.
Looks like until now all find_package() calls included the other
transitive dependencies as well, so this accidentally worked. But for
example with the DebugTools reliance on SceneGraph and Primitives now
being deprecated, this may change.
And, exactly as expected, there's many cases that used the (implicit)
ValueInit while NoInit is a better choice. So yeah, minor speedups in
various places such as GL image download.
That's a too harsh behavior, as it'd break user code (instead of just
causing a bunch of warnings) when people update to a commit that
deprecates a new library.
Yes, I plan to merge audio import into Trade::AbstractImporter, but
until that's done, it feels silly to have to pay for the std::string
cruft given that it's present in just two arguments.
The code was splitting on just a whitespace before the changes in
95b3f8578d (2021), so I suppose I just
accidentally copied the same code over from handling the
--disable-extensions and --disable-workarounds arguments, where the user
*is* allowed to use any whitespaces.
And given that just a space worked well for over a decade before,
there's no reason to pessimistically expect the extension strings
suddenly include tabs or newlines.
All that work to reduce header dependencies and yet here it's full of
them, somehow.
Well, given the fallout in various GL tests now I wonder if I should
just chuck the rest along with the state allocation as a PIMPL.
This originated in 7ad928ae42 which looks
like a generic find & replace that removed all early return statements
because the unmasked renderer string on WebGL could expose both the
underlying driver (NVidia, Mesa, ...) and the wrapper (ANGLE, ...).
Ideally the compiler would warn about an unused expression, but
Optional::operator*() isn't const on mutable variables, so it didn't.
Only discovered this because I'm removing the Optional wrapper from this
member, and then the compiler started to warn.
By now I tested on GCC 4.8, various Clang versions, most MSVC versions,
building the library was without warnings on all those, and so I
expected newer GCC to be also silent when it should be. Nope. Ugh.
I wanted to just ignore these, but the RT builds for some reason have
warnings-as-error enabled by default and, UGH, I just want this thing to
finally pass the CI.
Not only the implementation is a template hell full of its own problems,
the internals are also just wrapping trivial bits of STL without adding
anything of value on top, so ultimately any code that actually used this
thing ended up being slower to build, more verbose, harder to reason
about and with thousands of tiny little inefficiencies all over the
place. So let's just finally say no to this idea from 2012.