X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=README.win32;h=6e2d9daaa69db3c9d10266ba066af885c1346866;hb=2a53b4d0e2c98a14aedf31e38f0ad1fb2e8fe26f;hp=5fc2a6be6a3746e11f243ba38a7c8b510a166df1;hpb=0f4173ba4cc5f7bbd39ae49535072ad8dc81aafd;p=platform%2Fupstream%2Fglib.git diff --git a/README.win32 b/README.win32 index 5fc2a6b..6e2d9da 100644 --- a/README.win32 +++ b/README.win32 @@ -1,348 +1,384 @@ -General -======= - -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, a pthreads emulation -library is used. - -To build GLib on Win32, you can use either the Microsoft compiler and -tools, or gcc. Both the compiler from MSVC 5.0 and from MSVC 6.0 have -been used successfully. With gcc I mean gcc-2.95 or gcc-2.95.2 as -distributed by Mumit Khan, running under cygwin-b20.1. To successfully -use gcc, follow the instructions below. We want to use gcc --mno-cygwin, i.e. produce executables (.exe and .dll files) that do -*not* require the cygwin runtime library. This is sometimes called -"mingw32". - -To test the GLib functions, go to the tests subdirectory and enter -`nmake -f makefile.msc check` or `make -f makefile.cygwin check`. - -If you would want to use the cygwin tools to generate executables that -*do* use the cygwin runtime, the normal Unix configuration method -should work as if on Unix. But it won't produce DLLs. At least I -haven't succeeded in that. - -With a little work, it might be possible to use the ./configure -mechanism also with a "mingw32" configuration. - -The following preprocessor macro are used for conditional compilation -related to Win32: - -- G_OS_WIN32 is defined when compiling for Win32, *and* without - any POSIX emulation, other that to the extent provided by the - bundled Microsoft C library (msvcrt.dll) and the pthreads-win32 - library. For instance, pathnames are in the native Windows syntax. - -- _WIN32 is defined by the compiler - -The Win32 port uses the combination with both of those on. As -G_OS_WIN32 is defined in glibconfig.h, it is available to all source -files that use GLib (or GTk+, which uses GLib). - -Additionally, there are the compiler-specific macros: -- _MSC_VER is defined when using the Microsoft compiler -- __GNUC__ is defined when using GCC - -Some of the usage of these macros used to be a bit mixed up, and had -to be straightened out when adding the gcc support. In particular, I -used to check for _MSC_VER in some places where I really wanted to -check for the Microsoft C library, and those checks has now been -changed to G_OS_WIN32. - -G_OS_WIN32 implies using the Microsoft C runtime MSVCRT.DLL. - -Building software that use GLib or GTk+ -======================================= - -Unfortunately, even building software that just *use* 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. - -Pthreads library -================ - -Before building you must get the pthreads library for Win32 from -http://sourceware.cygnus.com/pthreads-win32/. The pthreads-win32 -snapshot from 1999-05-30 is the one that should be used. Edit the -location of the pthreads library and include files in makefile.msc or -makefile.cygwin. The pthreads distribution includes the precompiled dll -and import libraries both for MSVC and gcc. - -The pthreads for Win32 package that the thread support uses supposedly -isn't quite ready yet, and thus threads stuff should not be relied -upon for anything serious. - -Where are the makefiles? -======================== - -If you are building from a CVS snapshot, you will not have any -makefile.msc or makefile.cygwin file. You should copy the -corresponding makefile.msc.in or makefile.cygwin.in file to that name, -and edit the line that sets GLIB_VER to the correct version number. - -This is done automatically when an official distribution package is -built. - -Building with MSVC -================== - -If using the Microsoft toolchain, build with `nmake -f -makefile.msc`. Install with `nmake -f makefile.msc install`. - -Building with gcc -================= - -I use the latest and greatest gcc, gcc-2.95.2. 2.95 will also work. -Earlier version might, but you are on your own. - -Read these instruction carefully and understand them. If you don't -understand or can't follow the instructions, you probably shouldn't -want to build GLib (or GTk+ or GIMP) yourself anyway. - -0) Get and install Cygwin B20.1. - - Move the include files and libraries included in Cygwin out of the - way not to mix things up... (For example, rename - /cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/lib to - lib-no-thanks and rename - /cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/include to - include-no-thanks. - -1) Get gcc 2.95.2 built for Cygwin B20.1 from - ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/gcc-2.95.2/gcc-2.95.2-cygb20.tar.gz - - Install it somewhere, let's say G:\gcc-2.95.2 (//g/gcc-2.95.2 when - in Cygwin). Add //g/gcc-2.95.2/H-i586-cygwin32/bin to your - PATH. I assume you use bash below. - - Replace the specs file in - //g/gcc-2.95.2/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95.2/specs - with the following. (The changes are: Define __MSVCRT__, replace - the "1" versions of the crt files with the "2" ones, replace crtdll - with msvcrt. Also, extra whitespace squished. ) - -================ cut here ================ -*asm: - - -*asm_final: - - -*cpp: --remap %(cpp_cpu) %{posix:-D_POSIX_SOURCE} %{!mno-cygwin:-D__CYGWIN32__ -D__CYGWIN__} %{mno-cygwin:-iwithprefixbefore ../../../../%(mingw_include_path)/include/mingw32 -D__MSVCRT__ -D__MINGW32__=0.2} - -*cc1: -%(cc1_spec) - -*cc1plus: - - -*endfile: - - -*link: -%{mwindows:--subsystem windows} %{mconsole:--subsystem console} %{mdll:--dll -e _DllMainCRTStartup@12} - -*lib: -%{pg:-lgmon} %{!mno-cygwin:-lcygwin} %{mno-cygwin:-lmingw32 -lmoldname -lmsvcrt} %{mwindows:-lgdi32 -lcomdlg32} -luser32 -lkernel32 -ladvapi32 -lshell32 - -*libgcc: --lgcc - -*startfile: -%{mdll: %{mno-cygwin:dllcrt2%O%s}} %{!mdll: %{!mno-cygwin:crt0%O%s} %{mno-cygwin:crt2%O%s} %{pg: %{!mno-cygwin:gcrt0%O%s} %{mno-cygwin:gcrt2%O%s}}} - -*switches_need_spaces: - - -*signed_char: -%{funsigned-char:-D__CHAR_UNSIGNED__} - -*predefines: --Di386 -D_WIN32 -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) - -*cross_compile: -0 - -*version: -2.95.2 - -*multilib: -. !mno-cygwin;mingw32 mno-cygwin;; - -*multilib_defaults: - - -*multilib_extra: - - -*multilib_matches: -mno-cygwin mno-cygwin; - -*linker: -collect2 - -*cpp_486: -%{!ansi:-Di486} -D__i486 -D__i486__ - -*cpp_586: -%{!ansi:-Di586 -Dpentium} -D__i586 -D__i586__ -D__pentium -D__pentium__ - -*cpp_k6: -%{!ansi:-Di586 -Dk6} -D__i586 -D__i586__ -D__k6 -D__k6__ - -*cpp_686: -%{!ansi:-Di686 -Dpentiumpro} -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ - -*cpp_cpu_default: -%(cpp_586) - -*cpp_cpu: --Acpu(i386) -Amachine(i386) %{!ansi:-Di386} -D__i386 -D__i386__ %{mcpu=i486:%(cpp_486)} %{m486:%(cpp_486)} %{mpentium:%(cpp_586)} %{mcpu=pentium:%(cpp_586)} %{mpentiumpro:%(cpp_686)} %{mcpu=pentiumpro:%(cpp_686)} %{mcpu=k6:%(cpp_k6)} %{!mcpu*:%{!m486:%{!mpentium*:%(cpp_cpu_default)}}} - -*cc1_cpu: -%{!mcpu*: %{m386:-mcpu=i386 -march=i386} %{m486:-mcpu=i486 -march=i486} %{mpentium:-mcpu=pentium} %{mpentiumpro:-mcpu=pentiumpro}} - -*mingw_include_path: -i586-cygwin32 - -*link_command: -%{!fsyntax-only: %{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %D %o %{!nostdlib:%{!nodefaultlibs:%G %L %G}} %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} - }}}}}} - -================ cut here ================ - -2) Get the Mingw32 runtime sources from - ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2/runtime-source-19991107.zip - - Unpack it somewhere, say //g/src/mingw-runtime-19991107 . - - Apply the following patches: - - This makes the mingwm10.dll depend on the stuff that is needed - to build it.: - -================ cut here ================ -diff -ru2 ./mingw/Makefile.in ../../src/mingw-runtime-19991107/mingw/Makefile.in ---- ./mingw/Makefile.in Sun Nov 07 12:19:22 1999 -+++ ../../src/mingw-runtime-19991107/mingw/Makefile.in Mon Nov 08 14:55:38 1999 -@@ -138,5 +138,5 @@ - --base-file mingwthrd.base --output-exp mingwthrd.exp - --$(THREAD_DLL_NAME) mingwthrd.def: $(DLL_OFILES) Makefile -+$(THREAD_DLL_NAME) mingwthrd.def: $(DLL_OFILES) Makefile libmingw32.a libmoldname.a lib$(RUNTIME).a dllcrt$(CRT_ID).o - $(DLLTOOL) --as $(AS) --output-def mingwthrd.def $(DLL_OFILES) - $(CC) -Wl,--base-file=mingwthrd.base $(DLL_CC_STUFF) -================ cut here ================ - - This enables building the profiling gcrt2.o. I don't know how useful - it is, though, there doesn't seem to be any gprof command in cygwin. - -================ cut here ================ -diff -ru2 ./mingw/profile/Makefile.in ../../src/mingw-runtime-19991107/mingw/profile/Makefile.in ---- ./mingw/profile/Makefile.in Sun Nov 07 12:18:56 1999 -+++ ../../src/mingw-runtime-19991107/mingw/profile/Makefile.in Mon Nov 08 12:12:12 1999 -@@ -76,8 +76,8 @@ - - gcrt1.o: gcrt0.c -- $(CC) -U__MSVCRT__ -c -o $@ $(CPPFLAGS) $(CFLAGS) $? -+ $(CC) -U__MSVCRT__ -c -o $@ $(CPPFLAGS) $(ALL_CFLAGS) $? - - gcrt2.o: gcrt0.c -- $(CC) -D__MSVCRT__ -c -o $@ $(CPPFLAGS) $(CFLAGS) $? -+ $(CC) -D__MSVCRT__ -c -o $@ $(CPPFLAGS) $(ALL_CFLAGS) $? - - Makefile: Makefile.in config.status configure -================ cut here ================ - - This fixes a typo in wingdi.h: - -================ cut here ================ -diff -ru2 ./w32api/include/wingdi.h ../../src/mingw-runtime-19991107/w32api/include/wingdi.h ---- ./w32api/include/wingdi.h Thu Nov 04 03:42:40 1999 -+++ ../../src/mingw-runtime-19991107/w32api/include/wingdi.h Mon Nov 08 12:48:02 1999 -@@ -304,5 +304,5 @@ - #define FW_BOLD 700 - #define FW_EXTRABOLD 800 --#define FW_ULTRABOLD FW_EXTRABOOLD -+#define FW_ULTRABOLD FW_EXTRABOLD - #define FW_HEAVY 900 - #define FW_BLACK FW_HEAVY - -================ cut here ================ - - fpos_t should be long long with MSVCRT.DLL: - -================ cut here ================ ---- stdio.h~ Thu Aug 19 02:47:42 1999 -+++ stdio.h Mon Jan 17 21:58:20 2000 -@@ -296,6 +296,11 @@ - * it is fairly evident that the fpos_t type is a long (in CRTDLL.DLL). - * Perhaps an unsigned long? TODO? -+ * In MSVCRT.DLL it's a long long, however. - */ -+#ifdef __MSVCRT__ -+typedef long long fpos_t; -+#else - typedef long fpos_t; -+#endif - - int fgetpos (FILE* fileGetPosition, fpos_t* pfpos); -================ cut here ================ - - - (I haven't checked yet if other small errors I have noticed in - previous w32api header versions have been corrected.) - -3) Now you should build the mingw32 and w32api runtime and import libraries. - - Go to //g/src/mingw-runtime-19991107/w32api. Enter: - - CC='gcc -mno-cygwin' ./configure i586-pc-mingw32msvc - make - - That should complete in a while. It should produce a lot of .a - libraries (both import libraries, and a couple of archive - libraries), and some .o files. I don't trust make install to do - what I want (especially as I didn't give any --prefix argument to - the configure...), so I install the stuff manually: - - cd lib - mkdir //g/gcc-2.95.2/H-i586-cygwin32/lib/mingw32 - cp *.a //g/gcc-2.95.2/H-i586-cygwin32/lib/mingw32 - cp crt2.o crtdll2.o //g/gcc-2.95.2/H-i586-cygwin32/lib/mingw32 - cd ../include - mkdir //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32 - cp *.h //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32 - - Now go to ../../mingw, and run the same configure command, and do a - make: - - CC='gcc -mno-cygwin' ./configure i586-pc-mingw32msvc - make - - Then install the mingw32 libraries and headers: - cp *.a //g/gcc-2.95.2/H-i586-cygwin32/lib/mingw32 - mkdir //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32/sys - cp include/sys/*.h //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32/sys - cp include/*.h //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32 - - -4) Get an updated set of binutils for cygwin B20.1 from - ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/gcc-2.95.2/binutils-2.9.4-cygb20.tar.gz - Unpack that in your /cygnus/cygwin-b20 directory. The relevant - difference is: dlltool now parses GCC generated export directives - correctly for DATA items. - -5) Whew. That hopefully should be it. - -Next, go back to the GLib directory and build using `make -f -makefile.cygwin`. Building the dlls uses the script build-dll which -is somewhat of a hack. But I couldn't get things working in a cleaner -way. - ---Tor Lillqvist +Tor Lillqvist +Hans Breuer + +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 . + +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. + +For people using Visual Studio 2005 or later: + +If you are building GLib-based libraries or applications, or GLib itself +and you see a C4819 error (or warning, before C4819 is treated as an error +in msvc_recommended_pragmas.h), please be advised that this error/warning should +not be disregarded, as this likely means portions of the build is not being +done correctly, as this is an issue of Visual Studio running on CJK (East Asian) +locales. This is an issue that also affects builds of other projects, such as +QT, Firefox, LibreOffice/OpenOffice, Pango and GTK+, along with many other projects. + +To overcome this problem, please set your system's locale setting for non-Unicode to +English (United States), reboot, and restart the build, and the code should build +normally. See also this GNOME Wiki page [1] that gives a bit further info on this. + +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 +=========================== + +A more detailed outline of building GLib with its dependencies can +now be found on the GNOME wiki: + +https://wiki.gnome.org/Projects/GTK%2B/Win32/MSVCCompilationOfGTKStack + +Please do not build GLib in paths that contain spaces in them, as +this may cause problems during compilation and during usage of the +library. + +In an unpacked tarball, you will find in build\win32\vs9 (VS 2008) and +build\win32\vs10 (VS 2010) a solution file that can be used to build +the GLib DLLs and some auxiliary programs under VS 2008 and VS 2010 +(Express Edition will suffice with the needed dependencies) respectively. +Read the README.txt file in those folders for more +information. Note that you will need a libintl implementation, zlib, and +libFFI. + +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. + + .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. + + + | + +- 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 + +[1]: https://wiki.gnome.org/Projects/GTK%2B/Win32/MSVCCompilationOfGTKStack under "Preparations"