glib/vs9 at d5dc79c0b066895ad41e84db35568d5a30235186 - glib

mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-09-21 09:46:18 +02:00

History

Chun-wei Fan 9de42602c4 Bug 637852 - Updates to glib.vsprops 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		2011-01-05 22:57:48 +08:00
..
.gitignore	gitignore for win32 build stuff	2010-03-21 13:07:36 -05:00
gio.vcprojin	Made up for missed source files	2010-11-09 09:08:45 +08:00
glib-genmarshal.vcproj	Drop empty Tool elements from the project files for clarity	2010-03-21 13:33:44 +02:00
glib.sln	Added option to use existing installation of PCRE	2010-11-09 09:11:48 +08:00
glib.vcprojin	Some enhancements for Win64 and using existing PCRE installtions	2010-11-09 09:23:47 +08:00
glib.vsprops	Bug 637852 - Updates to glib.vsprops	2011-01-05 22:57:48 +08:00
gmodule.vcproj	Updated .def generation for x64	2010-11-09 09:27:27 +08:00
gobject.vcprojin	Avoid much of duplication in lists of source files	2010-03-21 16:15:02 +02:00
gspawn-win32-helper-console.vcproj	Drop empty Tool elements from the project files for clarity	2010-03-21 13:33:44 +02:00
gspawn-win32-helper.vcproj	Drop empty Tool elements from the project files for clarity	2010-03-21 13:33:44 +02:00
gthread.vcproj	Drop empty Tool elements from the project files for clarity	2010-03-21 13:33:44 +02:00
install.vcproj	Further work on VS9 project files	2010-02-04 19:59:12 +02:00
Makefile.am	Avoid much of duplication in lists of source files	2010-03-21 16:15:02 +02:00
README.txt	Updated README.txt for VS9	2010-11-09 09:50:11 +08:00
testglib.vcproj	Drop empty Tool elements from the project files for clarity	2010-03-21 13:33:44 +02:00

README.txt

Note that all this is rather experimental.

This VS9 solution and the projects it includes are intented to be used
in a GLib source tree unpacked from a tarball. In a git checkout you
first need to use some Unix-like environment or manual work to expand
the .in files needed, mainly config.h.win32.in into config.h.win32 and
glibconfig.h.win32.in into glibconfig.h.win32. You will also need to
expand the .vcprojin files here into .vcproj files.

The required dependencies are zlib and proxy-libintl. Fetch the latest
proxy-libintl-dev and zlib-dev zipfiles from
http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/ for 32-bit
builds, and correspondingly
http://ftp.gnome.org/pub/GNOME/binaries/win64/dependencies/ for 64-bit
builds. 

One may optionally use his/her own PCRE installation by selecting the
(BuildType)_ExtPCRE configuration, but please note the PCRE must be built
with VS9 with unicode support using the /MD (release) or /MDd (debug)
runtime option which corresponds to your GLib build flavour (release, debug).
(These are the defaults set by CMAKE, which is used in recent versions of PCRE.)
Not doing so will most probably result in unexpected crashes in 
your programs due to the use of different CRTs.  If using a static PCRE
build, add PCRE_STATIC to the "preprocessor definitions".
Note that one may still continue to build with the bundled PCRE by selecting
the (BuildType) configuration.

Set up the source tree as follows under some arbitrary top
folder <root>:

<root>\glib\<this-glib-source-tree>
<root>\vs9\<PlatformName>

*this* file you are now reading is thus located at
<root>\glib\<this-glib-source-tree>\build\win32\vs9\README.

<PlatformName> is either Win32 or x64, as in VS9 project files.

You should unpack the proxy-libintl-dev zip file into
<root>\vs9\<PlatformName>, so that for instance libintl.h end up at
<root>\vs9\<PlatformName>\include\libintl.h.

The "install" project will copy build results and headers into their
appropriate location under <root>\vs9\<PlatformName>. For instance,
built DLLs go into <root>\vs9\<PlatformName>\bin, built LIBs into
<root>\vs9\<PlatformName>\lib and GLib headers into
<root>\vs9\<PlatformName>\include\glib-2.0. This is then from where
project files higher in the stack are supposed to look for them, not
from a specific GLib source tree.

--Tor Lillqvist <tml@iki.fi>
--Updated by Chun-wei Fan <fanc999@gmail.com>