These warnings were always enabled, but we didn't see them due to https://gitlab.com/OpenMW/openmw/-/issues/7882.
I do not fully understand the cause of 7822 as I can't repro it in a minimal CMake project.
Some of these fixes are thought through.
Some are sensible best guesses.
Some are kind of a stab in the dark as I don't know whether there was a
possible bug the warning was telling me about that I've done nothing to
help by introducing a static_cast.
Nearly all of these warnings were about some kind of narrowing
conversion, so I'm not sure why they weren't firing with GCC and Clang,
which have -Wall -Wextra -pedantic set, which should imply -Wnarrowing,
and they can't have been affected by 7882.
There were also some warnings being triggered from Boost code.
The vast majority of library headers that do questionable things weren't
firing warnings off, but for some reason, /external:I wasn't putting
these Boost headers into external mode.
We need these warnings dealt with one way or another so we can switch
the default Windows CI from MSBuild (which doesn't do ccache) to Ninja
(which does).
I have the necessary magic for that on a branch, but the branch won't
build because of these warnings.
It turns out that it's possible for OSG plugins to be spread across multiple directories, and OSG doesn't account for this in osgDB::listAllAvailablePlugins(), even though it works when actually loading the plugin.
Instead, use code that's much more similar to how OSG actually loads plugin, and therefore less likely to miss anything.
Incidentally make things much simpler as we don't need awkwardness from working around osgDB::listAllAvailablePlugins()'s limitations.
That way, we don't have issues like the checker getting false positives when the right plugins are present for the wrong OSG version or build config, or false negatives when we've generated the wrong filenames.
It doesn't work, the workaround isn't enough to make it work, I can't be bothered making a more powerful workaround, and it's impossible to *package* a MacOS build missing the plugins we need anyway, even if you can build and attempt to run it.
* Work out what module filenames should be in CMake, and give those to C++
* Compare just the module filenames instead of the full strings
* Deal with OSG trying to support both UTF-8 and system-eight-bit-code-page file paths on Windows.
* Add a comment complaining about the constexpr situation.
* Use a stub implementation when using static OSG - apparently we don't actually support mixing and matching static and dynamic OSG plugins even though OSG itself does.
It doesn't work yet due to osgDB::listAllAvailablePlugins returning a list of paths to dynamic libraries.
That means:
* the check fails when the required plugin is linked statically.
* we're going to have to do something to slice up the filenames.
* there'll probably be unicode errors when the OpenMW installation path isn't representable by the current eight-bit code page on Windows.
Alternatively, we can switch to listing the required file extension support, and use osgDB::Registry::instance()->getReaderWriterList() and each element's supportedExtensions() function, but I don't think we've actually got that list of extensions anywhere and it might get desynced with the existing list of plugins if we add more.
Rebased to account for upstream normalising slashes to replace forward
slashes with backslashes, simplifying the part that needed to check for
both variants. Perhaps if it'd been like that in the first place, I
wouldn't have made the mistake that made the original version of this
commit necessary.
