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.
Using openMemory() instead of openData() allows the implementation to
assume the data will stay in scope for as long as needed, which can
prevent unnecessary copies in some plugin implementations.
It warranted a new flag, DataFlag::ExternallyOwned, to describe this
kind of memory. I couldn't reuse Owned as that's used for allocations
owned by the instance, which is too little for certain future use cases.
For example returning *Data instances referencing an Owned memory would
mean the user has to assume the memory is gone when the importer
instance is gone, and that's generally not true for memory passed to
openMemory().
Originally I thought I would do this later, but then realized the
existing plugin implementations would need to get all updated again to
be aware of the new flag, with some being forgotten, and it's just
easier to do the whole thing in a single step.
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.
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.
I need a bunch of new test images for shader tests and this was rather
easy to do, considering RLE images are ten times smaller. Not doing the
converter side yet due to time constraints, temporarily relying on
imagemagick to handle that (StbImageConverter does RLE also, but
interestingly it produces larger files than imagemagick).
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.
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.
Vladimír Vondruš