They're each a totally different beast and putting them into the same
test file doesn't really make sense:
- We want to link certain plugins statically on static builds to test
certain code paths in the implementation. However this is
counter-productive for the executable tests because there we are
checking for plugin presence from the test with the assumption that
the executable and the test have the exact same set of plugins
available (or linked statically).
- The executable tests are implemented on Unix only at the moment,
thus it's wasteful to try to build it on any other platforms. Having
it in a separate file makes it much easier to deal with.
Because storing arbitrary data as a string was not good:
- It *never* followed alignment requirements due to the last byte being
used for size. Instead the size is now stored before the data, and
thus the data is always on the 64 byte boundary.
- As it could contain arbitrary binary data, it could cause
magnum-sceneconverter --material-info to print garbage, corrupt the
terminal or, worst case, crash. Not good.
- It stored an implicit \0, which was unnecessary.
The line segment direction length is crucial for knowing where the
intersection happens so normalizing it beforehand will have unintended
consequences. OTOH, in case of the second (non-segment) variant, the
second parameter can but doesn't have to be normalized.
It was implemented only for the Half type and not the others, and I just
felt like using it on a vector now, 12 years after the Vector class got
first added.
What was there didn't really check that the output of one converter was
used as input for the next one. Especially with the upcoming rework for
full scene conversion that could lead to dangerous regressions.
Just a minimal support to get single-mesh conversion working with
GltfSceneConverter. The whole thing has to be subsequently reworked to
not be oriented around meshes, but this is the first step.
Makes a lot of use cases significantly simpler -- apart from the trivial
"convert an OBJ to a glTF" scenario, many processing steps are about
passing most data through but only doing a pass on meshes, or images, or
materials. And this simplifies that use case quite a lot.
This is only "driver" code, with no new interfaces for the plugins. For
them it still looks like all data, their names and related metadata were
added one by one.
Also, a suprisingly large amount of code for this feature.
This was done correctly in the Find module, but here somehow not -- if
MAGNUM_TARGET_EGL is enabled, then [Windowless]GlxApplication and
GlxContext were linking to MagnumSomeContext_LIBRARY, which is EGL. Whic
is wrong. Those should always link to GLX, if it exists, and nothing if
there's just the old libGL.
Funny/sad that this possibility took me so long to realize. Until now it
was "you can have command-line utilities or static plugins but never
both", and only with CMake 3.13+ it was possible to link static plugins
to these executables from outside. Now it's a builtin and supported
option.
I'm going to add quite a few features to this one, and doing that
without any regression tests whatsoever would be a misery. Same needs to
eventually be done for the imageconverter and other utils. No bugs found
here, fortunately, except for one message update -- otherwise the
verbose output would contain (1/2) but never (2/2) which may be
confusing.
At the moment the testing is done only on Unix -- originally I wanted to
postpone this until something like Utility::System::execute() is
implemented, with proper argument escaping and output redirection, but I
simply DO NOT HAVE TIME to do that properly now. So instead it's calling
into std::system(), assumes there is no whitespace in the arguments, and
assumes a Unix shell with stdout/stderr redirection to a file. Ugly and
probably way slower than necessary, but works.
For some reason, it was adding also the magnum / magnum-d directory,
which isn't really useful, especially in cases where the directory is
not at all or it's desired to pick a debug plugin from a release
executable and vice versa.
Also the distancefieldconverter was still attempting to join with an
absolute path -- somehow 7fb63a9434 missed
this one.
I really need to write regression tests for all this, sigh.
Vladimír Vondruš