List the files that are generated in the process to generate the
glib-install property sheets, so that we can use that list as a
depedency, as well as deleting those files in one shot after the
property sheet is generated, so we don't need to worry about those
in 'make distclean' or so.
Use a simple all-purpose utility script to generate the glib-mkenums
PERL script with the version info, and stop using the script that
tries to parse the autotools files. Move the things that
were taken out from build/win32/setup.py back there.
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.
Use the /MP option so that each project can build multiple sources in
parallel, which can cut down release build times by quite a bit. This will
cause a brief warning for debug builds due to their use of /Gm, and builds
would otherwise proceed as they did before.
Unfortunately Visual Studio 2008 is too old to support the /d2Zi+ flag, so
we can't make a better debug situation for it at the moment.
Rename the project to "install" the GLib files, as we are planning to have
a grand solution file that would build the entire GTK+ stack with its deps,
to ease the process for people building the GTK+ stack from a stock
installation of Visual Studio.
We are including the autocleanup headers as public headers for all builds,
although they work only for GCC in reality, so "install" them.
Also clean up a bit as we are having "\\" in places, where we only need
"\".
This updates the glib-install.[props|vsprops] so that the headers to
"install" for the build are kept up-to-date. Note that this has been
generated by a script, so that this hopefully means that the header
"installation" can be maintained along with the autotools files for most
uses, to simplify maintenance.
As glib-mkenums would likely be used in the building of the other
components of the stack, such as Cogl, Clutter and
gsettings-desktop-schemas, generate that using a Python script (if Python
can be found) and "install" it.
There are many test programs that are shipped with GLib, and this project
is a one-to-one project, which does not make sense to keep as various test
programs may have different CFLAGS, etc, which will require different build
options.
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.
...where possible, to make application of patches easier in the future.
The README.txt's and the .sln files are still in Windows/DOS line endings
as they need to be so.
Install the Python scripts that is used by gdbus-codegen in
share\glib-2.0\codegen, to be consistent with the other platforms.
Please see https://bugzilla.gnome.org/show_bug.cgi?id=702862 for details
on this.
Due to the split up of the property sheets, the install projects did not
have info on the Intermediate and Output Paths, which caused confusing
messages from Visual Studio to show up upon completing build+"install" and
closing Visual Studio on whether to reload the install project, at least on
Visual Studio 2008.
Include the property sheet which defines these properties to fix this.
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
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
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.
