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.
On this day, MSVC linker started complaining about missing symbols like
WavImporter::doOpenData() in the WavHeaderTest. Mind you, there's
NOTHING the WavHeader.h would use from there. Neither the test. The only
thing that connects those two together is that WavHeader.h includes
WavImporter.h (probably just a leftover from the time where those two
actually depended on each other). My suspicion is that this got
triggered due to recent changes in AbstractPlugin (it's movable now) and
MSVC attempts to instantiate the destructor or whatnot, needing
references to the privately defined virtual functions. Or something. All
that while nothing from there is EVER used.
Removing the header dependency, hopefully this fixes it. Ugh.
Basically mirroring the API of Trade::AbstractImporter, as that proved
to be useful. The old crazy openSingleData() and openData(horribleStuff)
are deprecated and will be removed in a future release.
No backwards compatibility is provided for font plugins, these need to
be adapted.
It'll get used outside of the root namespace and since the callbacks tend
to be quite complex, it would be silly to require users to implement one
callback for Trade, one for Text and one for Audio, for example.
Allows the Font and FontConverter plugins be built without TARGET_GL
enabled. That was the last piece missing for making the magnum-plugins
repo completely GL-free.
The original implementation had a few problems:
- If a file callback was set, openFile() was unconditionally calling
right into doOpenData(), making it impossible for the importer to
know the original path for correctly supplying paths to additional
files. Now, if the importer supports Feature::FileCallback,
doOpenFile() is always called. It's also possible for the importer to
save the path and then just delegate to the base doOpenFile()
implementation -- it will handle the file callbacks correctly too.
- If the importer supported neither FileCallback nor OpenData and
callbacks were set, the original doOpenFile() implementation was
called without any warning or anything, doing silently a bad thing.
Now in this case setFileCallbacks() asserts -- programmer has to
check for feature support first.
- It was not possible for the file callback to indicate file opening
failure -- in general, empty files are valid, so a nullptr ArrayView
is also a valid file. Now the callback return an Optional instead.