Bug 653841: Update README.win32 and VS README.txt's

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!)

1 files changed, 358 insertions, 347 deletions

diff --git a/README.win32 b/README.win32
index 25d06aeb8..a04417f91 100644
--- a/README.win32
+++ b/README.win32
@@ -1,347 +1,358 @@
-Tor Lillqvist <tml@iki.fi>
-Hans Breuer <hans@breuer.org>
-
-Note that this document is not really maintained in a serious
-fashion. Lots of information here might be misleading or outdated. You
-have been warned.
-
-The general parts, and the section about gcc and autoconfiscated
-build, and about a Visual Studio build are by Tor Lillqvist. The
-sections about MSVC build with NMAKE is by Hans Breuer. 
-
-General
-=======
-
-For prebuilt binaries (DLLs and EXEs) and developer packages (headers,
-import libraries) of GLib, Pango, GTK+ etc for Windows, go to
-http://www.gtk.org/download-windows.html . They are for "native"
-Windows meaning they use the Win32 API and Microsoft C runtime library
-only. No POSIX (Unix) emulation layer like Cygwin in involved.
-
-To build GLib on Win32, you can use either gcc ("mingw") or the
-Microsoft compiler and tools. For the latter, MSVC6 and later have
-been used successfully. Also the Digital Mars C/C++ compiler has
-reportedly been used.
-
-You can also cross-compile GLib for Windows from Linux using the
-cross-compiling mingw packages for your distro.
-
-Note that to just *use* GLib on Windows, there is no need to build it
-yourself.
-
-On Windows setting up a correct build environment can be quite a task,
-especially if you are used to just type "./configure; make" on Linux,
-and expect things to work as smoothly on Windows.
-
-The following preprocessor macros are to be used for conditional
-compilation related to Win32 in GLib-using code:
-
-- G_OS_WIN32 is defined when compiling for native Win32, without
-  any POSIX emulation, other than to the extent provided by the
-  bundled Microsoft C library (msvcr*.dll).
-
-- G_WITH_CYGWIN is defined if compiling for the Cygwin
-  environment. Note that G_OS_WIN32 is *not* defined in that case, as
-  Cygwin is supposed to behave like Unix. G_OS_UNIX *is* defined by a GLib
-  for Cygwin.
-
-- G_PLATFORM_WIN32 is defined when either G_OS_WIN32 or G_WITH_CYGWIN
-  is defined.
-
-These macros are defined in glibconfig.h, and are thus available in
-all source files that include <glib.h>.
-
-Additionally, there are the compiler-specific macros:
-- __GNUC__ is defined when using gcc
-- _MSC_VER is defined when using the Microsoft compiler
-- __DMC__ is defined when using the Digital Mars C/C++ compiler
-
-G_OS_WIN32 implies using the Microsoft C runtime, normally
-msvcrt.dll. GLib is not known to work with the older crtdll.dll
-runtime, or the static Microsoft C runtime libraries libc.lib and
-libcmt.lib. It apparently does work with the debugging version of
-msvcrt.dll, msvcrtd.dll. If compiled with Microsoft compilers newer
-than MSVC6, it also works with their compiler-specific runtimes, like
-msvcr70.dll or msvcr80.dll. Please note that it's non totally clear if
-you would be allowed by the license to distrubute a GLib linked to
-msvcr70.dll or msvcr80.dll, as those are not part of the operating
-system, but of the MSVC product. msvcrt.dll is part of Windows.
-
-Building software that use GLib or GTK+
-=======================================
-
-Building software that just *uses* GLib or GTK+ also require to have
-the right compiler set up the right way. If you intend to use gcc,
-follow the relevant instructions below in that case, too.
-
-Tor uses gcc with the -mms-bitfields flag which means that in order to
-use the prebuilt DLLs (especially of GTK+), if you compile your code
-with gcc, you *must* also use that flag. This flag means that the
-struct layout rules are identical to those used by MSVC. This is
-essential if the same DLLs are to be usable both from gcc- and
-MSVC-compiled code. Such compatibility is desirable.
-
-When using the prebuilt GLib DLLs that use msvcrt.dll from code that
-uses other C runtimes like for example msvcr70.dll, one should note
-that one cannot use such GLib API that take or returns file
-descriptors. On Windows, a file descriptor (the small integer as
-returned by open() and handled by related functions, and included in
-the FILE struct) is an index into a table local to the C runtime
-DLL. A file descriptor in one C runtime DLL does not have the same
-meaning in another C runtime DLL.
-
-Building GLib
-=============
-
-Again, first decide whether you really want to do this.
-
-Before building GLib you must also have a GNU gettext-runtime
-developer package. Get prebuilt binaries of gettext-runtime from
-http://www.gtk.org/download-windows.html .
-
-Autoconfiscated build (with gcc)
-================================
-
-Tor uses gcc 3.4.5 and the rest of the mingw utilities, including MSYS
-from www.mingw.org. Somewhat earlier or later versions of gcc
-presumably also work fine.
-
-Using Cygwin's gcc with the -mno-cygwin switch is not recommended. In
-theory it should work, but Tor hasn't tested that lately. It can
-easily lead to confusing situations where one mixes headers for Cygwin
-from /usr/include with the headers for native software one really
-should use. Ditto for libraries.
-
-If you want to use mingw's gcc, install gcc, win32api, binutils and
-MSYS from www.mingw.org.
-
-Tor invokes configure using:
-
-CC='gcc -mtune=pentium3 -mthreads' CPPFLAGS='-I/opt/gnu/include' \
-	LDFLAGS='-L/opt/gnu/lib -Wl,--enable-auto-image-base' CFLAGS=-O2 \
-	./configure --disable-gtk-doc --prefix=$TARGET
-
-The /opt/gnu mentioned contains the header files for GNU and (import)
-libraries for GNU libintl. The build scripts used to produce the
-prebuilt binaries are included in the "dev" packages.
-
-Please note that the ./configure mechanism should not blindly be used
-to build a GLib to be distributed to other developers because it
-produces a compiler-dependent glibconfig.h. For instance, the typedef
-for gint64 is long long with gcc, but __int64 with MSVC.
-
-Except for this and a few other minor issues, there shouldn't be any
-reason to distribute separate GLib headers and DLLs for gcc and MSVC6
-users, as the compilers generate code that uses the same C runtime
-library.
-
-The DLL generated by either compiler is binary compatible with the
-other one. Thus one either has to manually edit glibconfig.h
-afterwards, or use the supplied glibconfig.h.win32 which has been
-produced by running configure twice, once using gcc and once using
-MSVC, and merging the resulting files with diff -D.
-
-For MSVC7 and later (Visual C++ .NET 2003, Visual C++ 2005, Visual C++
-2008 etc) it is preferred to use specific builds of GLib DLLs that use
-the same C runtime as the code that uses GLib. Such DLLs should be
-named differently than the ones that use msvcrt.dll.
-
-For GLib, the DLL that uses msvcrt.dll is called libglib-2.0-0.dll,
-and the import libraries libglib-2.0.dll.a and glib-2.0.lib. Note that
-the "2.0" is part of the "basename" of the library, it is not
-something that libtool has added. The -0 suffix is added by libtool
-and is the value of "LT_CURRENT - LT_AGE". The 0 should *not* be
-thought to be part of the version number of GLib. The LT_CURRENT -
-LT_AGE value will on purpose be kept as zero as long as binary
-compatibility is maintained. For the gory details, see configure.ac
-and libtool documentation.
-
-Building with Visual Studio
-===========================
-
-In an unpacked tarball, you will find in build\win32\vs9 a solution
-file that can be used to build the GLib DLLs and some auxiliary
-programs. Read the README.txt file in that folder for more
-information. Note that you will need a libintl implementation, and
-zlib.
-
-Building with MSVC and NMAKE
-============================
-
-If you are building from a GIT snapshot, you will not have all
-makefile.msc files. You should copy the corresponding makefile.msc.in
-file to that name, and replace any @...@ strings with the correct
-value (or use the python script de-in.py from http://hans.breuer.org/gtk/de-in.py).
-
-This is done automatically when an official GLib source distribution
-package is built, so if you get GLib from a source distribution
-package, there should be makefile.msc files ready to use (possibly after some
-editing).
-
-The hand-written makefile.msc files, and the stuff in the "build"
-subdirectory, produce DLLs and import libraries that match what the
-so-called autoconfiscated build produces.
-
-All the MSVC makefiles are for the command line build with nmake.  If
-you want to use the VC-UI you can simply create wrapper .dsp makefiles
-(read the VC docs how to do so).
-
-Some modules may require Perl to auto-generate files. The goal (at
-least Hans's) is to not require any more tools. Of course you need
-the Microsoft Platform SDK in a recent enough - but not too recent - version.
-The last PSDK for Visual Studio 6 is:
-  http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm
-At least install the Core SDK, maybe also the "Tablet PC SDK".
-
-
-Build with:
-
-nmake -f makefile.msc
-  or
-nmake -f makefile.msc DEBUG=1
-
-[
- The former will create 'release' versions of the DLLs. If you
- plan to distribute you DLLs please use this command. The latter 
- will create DLLs with debug information _and_ link them with
- msvcrtd.dll instead of msvcrt.dll. 
- Beware: There are known problems with mixing DLLs in one 
- application, which are build against different runtimes. 
- Especially the index-to-file mapping used by 'unix-style' file
- operation - _open() _pipe() etc. - breaks sometimes in strange 
- ways (for example the Gimp plug-in communication).
-]
-
-Required libraries (not build from svn)
-------------------
-  libintl (gnu-intl),
-
-are available pre-built from the website mentioned above.
-
-Versioning
-----------
-Instead of the Unix and auto* way of tracking versions and resolving
-dependencies (configure; make; make install) involving autoconf,
-automake, libtool and friends the MSVC build uses a different
-approach.
-
-The core of it's versioning is the file build/win32/module.defs.
-It contains entries of the form MODULE_VER, e.g.:
-
-	GLIB_VER = 2.0
-	LIBICONV_VER = 1.3
-
-and the placement of these modules defined as MODULE, e.g.:
-
-	GLIB = $(TOP)/glib
-	LIBICONV = $(TOP)/libiconv-$(LIBICONV_VER)
-
-whereas TOP is defined as the relative path from the respective
-module directory to your top build directory. Every makefile.msc
-needs to define TOP before including the common make file part
-make.msc, which than includes module.defs, like:
-
-TOP = ../..
-!INCLUDE $(TOP)/glib/build/win32/make.msc
-
-(Taken from gtk+/gdk/makefile.msc)
-
-With this provision it is possible to create almost placement
-independent makefiles without requiring to 'install' the libraries and
-headers into a common place (as it is done on Unix, and as Tor does
-when producing his zipfiles with prebuilt GLib, GTK+ etc).
-
-Special Files
--------------
-	config.h.win32.in : @XXX_MAJOR_VERSION@ needs to be replaced by
-the current version/build number. The resulting file is to be saved
-as 'config.h.win32'. This should be automatically done if a package
-gets build on the Unix platform.
-
-	makefile.msc.in : @XXX_MAJOR_VERSION@ to be replaced. Save as
-makefile.msc.
-
-	<module>.def : every function which should be used from the outside of
-a dll needs to be marked for 'export'. It is common that one needs to change 
-these files after some api changes occured. If there are variables to be
-exported another mechanism is needed, like :
-
-	#ifdef G_OS_WIN32
-	#  ifdef GDK_COMPILATION
-	#    define GDKVAR __declspec(dllexport)
-	#  else
-	#    define GDKVAR extern __declspec(dllimport)
-	#  endif
-	#else
-	#  define GDKVAR extern
-	#endif
-
-
-
-Directory Structure
--------------------
-all modules should be build in a common directory tree otherwise you 
-need to adapt the file 'module.defs'. They are listed here in increasing
-dependencies order.
-
-<common rootdir without spaces>
-  |
-  +- glib
-  |   |
-  |   +- build          : [this module lives in the SVN root dir]
-  |   |   +- win32
-  |   |       .\module.defs : defines (relative) locations of the headers
-  |   |                       and libs and version numbers to be include 
-  |   |                       in dll names
-  |   |       .\make.msc    : include by almost every 'makefile.msc'
-  |   |
-  |   | .\README.WIN32  : more information how to build
-  |   | .\glibconfig.h.win32.in : similar to config.h.win32.in
-  |   | .\makefile.msc  : master makefile, sub dir makefiles should work 
-  |   |
-  |   +- glib
-  |   +- gmodule
-  |   +- gthread        : does _not_ depend on pthread anymore
-  |   +- gobject
-  |
-  +- pango
-  |   +- pango          : 'native' build does not require extra libs and
-  |   |                 includes the minimal required text renderer
-  |   |                 (there is also a currently slightly broken FreeType2 
-  |   |                 based implementation for win32)
-  |   +- modules (not yet build)
-  |
-  +- atk
-  |   +- atk
-  |       .\makefile.msc : build here
-  |
-  +- gtk+
-  |   | .\config.h.win32 : for all the below
-  |   |
-  |   +- gdk-pixbuf
-  |   |   .\gdk_pixbuf.rc.in : version resource for the DLLs. Needs
-  |   |                 to be converted (filled with version info)
-  |   |                 as described above.
-  |   |
-  |   +- gdk
-  |   |   | .\makefile.msc : some auto-generation is needed to build in the
-  |   |   |             in the subdirectory 
-  |   |   +- win32
-  |   |
-  |   +- gtk
-
-  |
-  +- gimp
-  |   .\makefile.msc    : master makefile to build The Gimp. The makefiles
-  |                     from the sub dirs should work stand alone, but than
-  |                     the user needs to know the build order
-
-  |
-  +- dia                : additionally depends on libart_lgpl (in SVN)
-      |                 and libxml2 ( see http://www.xmlsoft.org/ )
-      +- lib
-      +- app
-      +- objects
-      +- plug-ins
-          +- python
-
+Tor Lillqvist <tml@iki.fi>

+Hans Breuer <hans@breuer.org>

+

+Note that this document is not really maintained in a serious

+fashion. Lots of information here might be misleading or outdated. You

+have been warned.

+

+The general parts, and the section about gcc and autoconfiscated

+build, and about a Visual Studio build are by Tor Lillqvist. The

+sections about MSVC build with NMAKE is by Hans Breuer. 

+

+General

+=======

+

+For prebuilt binaries (DLLs and EXEs) and developer packages (headers,

+import libraries) of GLib, Pango, GTK+ etc for Windows, go to

+http://www.gtk.org/download-windows.html . They are for "native"

+Windows meaning they use the Win32 API and Microsoft C runtime library

+only. No POSIX (Unix) emulation layer like Cygwin in involved.

+

+To build GLib on Win32, you can use either gcc ("mingw") or the

+Microsoft compiler and tools. For the latter, MSVC6 and later have

+been used successfully. Also the Digital Mars C/C++ compiler has

+reportedly been used.

+

+You can also cross-compile GLib for Windows from Linux using the

+cross-compiling mingw packages for your distro.

+

+Note that to just *use* GLib on Windows, there is no need to build it

+yourself.

+

+On Windows setting up a correct build environment can be quite a task,

+especially if you are used to just type "./configure; make" on Linux,

+and expect things to work as smoothly on Windows.

+

+The following preprocessor macros are to be used for conditional

+compilation related to Win32 in GLib-using code:

+

+- G_OS_WIN32 is defined when compiling for native Win32, without

+  any POSIX emulation, other than to the extent provided by the

+  bundled Microsoft C library (msvcr*.dll).

+

+- G_WITH_CYGWIN is defined if compiling for the Cygwin

+  environment. Note that G_OS_WIN32 is *not* defined in that case, as

+  Cygwin is supposed to behave like Unix. G_OS_UNIX *is* defined by a GLib

+  for Cygwin.

+

+- G_PLATFORM_WIN32 is defined when either G_OS_WIN32 or G_WITH_CYGWIN

+  is defined.

+

+These macros are defined in glibconfig.h, and are thus available in

+all source files that include <glib.h>.

+

+Additionally, there are the compiler-specific macros:

+- __GNUC__ is defined when using gcc

+- _MSC_VER is defined when using the Microsoft compiler

+- __DMC__ is defined when using the Digital Mars C/C++ compiler

+

+G_OS_WIN32 implies using the Microsoft C runtime, normally

+msvcrt.dll. GLib is not known to work with the older crtdll.dll

+runtime, or the static Microsoft C runtime libraries libc.lib and

+libcmt.lib. It apparently does work with the debugging version of

+msvcrt.dll, msvcrtd.dll. If compiled with Microsoft compilers newer

+than MSVC6, it also works with their compiler-specific runtimes, like

+msvcr70.dll or msvcr80.dll. Please note that it's non totally clear if

+you would be allowed by the license to distrubute a GLib linked to

+msvcr70.dll or msvcr80.dll, as those are not part of the operating

+system, but of the MSVC product. msvcrt.dll is part of Windows.

+

+Building software that use GLib or GTK+

+=======================================

+

+Building software that just *uses* GLib or GTK+ also require to have

+the right compiler set up the right way. If you intend to use gcc,

+follow the relevant instructions below in that case, too.

+

+Tor uses gcc with the -mms-bitfields flag which means that in order to

+use the prebuilt DLLs (especially of GTK+), if you compile your code

+with gcc, you *must* also use that flag. This flag means that the

+struct layout rules are identical to those used by MSVC. This is

+essential if the same DLLs are to be usable both from gcc- and

+MSVC-compiled code. Such compatibility is desirable.

+

+When using the prebuilt GLib DLLs that use msvcrt.dll from code that

+uses other C runtimes like for example msvcr70.dll, one should note

+that one cannot use such GLib API that take or returns file

+descriptors. On Windows, a file descriptor (the small integer as

+returned by open() and handled by related functions, and included in

+the FILE struct) is an index into a table local to the C runtime

+DLL. A file descriptor in one C runtime DLL does not have the same

+meaning in another C runtime DLL.

+

+Building GLib

+=============

+

+Again, first decide whether you really want to do this.

+

+Before building GLib you must also have a GNU gettext-runtime

+developer package. Get prebuilt binaries of gettext-runtime from

+http://www.gtk.org/download-windows.html .

+

+Autoconfiscated build (with gcc)

+================================

+

+Tor uses gcc 3.4.5 and the rest of the mingw utilities, including MSYS

+from www.mingw.org. Somewhat earlier or later versions of gcc

+presumably also work fine.

+

+Using Cygwin's gcc with the -mno-cygwin switch is not recommended. In

+theory it should work, but Tor hasn't tested that lately. It can

+easily lead to confusing situations where one mixes headers for Cygwin

+from /usr/include with the headers for native software one really

+should use. Ditto for libraries.

+

+If you want to use mingw's gcc, install gcc, win32api, binutils and

+MSYS from www.mingw.org.

+

+Tor invokes configure using:

+

+CC='gcc -mtune=pentium3 -mthreads' CPPFLAGS='-I/opt/gnu/include' \

+	LDFLAGS='-L/opt/gnu/lib -Wl,--enable-auto-image-base' CFLAGS=-O2 \

+	./configure --disable-gtk-doc --prefix=$TARGET

+

+The /opt/gnu mentioned contains the header files for GNU and (import)

+libraries for GNU libintl. The build scripts used to produce the

+prebuilt binaries are included in the "dev" packages.

+

+Please note that the ./configure mechanism should not blindly be used

+to build a GLib to be distributed to other developers because it

+produces a compiler-dependent glibconfig.h. For instance, the typedef

+for gint64 is long long with gcc, but __int64 with MSVC.

+

+Except for this and a few other minor issues, there shouldn't be any

+reason to distribute separate GLib headers and DLLs for gcc and MSVC6

+users, as the compilers generate code that uses the same C runtime

+library.

+

+The DLL generated by either compiler is binary compatible with the

+other one. Thus one either has to manually edit glibconfig.h

+afterwards, or use the supplied glibconfig.h.win32 which has been

+produced by running configure twice, once using gcc and once using

+MSVC, and merging the resulting files with diff -D.

+

+For MSVC7 and later (Visual C++ .NET 2003, Visual C++ 2005, Visual C++

+2008 etc) it is preferred to use specific builds of GLib DLLs that use

+the same C runtime as the code that uses GLib. Such DLLs should be

+named differently than the ones that use msvcrt.dll.

+

+For GLib, the DLL that uses msvcrt.dll is called libglib-2.0-0.dll,

+and the import libraries libglib-2.0.dll.a and glib-2.0.lib. Note that

+the "2.0" is part of the "basename" of the library, it is not

+something that libtool has added. The -0 suffix is added by libtool

+and is the value of "LT_CURRENT - LT_AGE". The 0 should *not* be

+thought to be part of the version number of GLib. The LT_CURRENT -

+LT_AGE value will on purpose be kept as zero as long as binary

+compatibility is maintained. For the gory details, see configure.ac

+and libtool documentation.

+

+Building with Visual Studio

+===========================

+

+In an unpacked tarball, you will find in build\win32\vs9 a solution

+file that can be used to build the GLib DLLs and some auxiliary

+programs. Read the README.txt file in that folder for more

+information. Note that you will need a libintl implementation, and

+zlib.

+

+If you are building from a GIT checkout, you will first need to use some

+Unix-like environment or run build/win32/setup.py, 

+which will expand the VS 2008/2010 project files, the DLL resouce files and

+other miscellanious files required for the build.  Run build/win32/setup.py

+as follows:

+

+$python build/win32/setup.py --perl path_to_your_perl.exe

+

+for more usage on this script, run

+$python build/win32/setup.py -h/--help

+

+Building with MSVC and NMAKE

+============================

+

+If you are building from a GIT snapshot, you will not have all

+makefile.msc files. You should copy the corresponding makefile.msc.in

+file to that name, and replace any @...@ strings with the correct

+value (or use the python script de-in.py from http://hans.breuer.org/gtk/de-in.py).

+

+This is done automatically when an official GLib source distribution

+package is built, so if you get GLib from a source distribution

+package, there should be makefile.msc files ready to use (possibly after some

+editing).

+

+The hand-written makefile.msc files, and the stuff in the "build"

+subdirectory, produce DLLs and import libraries that match what the

+so-called autoconfiscated build produces.

+

+All the MSVC makefiles are for the command line build with nmake.  If

+you want to use the VC-UI you can simply create wrapper .dsp makefiles

+(read the VC docs how to do so).

+

+Some modules may require Perl to auto-generate files. The goal (at

+least Hans's) is to not require any more tools. Of course you need

+the Microsoft Platform SDK in a recent enough - but not too recent - version.

+The last PSDK for Visual Studio 6 is:

+  http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm

+At least install the Core SDK, maybe also the "Tablet PC SDK".

+

+

+Build with:

+

+nmake -f makefile.msc

+  or

+nmake -f makefile.msc DEBUG=1

+

+[

+ The former will create 'release' versions of the DLLs. If you

+ plan to distribute you DLLs please use this command. The latter 

+ will create DLLs with debug information _and_ link them with

+ msvcrtd.dll instead of msvcrt.dll. 

+ Beware: There are known problems with mixing DLLs in one 

+ application, which are build against different runtimes. 

+ Especially the index-to-file mapping used by 'unix-style' file

+ operation - _open() _pipe() etc. - breaks sometimes in strange 

+ ways (for example the Gimp plug-in communication).

+]

+

+Required libraries (not build from svn)

+------------------

+  libintl (gnu-intl),

+

+are available pre-built from the website mentioned above.

+

+Versioning

+----------

+Instead of the Unix and auto* way of tracking versions and resolving

+dependencies (configure; make; make install) involving autoconf,

+automake, libtool and friends the MSVC build uses a different

+approach.

+

+The core of it's versioning is the file build/win32/module.defs.

+It contains entries of the form MODULE_VER, e.g.:

+

+	GLIB_VER = 2.0

+	LIBICONV_VER = 1.3

+

+and the placement of these modules defined as MODULE, e.g.:

+

+	GLIB = $(TOP)/glib

+	LIBICONV = $(TOP)/libiconv-$(LIBICONV_VER)

+

+whereas TOP is defined as the relative path from the respective

+module directory to your top build directory. Every makefile.msc

+needs to define TOP before including the common make file part

+make.msc, which than includes module.defs, like:

+

+TOP = ../..

+!INCLUDE $(TOP)/glib/build/win32/make.msc

+

+(Taken from gtk+/gdk/makefile.msc)

+

+With this provision it is possible to create almost placement

+independent makefiles without requiring to 'install' the libraries and

+headers into a common place (as it is done on Unix, and as Tor does

+when producing his zipfiles with prebuilt GLib, GTK+ etc).

+

+Special Files

+-------------

+	config.h.win32.in : @XXX_MAJOR_VERSION@ needs to be replaced by

+the current version/build number. The resulting file is to be saved

+as 'config.h.win32'. This should be automatically done if a package

+gets build on the Unix platform.

+

+	makefile.msc.in : @XXX_MAJOR_VERSION@ to be replaced. Save as

+makefile.msc.

+

+	<module>.def : every function which should be used from the outside of

+a dll needs to be marked for 'export'. It is common that one needs to change 

+these files after some api changes occured. If there are variables to be

+exported another mechanism is needed, like :

+

+	#ifdef G_OS_WIN32

+	#  ifdef GDK_COMPILATION

+	#    define GDKVAR __declspec(dllexport)

+	#  else

+	#    define GDKVAR extern __declspec(dllimport)

+	#  endif

+	#else

+	#  define GDKVAR extern

+	#endif

+

+

+

+Directory Structure

+-------------------

+all modules should be build in a common directory tree otherwise you 

+need to adapt the file 'module.defs'. They are listed here in increasing

+dependencies order.

+

+<common rootdir without spaces>

+  |

+  +- glib

+  |   |

+  |   +- build          : [this module lives in the SVN root dir]

+  |   |   +- win32

+  |   |       .\module.defs : defines (relative) locations of the headers

+  |   |                       and libs and version numbers to be include 

+  |   |                       in dll names

+  |   |       .\make.msc    : include by almost every 'makefile.msc'

+  |   |

+  |   | .\README.WIN32  : more information how to build

+  |   | .\glibconfig.h.win32.in : similar to config.h.win32.in

+  |   | .\makefile.msc  : master makefile, sub dir makefiles should work 

+  |   |

+  |   +- glib

+  |   +- gmodule

+  |   +- gthread        : does _not_ depend on pthread anymore

+  |   +- gobject

+  |

+  +- pango

+  |   +- pango          : 'native' build does not require extra libs and

+  |   |                 includes the minimal required text renderer

+  |   |                 (there is also a currently slightly broken FreeType2 

+  |   |                 based implementation for win32)

+  |   +- modules (not yet build)

+  |

+  +- atk

+  |   +- atk

+  |       .\makefile.msc : build here

+  |

+  +- gtk+

+  |   | .\config.h.win32 : for all the below

+  |   |

+  |   +- gdk-pixbuf

+  |   |   .\gdk_pixbuf.rc.in : version resource for the DLLs. Needs

+  |   |                 to be converted (filled with version info)

+  |   |                 as described above.

+  |   |

+  |   +- gdk

+  |   |   | .\makefile.msc : some auto-generation is needed to build in the

+  |   |   |             in the subdirectory 

+  |   |   +- win32

+  |   |

+  |   +- gtk

+

+  |

+  +- gimp

+  |   .\makefile.msc    : master makefile to build The Gimp. The makefiles

+  |                     from the sub dirs should work stand alone, but than

+  |                     the user needs to know the build order

+

+  |

+  +- dia                : additionally depends on libart_lgpl (in SVN)

+      |                 and libxml2 ( see http://www.xmlsoft.org/ )

+      +- lib

+      +- app

+      +- objects

+      +- plug-ins

+          +- python

+