Make the projects include a single property sheet as necessary, which will
in turn include the other property sheet(s) as needed, so that we can avoid
warnings where we include the same property sheets twice in a single
project.
Also make the copying of pre-configured headers into custom build rules so
that they can be removed upon the clean command from the IDE and that they
can be re-copied if their counterpart *.h.win32 are updated.
Split the property sheet into four sheets, to make maintainance of the
build files easier, and also to prepare for using autotools to fill in
the parts for the "installation" of headers.
Also put more of the items that are repeated in the projects into the
property sheets, also to improve ease of maintenance.
Updates to the Visual Studio 2010 projects will come later, as the script
to update them to Visual Studio 2012 must also be taken into account during'
the process.
This is needed for GetAdaptersAddresses()[1], which was used to implement
if_nametoindex on Windows, notably on Windows XP, in commit 01156b12.
if_nametoindex and if_indextoname, as noted in config.h.win32(.in), is
available with Windows Vista and later, so when we eventually drop
support for Windows XP, we can call them directly, and these functions
also reside in the same iphlpapi.lib
[1]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365915%28v=vs.85%29.aspx
Since we are now starting to use __declspec (dllexport) to export the
public functions during the build of the GLib DLLs (i.e. to generate the
.lib files), we don't want to generate the .def files from the .symbols
files as we did before for a long time.
This removes from the projects the custom build steps to generate the
various .def files
This will also update the pre-configured config.h(.win32.in) to define
_GLIB_EXTERN appropriately as __declspec (dllexport), as well as making its
entries reflect config.h.in more closely.
-Make up for the missed DLL_EXPORT-it's actually needed for all GLib DLL
builds, omitting this caused problems to surface due to recent works to
make GDBus work on Windows.
-Also use the FFI_BULIDING macro for GObject builds as the suggessted
workaround for using static LibFFI builds (as we do now)-please see
ffi.h(.in). This will fix the build of GObject against LibFFI 3.0.11,
but it is probable that this will change at some point for LibFFI.
Clean/fix up the Preprocessor Definitions for the various projects, where
we purge out the unneeded macros and add _DEBUG to the Debug builds of
various projects that somehow lacked this.
This will also fix the GIO build under Visual C++ 2008, as the _DEBUG macro
in the release builds will cause a debug entry to appear in its manifest
file during the build, which will cause GIO-using applications to fail
to run on systems not running Visual C++/Studio 2008 due to its embedding
of a badly-generated manifest file.
Link to zlib1.lib for release builds and zlib1d.lib for debug builds-
this is to be consistent across the board for the GTK+ stack (and many
other opensource code linking to the ZLib DLL on Windows)
-In gio/Makefile.am, the name for one of the filters for capturing the
sources for the GIO VS Project Files is corrected.
-Remove the GIO source file items in the VS project files templates as
a result for this change, and move the entry of the "new"
gregistrysettingsbackend.c into the filter in gio/Makefile.am
Don't keep the lists of source files for libglib, libgobject and
libgio in the VS project files in addition to the canonical location,
the corresponding Makefile.am files.
Instead, generate the corresponding .vcproj files at make dist time
using the C preprocessor, from template files called .vcprojin. We
still list explicitly in the .vcprojin files some of the
Windows-specific source files, and the sources files of gnulib and
pcre.
