glib-mkenums is now done in Python, but since the Visual Studio build
environment (cmd.exe) does not support shebang lines, we need to call
the interpretor explicitly to run the script.
This means that we need to update on how we generate
gsk/gskenumtypes.[c|h] in our projects, as at this point GTK+-3.91.x
does not require a GLib installation that ships with the Python-fied
glib-mkenums. As a result, we adapt to this by first using Python
to call glib-mkenums. If this fails (where the output file becomes 0
in size), then we use PERL to call the glib-mkenums script. Note that
during the build this will cause a warning message to be displayed,
stating that '&' cannot be found, but due to the way Windows .bat script
are done, we need to live with that until a solution can be found on
this.
This is likely a problem that does not exist in the Meson builds, as
Meson will take care of calling the interpretor for us by looking at
the shebang lines for our case.
Also, clean up the .batin Windows batch script that is used to call
glib-mkenums by using a for loop in there.
Use conditionals to select the Python installation, so that we can stick
closer to the default Visual Studio versions used to compile each official
Python releases.
This means by default:
-2013 builds use Python 3.4.x, which is built with 2010
-2015 and 2017 builds use Python 3.6.x, which is built with 2015.
Also rename PythonPath/PythonPathX64 in the property sheets to
PythonDir/PythonDirX64 repsectively, as PythonPath is the envvar name
where additional Python modules is searched for, so we don't want to get
confused with it.
Last but not least, distinguish between the Python interpretors that are
used on x64 and x86/32-bit builds for generating the libgtk4.manifest
file and the gdbus-generated sources, for consistency reasons.
Update the autotools scripts to support Visual Studio 2017 builds by
copying the Visual Studio 2013 projects and updateing the items as
necessary to obtain the Visual Studio 2017 projects.
Note that the format of the toolset string changed, so allow one to
pass in and thus use a custom toolset string, otherwise the default
toolset string will be generated as it was before.
Note also the Visual Studio 2017 aims to be compatible with Visual
Studio 2015 on the CRT level, so binaries built with 2017 should
work without problems with the binaries built with 2015.
It was suggested that the project files to be moved to win32/, so that we can
have one less layer of directories we need to go down into to reach the project files.
