Again, similarly to what's done for custom MeshAttribute and SceneField
values already. I'm bumping the importer interface version as adding new
virtual functions is a silent ABI breakage, but it's good to do in any
case as the AnimationTrackTarget enum was extended to 16 bits and the
values got shifted.
While UfbxImporter knows to import these directly, AssimpImporter tries
to load them as FBX and fails (heh!), and ObjImporter has no idea about
materials at all, so recognizing this extension would only add more harm
than good at the moment.
This was an annoyance with GltfImporter's customSceneFieldTypes, where
it just wasn't possible to set the options through AnySceneImporter or
magnum-sceneconverter -i argument without causing a warning to be
printed.
The behavior is now that if a plugin configuration subgroup (but not the
root group) is empty, it's assumed that new values are meant to be added
to it, and thus it doesn't warn on them.
Basically just making use of all APIs that got invented over the last 10
years, such as using instanced test cases instead of repeatedly having
the same test code with just different strings or accessing meshes
directly by name instead of meshForName().
Additionally the test files were renamed to better group them visually,
with invalid cases being separated from valid cases so it's possible to
have instanced tests for those.
When for example only CMAKE_RUNTIME_OUTPUT_DIRECTORY is set, but not the
others, the original code skipped overriding the locations altogether.
This is a valid use case, as e.g. ARCHIVE and LIBRARY_OUTPUT_DIRECTORY
tend to mess with the way Visual Studio produces and consumes *.lib
files.
Furthermore, this now also handles CMAKE_*_OUTPUT_DIRECTORY_<CONFIG> in
a similar way, which is what Conan uses for example.
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
I.e., with the intention to be implemented in the best way possible,
without relying on some 3rd party library with murky corner cases and
questionable tradeoffs.
Somehow. Heh. This causes a non-deprecated build on MSVC to break due to
a similar reason as in 54394e2c2f. And,
similarly to 3717043ae2, *again*
discovered while building bindings.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
Except for file callbacks, for these I have another change planned for
zero-copy import and it would be unwise to break stuff twice, providing
two sets of backwards compatibility wrappers. The image / scene
converter plugins went through a similar change earlier already and the
shader converters were made sane since the very beginning. OTOH audio
importers and text stuff are scheduled for merging with Trade or a
larger rework anyway, so I didn't see any point in updating those.
It's mostly a trivial change, except that returned String instances are
now also checked for non-default deleters same as Arrays because yes,
wow such flexibility compared to STL strings. Same was done for
ShaderTools::AbstractConverter already anyway, so nothing unheard-of
either.
The importer plugin interface version is bumped as this likely breaks
ABI in a nasty way that would lead to crashes.
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.
With the previous commits, existing plugin implementations built and ran
against the new code, however it introduced several ABI breaks meaning
that existing plugin binaries would crash. This forces them to be
recompiled to match the new version string.
Minor but very important convenience feature, especially useful when
dealing with command-line apps. This now works:
magnum-imageconverter a.png a.jpg -c jpegQuality=0.75
The AnyImageConverter gets the jpegQuality option and then
automatically propagates it to the concrete plugin (which is either
JpegImageConverter or StbImageConverter), possibly warning in case the
target plugin doesn't recognize given option (i.e., doesn't list it in
its default configuration). Previously the user had to always specify a
concrete converter implementation using -C, which was rather annoying
and nonintuitive.
It doesn't really work for tests that depend on more than one plugin
(because there i would need to handle all combinations, somehow), but it
does the job when the end user has such use case.
Makes more sense as the function isn't expected to fail (and thus any
kind of lazy population is not possible as it would be too late for
error checks anyway).
*Not* updating interface strings even though this is an ABI break
because we're doing that right after the skin import interface bump.
The plugin interface version got bumped to avoid ABI issues when loading
plugins that weren't updated for the change, but apart from that this
shouldn't be a breaking change, as the API returns a type that can be
both an Optional and a Pointer.
Vladimír Vondruš