The previous commit to glib/glibconfig.h.win32.in, though it improves
the state of GLib and fixes bugs, cannot be used as a drop-in
replacement for code that builds against the previous
glib/glibconfig.h(.win32.in) that were build using the Visual Studio
projects. Change the DLL names as a result so that the likelihood of
problems caused by replacing existing GLib DLLs can be reduced--code
that was built against previous GLib MSVC builds should be rebuilt, so
that things will work with the newer DLLs, instead of depending on the
older DLLs.
Note that if Visual Studio builds are done through Meson, existing code
that link against GLib should be rebuilt as well, for the same reason.
DLLs built with the Visual Studio projects from 2.55.0 onwards should be
compatible with the ones that are built with Visual Studio via Meson.
This is to avoid confusion with the PYTHONPATH envvar that is commonly
used to determine where additional Python modules can be loaded,
especially in the case of a MSBuild build. Note that envvar names are
not case sensitive on Windows in general.
Use conditionals to select the Python installation, so that we can more
stick to the default Visual Studio versions used to compile each
official Python releases more closely.
This means by default:
-2010/2012/2013 builds use Python 3.4.x, which is built with 2010
-2015/2017 builds use Python 3.6.x, which is built with 2015
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
