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).
Static libraries on Windows can't have embedded resources, so this mean the icon for the CS wasn't used.
This could have also been resolved by explicitly requesting the library type as OBJECT rather than letting it default to STATIC (as object libraries aren't a thing on-disk and are just an abstraction in CMake so you can use the same object files in different targets), but this seemed less invasive.
I also made it Win32-only as a Windows .rc file is meaningless on Unix, but it shouldn't be MSVC-only as MinGW can consume them.
Each binary depending on components library requires OSG plugins to be linked.
Duplicating dependecies for each binary does not give benefits and brings
problems when new binary is added.
Define components_qt static library with all qt dependent components that also
depends on other components. Link only cs, wizard and launcher with qt
dependent components.
`$<TARGET_FILE:...>` fails if the argument is already a path (instead of
a library name). This happens when a static library is found via
`osg_find_library`.
If the argument contains `/` or `.`, do not use `$<TARGET_FILE:...>`
