This is still used in the wild as lots of people install 7zip and never update it because it works. We can't check the version and abort if it's too old as the changelog doesn't make it clear which version fixed the behaviour.
Also fix some bugs discovered in the process.
For multi-config generators, this basically just copies the DLLs for
each configuration, and for single-config, due to there being separate
build directories with separate extracted dependencies for each, it
defaults to just one, and will run the script several times if you
manually specify several.
Details include:
* Changing CONFIGURATION from a string to an array called
CONFIGURATIONS. This gets iterated over in a bunch of places.
* Fixing a typo of 'cannot'
* Making the DLL lists arrays per-config, too.
* Some handling for the recursive stuff and a warning if configurations
are set with a multi-config generator.
* Moving the configuration name sanitisation after they've been set.
* Myriad changes to Google Test:
- Build it in a directory specific to the build tools - previously,
having an MSVC 2017 and MSVC 2019 build on the same machine was
impossible if unit tests were on, even though it's allowed otherwise
- Use either Debug or Release Google Test as its finder isn't looking
for RelWithDebInfo or capable of dealing with it if we try and use
it anyway.
- Always build Google Test with MSBuild as it's much less hassle due
to CMake setting up the environment for us. Currently, MSVC always
comes with something that can build solution files, no matter how
you get it, so this shouldn't upset anyone.
- Use CMake's --install mode so we can set the install prefix in the
place that uses it.
- Pass CMake both Debug and Release Google Test instead of risking a
C/C++ library configuration mismatch causing linker and runtime
errors - it'll pick a suitable one for each configuration.
- Pass the library type explicitly as CMake can't cope without a
Release library if you only gave it Debug, due to accessing a
Release-specific variable unconditionally.
* Remove the -legacy flag from vswhere as it's only needed for MSVC
2015, which we don't support any more.
* Fix the -version argument for vswhere as I'd massively cocked it up.
I don't know how that happened as I did test it on a machine with
multiple MSVC versions installed, which was the failure case, but it
didn't fail then.
