blob: 27c4b7fe06dfa9bcbaa62a5f53dd825c1c5af997 [file] [log] [blame]
For more information about the port or GLib, GTk+ and the GIMP to
native Windows, and pre-built binary packages, see
http://www.iki.fi/tml/gimp/win32/ . "Native" means that we use the
Win32 API only, and not any POSIX emulation layer except that provided
by the Microsoft runtime C library. Additionally the pthreads
emulation library is used.
As for now, to build GLib on Win32, you need the Microsoft compiler
and tools. Both the compiler from MSVC 5.0 and MSVC 6.0 have been used
successfully.
Before building you must get the pthreads library for Windows from
http://sourceware.cygnus.com/pthreads-win32/. Edit the location of the
pthreads library and include files in makefile.msc. Also edit the BIN
definition in makefile.msc.
Build with `nmake -f makefile.msc`. Install with `nmake -f
makefile.msc install`.
Support for building using the cygwin tools (without depending on the
cygwin runtime, i.e. "mingw32"), and maybe LCC-Win32 might be added
later. When using the cygwin tools *with* the cygwin runtime the
normal Unix configuration method should work as if on Unix (knock on
wood).
With a little work, it might be possible to use the ./configure
mechanism also with a "mingw32" configuration. I.e. building GLib for
Win32 would use the cygwin tools (and runtime), but the produced
libraries would not depend on the cygwin runtime being present.
The following preprocessor macros are used for conditional compilation
related to Win32:
- WIN32 is defined when compiling for the Win32 platform, regardless
if using the X11 or Win32 windowing API (in the case of GLib, this
dimension isn't significant), regardless whether using a more or
less complete POSIX emulation runtime layer (like Cygwin) or not.
- NATIVE_WIN32 is defined when compiling for Win32, *and* without
any POSIX emulation, other that to the extent provided by the
(Microsoft) C library, or the pthreads-win32 library. For instance,
pathnames use the native Windows syntax.
- _MSC_VER is defined when using the Microsoft compiler.
Currently the Win32 port uses the combination with all three of those
on, but eventually the cygwin compiler and tools will be supported
also, and in that case _MSC_VER wouldn't be defined.
Some of the usage of these macros is probably a bit mixed up, and will
have to be straightened out when actually trying other combinations.
The pthreads for Win32 package that the thread support uses isn't
released yet, and thus threads really should not be relied upon.