Is critically needed for the GltfImporter now, as the per-data importer
state is not useful on its own anymore and needs the Utility::Json
instance as well. And doing the same for AnyImageImporter as well for
feature parity.
Such a hopeful test coverage, almost there, and yet it doesn't test
everything. It now uses 1D, 2D and 3D KTX2 files with levels taken
directly from KtxImporter tests, the original 1d.ktx2 and 3d.ktx2 are
moved to AnyImageConverter test where they are used to verify metadata
presence.
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.
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.
And prefere to use it onver OpenEXR in most AnyImage{Converter,Importer}
tests, unless the test really needs something that only OpenEXR has
(such as the verbose output for threads or configuration that needs to
be set on both export and import to make the import succeed).
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.
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.
The current testing workflow had quite a few major flaws and it was no
longer possible after the move of Any* plugins to core. Among the flaws
is:
* Every plugin was basically built twice, once as the real plugin and
once as a static testing library. Most of the build shared common
object files, but nevertheless it inflated build times and made the
buildsystem extremely complex.
* Because the actual plugin binary was never actually loaded during the
test, it couldn't spot problems like:
- undefined references
- errors in metadata files
- mismatched plugin interface/version, missing entry points
- broken static plugin import files
* Tests that made use of independent plugins (such as TgaImageConverter
test using TgaImporter to verify the output) had a hardcoded
dependency on such plugins, making a minimal setup very hard.
* Dynamic loading of plugins from the Any* proxies was always directed
to the install location on the filesystem with no possibility to
load these directly from the build tree. That caused random ABI
mismatch crashes, or, on the other hand, if no plugins were
installed, particular portions of the codebase weren't tested at all.
Now the workflow is the following:
* Every plugin is built exactly once, either as dynamic or as static.
* The test always loads it via the plugin manager. If it's dynamic,
it's loaded straight from the build directory; if it's static, it
gets linked to the test executable directly.
* Plugins used indirectly are always served from the build directory
(if enabled) to ensure reproducibility and independence on what's
installed on the filesystem. Missing presence of these plugins causes
particular tests to be simply skipped.
* Plugins that have extensive tests for internal functionality that's
not exposed through the plugin interface are still built in two
parts, but the internal tests are simply consuming the OBJECT files
directly instead of linking to a static library.
Similarly to changes done in Magnum itself, this now generalizes the
Emscripten file bundling to Android as well and additionally makes CTest
check for file presence before running the tests.
Please note that this is not exactly backwards compatible, but as most
uses of the plugin library are without interacting with CMake, it
shouldn't be as painful, hopefully. In any case, recreate the build dir
and update your copy of Find*.cmake modules to avoid weird things
happening.
User-facing changes:
* Documentation of Find*.cmake modules converted to reStructuredText to
follow official CMake guidelines.
* The newfangled way to link the plugins is to use
MagnumPlugins::JpegImporter instead of
${MAGNUMPLUGINS_JPEGIMPORTER_LIBRARIES} and
${MAGNUMPLUGINS_JPEGIMPORTER_INCLUDE_DIRS}.
* The old ${MAGNUMPLUGINS_*_LIBRARIES} are deprecated and
just expand to MagnumPlugins::* target and are exposed only if
building with BUILD_DEPRECATED.
* The old ${MAGNUMPLUGINS_*_INCLUDE_DIRS} are removed, as the
MagnumPlugins::* targets cover that now as well.
Internal changes:
* Removed global state in favor of target-specific settings.
Vladimír Vondruš