Boost::zlib is basically part of Boost::iostreams, and depending on how you configure Boost, it can either be a separate library or get embedded into iostreams.
With the third-party-but-linked-on-Boost's-website package we've been using for years, it's a separate library.
Before https://gitlab.com/OpenMW/openmw/-/merge_requests/4307, we needed to explicitly link with it as CMake wasn't handling transitive dependencies for us.
With vcpkg, it's embedded, and doesn't have its own CMake config, so we couldn't explicitly link with it even if we wanted to.
Now CMake *is* handling transitive dependencies for us, we don't even need to think about this library.
It's all automatic.
Boost::locale, on the other hand, used to be something we used directly (I think for doing UTF-16/UTF-8 conversions when dealing with Windows paths).
However, it isn't anymore, and we just didn't purge it from our CMake when we should have.
It can go.
Resolves https://gitlab.com/OpenMW/openmw/-/issues/8100
Also removes some old crud.
Hopefully the old crud is all:
* Handled automatically by CMake now we're using the modern approach.
* A hack-fix for a problem caused by not using the modern approach.
* Massively outdated so no longer necessary.
If it turns out this makes CI fail, I'll tweak things as necessary.
Changes that might not be wanted include:
* Getting rid of our BOOST_STATIC CMake option. In cases where the CMake config doesn't make the one correct choice from the build environment (i.e. because there's a choice) the CMake config exposes the option already.
However, we were forcing this on for Windows, so that might matter.
It seems to default to static on my machine even though I thought I read something suggesting otherwise, so we'll see how things go with that.
If we eventually put CMake in charge of installing dependency DLLs this will be a moot point as we won't need to care.
* Bumping the minimum version of Boost to 1.70.0, as that's the first with working CMake config.
It's from 2019, so plausibly there are distros too scared to use a library from five years ago as it can't legally drink in the US (although it could in limited quantities with parental supervision in the UK, as long as it's just something inconsequential like a single sip of beer).
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.
* 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.
