Build and "install" the gio-querymodules and gdbus utility programs so that
the Visual Studio builds of GLib is more comprehensive. The Python scripts
for the GDBus codegen will be added to "installation" later.
Update G_LOG_DOMAIN to be "GLib-GObject" so that we are consistent with
the autotools builds, and that tests expecting the log domain to be
"GLib-GObject" would not fail.
Define the G_LOG_DOMAIN of the GLib DLL as "GLib", because:
-This makes it consistent with the autotools builds
-Some tests expect the log domain to be "GLib"
We no longer need entries to generate the .def files in the property sheets
as we are now doing __declspec (dllexport) to export all the needed
symbols. So, purge these items from the property sheets since they are no
longer used.
We should also stop using gthread/gthread.def file as well, since we
also use __declspec (dllexport) for the two (deprecated) functions there
since commit f8756694.
This should also silence some linker warnings in x64 builds.
Also get rid of the references to the .symbols files in the
.vcxproj.filters(in) in the various Visual C++ 2010 projects
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.
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
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.
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.
Added projects to compile the glib-compile-resources and gresource(-tool)
utility programs during the Visual C++ 2010 build process, "install"
the resulting binaries upon successful compilation, and dist the new
.vcxproj and .vcxproj.filters files.
Also updated the property sheet and "install" project to make sure the new
.exe's are indeed "installed" and removed from the "install" project the
dependency on the testglib project as testglib is not an exhausive test on
GLib and people might want to make that project compile different test
programs as they might need.
Just wondering: I have updated the property sheet to create the
gconstructor_as_data.h header for glib-compile-resources, but is it better
to dist that generated header instead as the VS 2008/2010 projects will
depend on a working installation of PERL on Windows?
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!)
