In this page we're going to gather as much information as we can on the effort of making the Gtk+ Windows building, packaging and developing more pleasant.
Contents
Goals
These goals are ordered by priority:
Be able to cross compile Gtk+ and all its dependencies to not depend on external builds as we do right now on the GnuWin32 gettext, zlib and so on.
Be able to package an official .msi installer with a automated procedure (depends on the cross compile thing). Msi installers allows sysadmins to deploy apps into an ActiveDirectory enviroment with very little effort.
- Be able to build Win32 bindings using the same toolchain and achieve packaging integration (as the all-in-one pygtk installer).
- Allow third party apps to create their own .msi with our toolchain and embed the gtk runtime.
- Ease the build of Gtk+ apps on windows, which is kinda impossible without a shell nowdays, enabling a jhbuild moduleset that only depends on MinGW or MSVC would be a huge step. This will enable more testers and patchers!
- Be able to cross compile Glib and all its dependencies for WinCE
Tasks
Task |
Status |
People working on it |
Comments |
Add support for WiX assemblies to buildows |
|
|
|
Try to get WiX working with Wine and Mono/Win32 |
Research |
jdahlin |
Make buildows work with standard jhbuild |
Pending |
asabil |
|
Cross compiling GLib for WinCE |
Research |
Tools
Buildows tool to generate WiX files from a GNU/Linux box. It currently needs a last step on a windows box, due to msi native code that perhaps can be avoided using wine.
Small python tool that gets all the Tor's binary zipfiles and unpack them using a .ini as a binary module set.
WiX Installer, an opensource Microsoft tool to create .msi installers
All-in-One PyGTK Installer, all the dependencies in one installer, got 8000 downloads on the first day, so there's a huge audience there. There are no more releases of it, partially because AlbertoRuiz was not happy on the state of the underlaying installers, specially the Gtk+ one.
Waf a potential enabler of a more pleasant cross compiling experience on Win32 compared to autotools.
CeGCC Cross-development tools for Windows CE (PocketPC).
All-in-One GTK+/Glade/OpenGL/GtkGlExt Installer: updated libraries to work in Windows with Gtk+, OpenGL, GtkGlExt, Glade
Packaging
Innosetup http://www.jrsoftware.org/isinfo.php
Bug triaging
External Links
Cross compiling GTK+ for Win32 wiki entry.
Bratsche's cross compiling GTK+ for Win32.
OABuild, tool to build some FLOS Software using a Win32/VS toolchain
Philip Whithnall's Cross Compiling GTK+ Apps for Win32
Blog posts
(30/01/2008) Pachi's post on the state and call for help.
(16/12/2007) JohnStowers effort to improve the jhbuild process on windows.
(07/01/2008) FredericPeters bug triaging of AlbertoRuiz and JohnStowoers patches to make jhbuild not depend on bash.
(20/09/2007) GMAE on WinCE
Bugs
- gettext needs at least version 0.17 to avoid bug due to conflicting def of SUBLANG_BENGALI_INDIA SUBLANG_PUNJABI and SUBLANG_ROMANIAN with msys.
Savannah's bug #22184, gettext not compiling properly on cross compilation.
Gnome's #513826, gtk 2.12 finds cups-config on the linux host but then it won't find the headers, exiting from the configure script with an error. Patch is proposed.
Buildows additional information
Buildows first runs jhbuild on the provided modules and later runs wixer.wixit on the baked elements for the wixets dir
The jhbuild version that buildows is based on has been lightly patched. The mofified files are (probably) just jhbuild/config.py, jhbuild/modtypes/tarball.py and jhbuild/modtypes/autotools.py (grep -Ri bundle * can help finding the modified files).
These modification are used to get the desired layout for the built files (using $DESTDIR/$PREFIX/), as a sort of make install replacement (done tweaking the $DESTDIR var), and are inserted in the do_install method of those files (tarball.py and autotools.py). The change in config.py just adds a new destdir var.
Current versions of jhbuild seem to be using makeinstallargs and that could be used to pass the desired $DESTDIR (see jhbuild/modtypes/autotools.py). It would be needed to find the way to add that makeinstallargs for the 'baked' elements.
Cracktastic Ideas
Perhaps a new module type called installer could be created. Hooks could then be added before and after make, where http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/215418 code like this calculates the new files. When jhbuild evaluates the installer (which may depend on multiple modules) it gets passed the instace of this file monitor, and is able to look at all the new files, and the location they were installed to. This information could then be sufficient to transform into the wix/nsis format for listing the files included in the installer. This would make the process for creating unified installers the same as the process for creating installers for single packakes
