The last commit (Add a preconfigured gio/gnetworking.h for Windows) has to
be split into two as git am does not like a patch that deals with files
that have different line feeds.
This updates the property sheets to use the pre-configured
gio/gnetworking.h during the build process.
https://bugzilla.gnome.org/show_bug.cgi?id=690163
Apparently the C4819 warnings appear due to a bug on Visual C++ on DBCS
locales, so re-enable this.
Add a note in the Visual C++ Readme.txt's regarding this.
-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.
Update the build support of the included PCRE as we are now including
PCRE 8.30 with the GLib distribution.
Also "install" the new gversionmacros.h header file.
Make the "install" project depend on the glib-compile-resources gresource
projects so that these tools will be indeed installed. Missed that in my
last commit-oops.
Also make the "install" project not to depend on the testglib project as:
-the test program in the project is not an exhausive test of the GLib
libraries
-One may want to use the project to compile different test program(s), so
it might be better to keep the project but not "install" the resulting
.exe
Add projects to build the glib-compile-resources and gresource(-tool)
utilities, and "install" these tools upon successful compilation, and dist
the new projects.
One piece of note: will it be better to dist gconstructor_as_data.h instead
of generating it in the VS build process (I generated it in the property
sheet update in this commit)?
Visual C++ 2010 projects will follow shortly.
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)
Get rid of _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_WARNINGS
from the preprocessor definitions as those two macros are now defined
in msvc_recommended_pragmas.h, which is force-included in these projects
via the property sheets. This will silence C4005 warnings on macro
redefinition.
-Fix GLib project/filter files generation as some source items are under
the "deprecated" subfolder, and filter out the gthread-*.c
-Explicitly specify gthread-win32.c in the GLib project/filter file
templates, since tarballs are done on Linux.
-Don't define g_static_mutex_get_mutex in the pregenerated
glibconfig.h.win32(.in) as it is defined in deprecated/gthread.h for Windows
Define USE_SYSTEM_PCRE for all configurations which uses the PCRE that
was already built and "installed" beforehand (i.e. the *_ExtPCRE
configurations) so that the compilation will not pick up the
GLib-bundled pcre.h when one wants to use the PCRE "installation" on
his/her system.
-Added glib/ghmac.h to the list of files to copy during the "install" stage
-Cleaned up a bit (glib-2.0->glib-$(ApiVersion), where $(ApiVersion) is
2.0)
This relates to my previous commit titled "add a script to generator
files for building" on behalf of Shixin Zeng.
Tell people about the availability of a python script to create the
necessary files for a Visual C++ build from a GIT checkout.
This is done with the courtesy of Shixin Zeng's python script which does
the job and eliminates the troubles of getting a suitable shell environment
to do the "make dist" job (which is especially not easy on Windows itself!)
-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
-Reinstate build/win32/vs10/glib.sln with the correct EOL (DOS/Windows) so
that the file can be correctly recognized by Windows, rather than having
the "Unrecognized Visual Studio Version".
-Update the main GLib projects to output the DLL/LIB file into <Release or
Debug>\<Win32 or x64>\bin for all configurations.
-Update/simplify the property sheets to copy all DLL and LIB files from
<Release or Debug>\<Win32 or x64>\bin for all configurations.
-Update the VS 2008 property sheet to seperate the intermediate directories
for all projects as well to avoid errors/warnings of being unable to
write/access the PDB files as they are in use.
These tools require the use of GModule headers also, so update the include
directories so that the correct gmodule.h will be included instead of the
system-installed version.
-Added projects to compile the glib-compile-schemas and gsettings utilities
-Update .vsprops to install these in "install" phase
-Distribute these projects also
Due to changes in the GIO APIs/headers, the glib.vsprops
is updated to reflect that in the "install" phase, namely:
-removal of the gperiodic.h header
-addition of GPollable I/O Stream, GTCP Connection and
GTLS headers
