This was originally meant to be an interleave() that operates on
MeshData, but later I realized I need the same logic in duplicate(), so
turned it into a private function. Now I am pretty sure I'll be using
this function in *many* importer plugins :D
There's a lot to change with the current version -- the bloaty tuple,
the useless min/max, and compressing all the way down to 8 bits is not
desirable anymore either. The new function allows to specify a minimal
type to compress to and works also on 8- and 16-byte types, which makes
it possible to also inflate a smaller type into a larger one.
The old function is now deprecated.
And rename them to *InPlace(), since that's what they do. The original
STL variants are now deprecated wrappers over the new names. Not
adapting the test yet in order to test everything is alright.
The templated version had the unfortunate "feature" of not being able to
figure out the type when an array view or a C array got passed to it.
That led to worse-than-ideal UX and even though it's now a bit more
verbose on the implementation side, it's the preferred solution.
I spent a week (!) thinking the extra remapping array is not necessary.
Actually, it is (though with a non-shitty hashmap the allocation could
be done for both) -- this was an university assignment almost a decade
ago and it wouldn't pass if it would be wasting time.
But the english of past me was horrible. Yes.
Should make new things more discoverable, avoid confusion when a
documented API isn't there and reduce the need for maintaining multiple
separate versions of the docs.
Before, the functions didn't accept a r-value view. Now they do, and
they also still accept l-values.
However, for a proper thing I should be making those non-templated,
specialized for Float and Double and implemented using SIMD. Well,
later.
This makes it possible to:
- finally use Magnum as a CMake subproject on Windows and have your
executables not fail to run with a "DLL missing" error (and the
setting is put to cache so superprojects just implicitly make use of
that)
- run tests on Windows without having to install first
- use dynamic plugins from a CMake subproject on any platform without
having to install first or load them by filename --- and the plugin
directory is now easily discovered as relative to
libraryLocation() of the library implementing given plugin interface
No matter how broken iOS is in CMake 3.6, $<CONFIG> seems to work there,
so reducing the amount of code and putting the configure into a single
place independently of what generator or what system/build is used.
Compared to current state it always adds Debug/configure.h instead of
putting it directly to the ${CMAKE_CURRENT_BINARY_DIR}, but the
alternative would be some CMake branching again and I just removed that,
so no.
This also prepares everything for plugin libraries being put into a
central place -- the config files don't depend on their location
anymore.