The initial MSVC 201x projects inadvertly disabled
RandomizedBaseAddress, which is normally enabled by default, so ensure
that is the case for all 201x builds. This feature is supported by
Visual Studio 2010 or later.
Also, for x64 builds on MSVC 2012 or later, use /HIGHENTROPYVA when
linking.
Pointed out by Ignacio Casal Quinteiro.
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
glib-genmarshal is now a Python script instead of a compiled program, so
we need to:
-Remove the projects that are used to build the glib-genmarshal sources.
-Generate the full glib-genmarshal Python script from glib-genmarshal.in
-Make Python a hard build-time requirement, since we use this tool
in many parts of the stack (and it is the case for glib-mkenums).
-Tell people in the Visual Studio build README.txt files that Python
2.7.x or 3.x is now required for the build/"install".
The latest upstream libffi is getting bit-rotten with the Windows/MSVC
builds, and since we are eventually moving to a Meson-based build system,
make use of the Centricular fork of libffi[1], which is better maintained
and tested for builds on Windows, with the use of DLLs over static libraries
and elimination of awkward build flags that we had to use for GObject.
[1]: https://github.com/centricular/libffi
Use the new gen_util_scripts.py script to generate the glib-mkenums and
gdbus-codegen scripts with the proper info in them so that they can be
used properly by other build systems such as Meson, during "install".
This will allow the utility scripts glib-mkenums and gdbus-codegen be
generated with the proper info in them, as build systems such as Meson
might look for shebang lines to determine the commands that need to be
called to invoke the scripts (which is necessary for calling these
scripts on standard Windows cmd.exe)
Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues. Fix this by:
-Doing what we did before on Python 2.x
-Open the file with encoding='utf-8' on Python 3.x
The custom build rules did not have rules for x64 Debug builds during
the refactoring. Fix this by removing all Platform and Configuration
conditions for it, since this is done on are configs in the same manner.
Noted by Ignacio Casal Quinteiro.
As in the version in of this NMake Makefile module in G-I, support
CFG == Release|Debug, which is what is used in the Visual Studio
projects, so that:
-This file will be in sync with the one in G-I
-Other projects that make use of this can integrate this NMake Makefile
module in their Visual Studio project files.
Update this common NMake Makefile module so projects using this (such as
for introspection builds or projects supporting MSVC builds using NMake)
can make use of Visual Studio 2017.
This adds support for Visual Studio 2017 by updating the autotools files for
copying and updating the Visual Studio 2010 project files.
Since the toolset version of Visual Studio 2017 is no longer in the form
of $(MSVC_VER_SHORT)0, we need to specify the full number, but this is a
rather simple change we have here. Note that Visual Studio 2017's CRT
aims to be compatible with the 2015's CRT, so it should be possible to
use 2017-compiled code with the 2015-compiled ones.
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.
