-Tor Lillqvist <tml@iki.fi>
-Hans Breuer <hans@breuer.org>
-
-The general parts, and the stuff about gcc and autoconfiscated build
-are by Tor Lillqvist. The stuff about MSVC build is by Hans Breuer.
-
-General
-=======
-
-For prebuilt binaries (DLLs and EXEs) and developer packages (headers,
-import libraries) of GLib, GTK+, GIMP etc for Windows, surf to
-http://www.gimp.org/win32/ . They are for "native" Windows meaning
-they use the Win32 API and Microsoft C runtime library only, no POSIX
-(Unix) emulation layer (like Cygwin).
-
-To build GLib on Win32, you can use either gcc or the Microsoft
-compiler and tools. Both the compiler from MSVC 5.0 and from MSVC 6.0
-have been used successfully.
-
-But note that to just *use* GLib on Windows, there is no need to build
-it yourself. Prepackaged runtime and developer packages are available
-from the webiste above. On Unix, it is quite normal that system admins
-build and install libraries like GLib themselves. But on Windows
-setting up a correct build environment can be quite a task, especially
-if you are used to on Unix just type ./configure; make, and expect
-things to work as smoothly on Windows.
-
-The following preprocessor macros can 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 (msvcrt.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 when
- compiling 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 (indirectly)
-available in all source files that include <glib.h> or GTK+ headers.
-
-Additionally, there are the compiler-specific macros:
-- __GNUC__ is defined when using gcc
-- _MSC_VER is defined when using the Microsoft compiler
-
-G_OS_WIN32 implies using the Microsoft C runtime 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.
-
-Building software that use GLib or GTK+
-=======================================
-
-Even building software that just *uses* GLib or GTK+ also require to
-have the right compiler set up the right way, so if you intend to use
-gcc, follow the relevant instructions below in that case, too.
-
-Tor uses gcc with the -mms-bitfields flag (used to be called
--fnative-struct in gcc 2.x), 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. This
-definitely is something one wants.)
-
-Building GLib
-=============
-
-Again, first decide whether you really want to do this.
-
-Before building GLib you must also have the libiconv library, either
-from the same website mentioned above, or from it's homepage at
-http://clisp.cons.org/~haible/packages-libiconv.html. Libiconv has
-makefiles for building with MS Visual C only, but as it is one source
-file only, building it "by hand" with gcc isn't hard.
-
-You must also have the "intl" library from GNU tettext 0.10.40 (or
-later). Get a prebuilt version from the website mentioned above.
-
-Edit the correct paths to those libraries in build/win32/module.defs
-as appropriate.
-
-Where are the makefiles?
-========================
-
-If you are building from a CVS snapshot, you will not have any
-makefile.mingw or makefile.msc files. You should copy the
-corresponding makefile.mingw.in or makefile.msc.in file to that name,
-and replace any @...@ strings with the correct value.
-
-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.mingw and makefile.msc files ready
-to use (after some editing).
-
-Building GLib with gcc
-======================
-
-Tor uses gcc 3.2. Version 2.95.3 also works.
-
-You can either use gcc running on Cygwin, or the "pure" mingw
-gcc. Using the latter might work better, or at least did at some
-point.
-
-Fetch the latest version of gcc for mingw and the msvcrt runtime, from
-www.mingw.org.
-
-Set up your PATH so that the gcc from the bin directory that got
-created above is the one that gets used. Even if you run the mingw
-gcc, you still want to have Cygwin to run make in.
-
-Then run make -f makefile.mingw. Install the resulting DLLs somewhere
-in your PATH. You can either keep the headers and import libraries
-where they are, or install them somewhere else. There are no rules in
-the makefile.mingws for installing, it is up to you where to put them.
-
-Autoconfiscated build
-=====================
-
-It is also possible to use the auto*, ./configure and libtool
-mechanism when building with gcc. You should be running Cygwin, or
-maybe cross-compiling from real Unix, for the configure script to
-work, obviously. (It should also be possible to use MSYS.) Tor invokes
-configure using:
-
-CC='gcc -mcpu=pentium3' CPPFLAGS='-I/target/include'
- CFLAGS=-O3 LDFLAGS='-L/target/lib' ./configure --with-libiconv
- --disable-static --prefix=/target --host=i386-pc-mingw32
- --enable-maintainer-mode
-
-(on a single line)
-
-But 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 (and config.h, but that
-shouldn't matter, as it isn't seen by GLib-using applications). 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 really shouldn't
-be any reason to distribute separate GLib headers and DLLs for gcc and
-MSVC users, as both compilers generate code that uses the same C
-runtime library. Thus one either has to manually edit glibconfig.h
-afterwards, or use the supplied glibconfig.h.win32. This has been
-produced by running configure twice, once using gcc and once using
-MSVC, and merging the resulting files with diff -D.
-
-There might be other hickups when using auto* and configure to build
-with gcc. Lately Tor has used auto*/configure/libtool exclusively when
-building GLib, GTK+, GIMP etc on Win32, and it seems to work well
-(with some patches applied to the current CVS libtool...).
-
-The hand-written makefile.{mingw,msc} files, and the stuff in the
-"build" subdirectory, produce DLLs and import libraries that match
-what Makefile.am and libtool produces. For GLib, the 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 tucked on. The -0 suffix
-is the value of "LT_CURRENT - LT_AGE". The 0 is *not* simply the micro
-version number of GLib, although, for GLib 2.2.0, it happens to be the
-same. 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.in and libtool documentation.
-
-If you want to run the Cygwin-hosted gcc, and still want to produce
-code that does not use Cygwin, but the msvcrt runtime, in theory it
-should work to use the -no-cygwin flag, but Tor hasn't tested that
-lately.
-
-If you would want to use the Cygwin tools to generate a GLib that
-*does* use the Cygwin runtime, the normal Unix configuration method
-should work as if on Unix. Note that successfully producing shared
-libraries (DLLs) for Cygwin most probably requires you to have a very
-new libtool. (And a new libtool probably requires rather new autoconf
-and automake.) Tor hasn't tested this in a while, either.
-
-Building with MSVC
-==================
-
-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.
-
-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 cvs)
-==================
- libintl (gnu-intl), libiconv
- libtiff, libpng, zlib, libjpeg
-
-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 cvs 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 cvs)
- | and libxml2 ( see http://www.xmlsoft.org/ )
- +- lib
- +- app
- +- objects
- +- plug-ins
- +- python
-
+Tor Lillqvist <tml@iki.fi>\r
+Hans Breuer <hans@breuer.org>\r
+\r
+Note that this document is not really maintained in a serious\r
+fashion. Lots of information here might be misleading or outdated. You\r
+have been warned.\r
+\r
+The general parts, and the section about gcc and autoconfiscated\r
+build, and about a Visual Studio build are by Tor Lillqvist. The\r
+sections about MSVC build with NMAKE is by Hans Breuer. \r
+\r
+General\r
+=======\r
+\r
+For prebuilt binaries (DLLs and EXEs) and developer packages (headers,\r
+import libraries) of GLib, Pango, GTK+ etc for Windows, go to\r
+http://www.gtk.org/download-windows.html . They are for "native"\r
+Windows meaning they use the Win32 API and Microsoft C runtime library\r
+only. No POSIX (Unix) emulation layer like Cygwin in involved.\r
+\r
+To build GLib on Win32, you can use either gcc ("mingw") or the\r
+Microsoft compiler and tools. For the latter, MSVC6 and later have\r
+been used successfully. Also the Digital Mars C/C++ compiler has\r
+reportedly been used.\r
+\r
+You can also cross-compile GLib for Windows from Linux using the\r
+cross-compiling mingw packages for your distro.\r
+\r
+Note that to just *use* GLib on Windows, there is no need to build it\r
+yourself.\r
+\r
+On Windows setting up a correct build environment can be quite a task,\r
+especially if you are used to just type "./configure; make" on Linux,\r
+and expect things to work as smoothly on Windows.\r
+\r
+The following preprocessor macros are to be used for conditional\r
+compilation related to Win32 in GLib-using code:\r
+\r
+- G_OS_WIN32 is defined when compiling for native Win32, without\r
+ any POSIX emulation, other than to the extent provided by the\r
+ bundled Microsoft C library (msvcr*.dll).\r
+\r
+- G_WITH_CYGWIN is defined if compiling for the Cygwin\r
+ environment. Note that G_OS_WIN32 is *not* defined in that case, as\r
+ Cygwin is supposed to behave like Unix. G_OS_UNIX *is* defined by a GLib\r
+ for Cygwin.\r
+\r
+- G_PLATFORM_WIN32 is defined when either G_OS_WIN32 or G_WITH_CYGWIN\r
+ is defined.\r
+\r
+These macros are defined in glibconfig.h, and are thus available in\r
+all source files that include <glib.h>.\r
+\r
+Additionally, there are the compiler-specific macros:\r
+- __GNUC__ is defined when using gcc\r
+- _MSC_VER is defined when using the Microsoft compiler\r
+- __DMC__ is defined when using the Digital Mars C/C++ compiler\r
+\r
+G_OS_WIN32 implies using the Microsoft C runtime, normally\r
+msvcrt.dll. GLib is not known to work with the older crtdll.dll\r
+runtime, or the static Microsoft C runtime libraries libc.lib and\r
+libcmt.lib. It apparently does work with the debugging version of\r
+msvcrt.dll, msvcrtd.dll. If compiled with Microsoft compilers newer\r
+than MSVC6, it also works with their compiler-specific runtimes, like\r
+msvcr70.dll or msvcr80.dll. Please note that it's non totally clear if\r
+you would be allowed by the license to distrubute a GLib linked to\r
+msvcr70.dll or msvcr80.dll, as those are not part of the operating\r
+system, but of the MSVC product. msvcrt.dll is part of Windows.\r
+\r
+For people using Visual Studio 2005 or later:\r
+\r
+If you are building GLib-based libraries or applications, or GLib itself\r
+and you see a C4819 error (or warning, before C4819 is treated as an error\r
+in msvc_recommended_pragmas.h), please be advised that this error/warning should\r
+not be disregarded, as this likely means portions of the build is not being\r
+done correctly, as this is an issue of Visual Studio running on CJK (East Asian)\r
+locales. This is an issue that also affects builds of other projects, such as\r
+QT, Firefox, LibreOffice/OpenOffice, Pango and GTK+, along with many other projects.\r
+\r
+To overcome this problem, please set your system's locale setting for non-Unicode to\r
+English (United States), reboot, and restart the build, and the code should build\r
+normally. See also this GNOME Wiki page [1] that gives a bit further info on this.\r
+\r
+Building software that use GLib or GTK+\r
+=======================================\r
+\r
+Building software that just *uses* GLib or GTK+ also require to have\r
+the right compiler set up the right way. If you intend to use gcc,\r
+follow the relevant instructions below in that case, too.\r
+\r
+Tor uses gcc with the -mms-bitfields flag which means that in order to\r
+use the prebuilt DLLs (especially of GTK+), if you compile your code\r
+with gcc, you *must* also use that flag. This flag means that the\r
+struct layout rules are identical to those used by MSVC. This is\r
+essential if the same DLLs are to be usable both from gcc- and\r
+MSVC-compiled code. Such compatibility is desirable.\r
+\r
+When using the prebuilt GLib DLLs that use msvcrt.dll from code that\r
+uses other C runtimes like for example msvcr70.dll, one should note\r
+that one cannot use such GLib API that take or returns file\r
+descriptors. On Windows, a file descriptor (the small integer as\r
+returned by open() and handled by related functions, and included in\r
+the FILE struct) is an index into a table local to the C runtime\r
+DLL. A file descriptor in one C runtime DLL does not have the same\r
+meaning in another C runtime DLL.\r
+\r
+Building GLib\r
+=============\r
+\r
+Again, first decide whether you really want to do this.\r
+\r
+Before building GLib you must also have a GNU gettext-runtime\r
+developer package. Get prebuilt binaries of gettext-runtime from\r
+http://www.gtk.org/download-windows.html .\r
+\r
+Autoconfiscated build (with gcc)\r
+================================\r
+\r
+Tor uses gcc 3.4.5 and the rest of the mingw utilities, including MSYS\r
+from www.mingw.org. Somewhat earlier or later versions of gcc\r
+presumably also work fine.\r
+\r
+Using Cygwin's gcc with the -mno-cygwin switch is not recommended. In\r
+theory it should work, but Tor hasn't tested that lately. It can\r
+easily lead to confusing situations where one mixes headers for Cygwin\r
+from /usr/include with the headers for native software one really\r
+should use. Ditto for libraries.\r
+\r
+If you want to use mingw's gcc, install gcc, win32api, binutils and\r
+MSYS from www.mingw.org.\r
+\r
+Tor invokes configure using:\r
+\r
+CC='gcc -mtune=pentium3 -mthreads' CPPFLAGS='-I/opt/gnu/include' \\r
+ LDFLAGS='-L/opt/gnu/lib -Wl,--enable-auto-image-base' CFLAGS=-O2 \\r
+ ./configure --disable-gtk-doc --prefix=$TARGET\r
+\r
+The /opt/gnu mentioned contains the header files for GNU and (import)\r
+libraries for GNU libintl. The build scripts used to produce the\r
+prebuilt binaries are included in the "dev" packages.\r
+\r
+Please note that the ./configure mechanism should not blindly be used\r
+to build a GLib to be distributed to other developers because it\r
+produces a compiler-dependent glibconfig.h. For instance, the typedef\r
+for gint64 is long long with gcc, but __int64 with MSVC.\r
+\r
+Except for this and a few other minor issues, there shouldn't be any\r
+reason to distribute separate GLib headers and DLLs for gcc and MSVC6\r
+users, as the compilers generate code that uses the same C runtime\r
+library.\r
+\r
+The DLL generated by either compiler is binary compatible with the\r
+other one. Thus one either has to manually edit glibconfig.h\r
+afterwards, or use the supplied glibconfig.h.win32 which has been\r
+produced by running configure twice, once using gcc and once using\r
+MSVC, and merging the resulting files with diff -D.\r
+\r
+For MSVC7 and later (Visual C++ .NET 2003, Visual C++ 2005, Visual C++\r
+2008 etc) it is preferred to use specific builds of GLib DLLs that use\r
+the same C runtime as the code that uses GLib. Such DLLs should be\r
+named differently than the ones that use msvcrt.dll.\r
+\r
+For GLib, the DLL that uses msvcrt.dll is called libglib-2.0-0.dll,\r
+and the import libraries libglib-2.0.dll.a and glib-2.0.lib. Note that\r
+the "2.0" is part of the "basename" of the library, it is not\r
+something that libtool has added. The -0 suffix is added by libtool\r
+and is the value of "LT_CURRENT - LT_AGE". The 0 should *not* be\r
+thought to be part of the version number of GLib. The LT_CURRENT -\r
+LT_AGE value will on purpose be kept as zero as long as binary\r
+compatibility is maintained. For the gory details, see configure.ac\r
+and libtool documentation.\r
+\r
+Building with Visual Studio\r
+===========================\r
+\r
+A more detailed outline of building GLib with its dependencies can\r
+now be found on the GNOME wiki:\r
+\r
+https://wiki.gnome.org/Projects/GTK%2B/Win32/MSVCCompilationOfGTKStack\r
+\r
+Please do not build GLib in paths that contain spaces in them, as\r
+this may cause problems during compilation and during usage of the\r
+library.\r
+\r
+In an unpacked tarball, you will find in build\win32\vs9 (VS 2008) and\r
+build\win32\vs10 (VS 2010) a solution file that can be used to build\r
+the GLib DLLs and some auxiliary programs under VS 2008 and VS 2010\r
+(Express Edition will suffice with the needed dependencies) respectively.\r
+Read the README.txt file in those folders for more\r
+information. Note that you will need a libintl implementation, zlib, and \r
+libFFI.\r
+\r
+If you are building from a GIT checkout, you will first need to use some\r
+Unix-like environment or run build/win32/setup.py, \r
+which will expand the VS 2008/2010 project files, the DLL resouce files and\r
+other miscellanious files required for the build. Run build/win32/setup.py\r
+as follows:\r
+\r
+$python build/win32/setup.py --perl path_to_your_perl.exe\r
+\r
+for more usage on this script, run\r
+$python build/win32/setup.py -h/--help\r
+\r
+Building with MSVC and NMAKE\r
+============================\r
+\r
+If you are building from a GIT snapshot, you will not have all\r
+makefile.msc files. You should copy the corresponding makefile.msc.in\r
+file to that name, and replace any @...@ strings with the correct\r
+value (or use the python script de-in.py from http://hans.breuer.org/gtk/de-in.py).\r
+\r
+This is done automatically when an official GLib source distribution\r
+package is built, so if you get GLib from a source distribution\r
+package, there should be makefile.msc files ready to use (possibly after some\r
+editing).\r
+\r
+The hand-written makefile.msc files, and the stuff in the "build"\r
+subdirectory, produce DLLs and import libraries that match what the\r
+so-called autoconfiscated build produces.\r
+\r
+All the MSVC makefiles are for the command line build with nmake. If\r
+you want to use the VC-UI you can simply create wrapper .dsp makefiles\r
+(read the VC docs how to do so).\r
+\r
+Some modules may require Perl to auto-generate files. The goal (at\r
+least Hans's) is to not require any more tools. Of course you need\r
+the Microsoft Platform SDK in a recent enough - but not too recent - version.\r
+The last PSDK for Visual Studio 6 is:\r
+ http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm\r
+At least install the Core SDK, maybe also the "Tablet PC SDK".\r
+\r
+\r
+Build with:\r
+\r
+nmake -f makefile.msc\r
+ or\r
+nmake -f makefile.msc DEBUG=1\r
+\r
+[\r
+ The former will create 'release' versions of the DLLs. If you\r
+ plan to distribute you DLLs please use this command. The latter \r
+ will create DLLs with debug information _and_ link them with\r
+ msvcrtd.dll instead of msvcrt.dll. \r
+ Beware: There are known problems with mixing DLLs in one \r
+ application, which are build against different runtimes. \r
+ Especially the index-to-file mapping used by 'unix-style' file\r
+ operation - _open() _pipe() etc. - breaks sometimes in strange \r
+ ways (for example the Gimp plug-in communication).\r
+]\r
+\r
+Required libraries (not build from svn)\r
+------------------\r
+ libintl (gnu-intl),\r
+\r
+are available pre-built from the website mentioned above.\r
+\r
+Versioning\r
+----------\r
+Instead of the Unix and auto* way of tracking versions and resolving\r
+dependencies (configure; make; make install) involving autoconf,\r
+automake, libtool and friends the MSVC build uses a different\r
+approach.\r
+\r
+The core of it's versioning is the file build/win32/module.defs.\r
+It contains entries of the form MODULE_VER, e.g.:\r
+\r
+ GLIB_VER = 2.0\r
+ LIBICONV_VER = 1.3\r
+\r
+and the placement of these modules defined as MODULE, e.g.:\r
+\r
+ GLIB = $(TOP)/glib\r
+ LIBICONV = $(TOP)/libiconv-$(LIBICONV_VER)\r
+\r
+whereas TOP is defined as the relative path from the respective\r
+module directory to your top build directory. Every makefile.msc\r
+needs to define TOP before including the common make file part\r
+make.msc, which than includes module.defs, like:\r
+\r
+TOP = ../..\r
+!INCLUDE $(TOP)/glib/build/win32/make.msc\r
+\r
+(Taken from gtk+/gdk/makefile.msc)\r
+\r
+With this provision it is possible to create almost placement\r
+independent makefiles without requiring to 'install' the libraries and\r
+headers into a common place (as it is done on Unix, and as Tor does\r
+when producing his zipfiles with prebuilt GLib, GTK+ etc).\r
+\r
+Special Files\r
+-------------\r
+ config.h.win32.in : @XXX_MAJOR_VERSION@ needs to be replaced by\r
+the current version/build number. The resulting file is to be saved\r
+as 'config.h.win32'. This should be automatically done if a package\r
+gets build on the Unix platform.\r
+\r
+ makefile.msc.in : @XXX_MAJOR_VERSION@ to be replaced. Save as\r
+makefile.msc.\r
+\r
+ <module>.def : every function which should be used from the outside of\r
+a dll needs to be marked for 'export'. It is common that one needs to change \r
+these files after some api changes occured. If there are variables to be\r
+exported another mechanism is needed, like :\r
+\r
+ #ifdef G_OS_WIN32\r
+ # ifdef GDK_COMPILATION\r
+ # define GDKVAR __declspec(dllexport)\r
+ # else\r
+ # define GDKVAR extern __declspec(dllimport)\r
+ # endif\r
+ #else\r
+ # define GDKVAR extern\r
+ #endif\r
+\r
+\r
+\r
+Directory Structure\r
+-------------------\r
+all modules should be build in a common directory tree otherwise you \r
+need to adapt the file 'module.defs'. They are listed here in increasing\r
+dependencies order.\r
+\r
+<common rootdir without spaces>\r
+ |\r
+ +- glib\r
+ | |\r
+ | +- build : [this module lives in the SVN root dir]\r
+ | | +- win32\r
+ | | .\module.defs : defines (relative) locations of the headers\r
+ | | and libs and version numbers to be include \r
+ | | in dll names\r
+ | | .\make.msc : include by almost every 'makefile.msc'\r
+ | |\r
+ | | .\README.WIN32 : more information how to build\r
+ | | .\glibconfig.h.win32.in : similar to config.h.win32.in\r
+ | | .\makefile.msc : master makefile, sub dir makefiles should work \r
+ | |\r
+ | +- glib\r
+ | +- gmodule\r
+ | +- gthread : does _not_ depend on pthread anymore\r
+ | +- gobject\r
+ |\r
+ +- pango\r
+ | +- pango : 'native' build does not require extra libs and\r
+ | | includes the minimal required text renderer\r
+ | | (there is also a currently slightly broken FreeType2 \r
+ | | based implementation for win32)\r
+ | +- modules (not yet build)\r
+ |\r
+ +- atk\r
+ | +- atk\r
+ | .\makefile.msc : build here\r
+ |\r
+ +- gtk+\r
+ | | .\config.h.win32 : for all the below\r
+ | |\r
+ | +- gdk-pixbuf\r
+ | | .\gdk_pixbuf.rc.in : version resource for the DLLs. Needs\r
+ | | to be converted (filled with version info)\r
+ | | as described above.\r
+ | |\r
+ | +- gdk\r
+ | | | .\makefile.msc : some auto-generation is needed to build in the\r
+ | | | in the subdirectory \r
+ | | +- win32\r
+ | |\r
+ | +- gtk\r
+\r
+ |\r
+ +- gimp\r
+ | .\makefile.msc : master makefile to build The Gimp. The makefiles\r
+ | from the sub dirs should work stand alone, but than\r
+ | the user needs to know the build order\r
+\r
+ |\r
+ +- dia : additionally depends on libart_lgpl (in SVN)\r
+ | and libxml2 ( see http://www.xmlsoft.org/ )\r
+ +- lib\r
+ +- app\r
+ +- objects\r
+ +- plug-ins\r
+ +- python\r
+\r
+[1]: https://wiki.gnome.org/Projects/GTK%2B/Win32/MSVCCompilationOfGTKStack under "Preparations"\r
projects / platform / upstream / glib.git / blobdiff