Make use of the common autotools module that is used to generate the MSVC
project files from their respective templates so that the main build files
beccome cleaner, and enhance them in a way that the headers that should be
installed can be written to the property sheets during 'make dist', so that
the chances of missing headers for MSVC builds can be greatly reduced.
Also use this autotools module to fill in the projects for
glib-compile-schemas and glib-compile-resources.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
Update the .pdb file generation for the MSVC 2010+ DLLs (and the x64 gspawn
helper programs), so that they match the names of the DLLs/EXEs that are
built. Also update the .lib generation so that all will use -$(ApiVersion)
from the property sheets instead of the -2.0 which was previously hard
coded (as we will eventually move into GLib 3.x in the future, for example)
Link to zlib1.lib for all builds, as:
-The notion of zlib1d.lib is rather not standardized across the board for
most cases.
-Easier for the grand all-in-one solution file.
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.
Like the Visual Studio 2008 project files, split up the property sheets
so to ease maintenace, and to prepare to use autotools to fill in the
header entries to "install".
Put some of the items that are frequently repeated in the projects as well,
also to simplify maintenance.
Also, update the autotools files to automate the upgrade of Visual Studio
2010 project as we now have multiple property sheets to copy and 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.
Add the PlatformToolset tag to the project configs so that we can use add a
simple script later to the autotools files to copy the projects and change
the value (v100 -> v110) of that tag (and other simple changes) in order
that we can quickly provide and maintain support for Visual Studio 2012
with minimal effort.
Note that at the moment GLib does not yet support the API/SDK requirements
for Windows 8 Modern UI (formerly known as Metro), but this paves the very
initial step.
-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
-Seperate intermediate directories for each project to avoid intermittent
MSBuild errors that a build log cannot be written while in use, and
update the property sheet as necessary.
-Minor cleanups of uneeded tags in the projects/properties
These are the actual GLib VS2010 project files (*.vcxproj,
*.vcxproj.filters) and property sheet file (*.props) that are used
to compile the GLib, GModule, GObject, GThread, GIO DLLs, along with
the gspawn-win32-helper* programs, glib-genmarshal utility and
testglib test program. A readme.txt file is also enclosed for
references for building GLib under VS2010.
Note that the project files for GLib, GIO and GObject are templates
that makes use of the autotools items of my last commit so that maintenance
of those files are simplified as new source files are added to these rather
frequently.
Suggestions are welcome for these-please let me know via BugZilla.
Thank you!
