This would fail to build when Corrade is built w/o deprecated APIs but
Magnum is with. Rare case, but I just hit it while testing, so I guess
it's valid.
Like in Trade, the unatomic exists() + read() pair (and silent failures
if the file exists but can't be read) was replaced with just
Path::read() that now returns an Optional. Besides that, not much worth
mentioning.
Since the plugin implementations rely on the base plugin interfaces for
file handling, this affected only the tests. Also took this as an
opportunity to use the new TestSuite::Compare::StringHasPrefix etc. in
various places.
For file opening there's no longer an unatomic pair of exists() +
read(), but since Path::read() now returns an Optional, it means we can
reliably distinguish between empty files and failures.
While at it, also added TODOs for removal of the StringStl.h header
that's needed in various places for compatibility with APIs still using
STL strings.
Basically mirroring the changes done for Corrade::Compare::*File*,
including storing the filenames as string views to avoid unnecessary
copies (and then paying extra attention to not pass temporaries to them
in its own tests).
It's dangerous, as in case of failure it will attempt to print them as
strings. Plus now with latest de-std-string-ification of TestSuite it
causes the compilation to fail due to an ambigupus overload.
This should eventually be catched and disallowed directly by the Tester
class.
Similar change was done for applications long ago. They're built always
as static (as they're tiny) and original expectation was that they would
get linked just to the final executable and not any shared library, thus
not needing the -fPIC. But real-world experience was different, so I
added that. The same needs to be done for (also static) context
libraries, yet somehow I forgot until now.
Otherwise unrelated error messages such as file read failures would get
included, making the tests fail. The Debug output on the other hand
isn't used for any internal reporting.
Using a tuple was very useful, helpful and exciting as I had to make an
explicit comment about what element is what, and then having to remember
the order in all places that accessed the tuple.
Using a struct however is rather boring as the fields are just named
there, I don't need any complex std::get<4>() and extra comments
explaining what is where and it's just not so adventurous anymore. The
build time of a non-deprecated MagnumGL library also dropped from 5.9
seconds to 5.85. SAD!
All the tests were updated to explicitly check that non-null-terminated
strings get handled properly (the GL label APIs have an explicit size,
so it *should*, but just in case). Also, because various subclasses
override the setter to return correct type for method chaining and the
override has to be deinlined to avoid relying on a StringView include,
the tests are now explicitly done for each leaf class, instead of the
subclass
The <string> being removed from the base class for all GL objects may
affect downstream projects which relied on it being included. In case of
Magnum, the breakages were already fixed in the previous commit.
Compile time improvement for the MagnumGL library alone is 0.2 second or
4% (6.1 seconds before, 5.9 after). Not bad, given that there's three
more files to compile and strings are still heavily used in other GL
debug output APIs and all shader stuff. For a build of just the GL
library and all tests, it goes down from 28.9 seconds to 28.1. Most
tests also still rely quite heavily on std::stringstream for debug
output testing, so the numbers still could go further.
This used to somehow get dragged along with <string> on all platforms we
tested on, but once we get rid of <string> we'd have to include
<algorithm> instead. Not acceptable, also it's much shorter and less
error-prone this way.
It doesn't make the test any simpler, easier to understand or less
error prone, on the contrary. And it would stop testing the intended
code path once file callbacks are implemented inside the importer.
Got done in 7ced4740fd and
f3fc17e2b0 for CGL and OpenAL, but ever
since Travis decided we're not worthy of using their services, I didn't
have a chance to check the warning in the iOS build. Now I have.
It's quite easy if WEBGL_debug_renderer_info is present, but if it isn't
then our only hope is to check for ANGLE-specific extensions. Which may
cause some false positives, but since we need to enable various
workarounds for ANGLE to avoid issues, it's better than having the
detection too conservative.
The original ANGLE detection based on line size is probably not so
relevant anymore, but let's keep it there.
Vladimír Vondruš