Contents
There is quite a bit of energy around maintaining Windows ports of Gtk+, GLib and other Gnome apps and libraries but it's currently lacking coordination. This page is supposed to become an overview of the currently active efforts and the reasons for doing things in specific ways. With that in mind we can decide what the best course of action is to support Gtk/Gnome on Windows.
Resources
The windows-devel-list@gnome.org mailing list
Motivations/Goals
We want to do continuous automated builds to test portability & stop the neglect that the Windows platform currently suffers
- Make it easy to port Gnome applications to Windows (including installers)
- Allow Windows developers to use Gnome platform libraries
- Support the large Python/Gtk+ on Windows community
Compilers
Two options have theoretical support on Windows - mingw/GCC and Microsoft Visual C. We want to support developers using either toolchain to compile their app. In theory the toolchain used to compile Gtk itself is an orthogonal issue.
mingw/GCC (native)
- Has a reasonable tool ecosystem (gdb, etc) but incompatible with Microsoft's, and lacks the deep platform integration of their tools
- Not a common choice for Windows-centric developers, although it does have many users
- GCC is used on pretty much every other platform these days
- To use MSVC-compiled Gtk+ in a mingw program, Gtk+ must have been linked against the original MSVCRT.DLL, which requires using an old version of MSVC or performing some elaborate hacks.
GLib no longer compiles with the mingw.org version of GCC, due it targetting too old an architecture. The version available from mingw-w64 must be used instead.
fedora mingw
- autotools scripts run 100x faster in Linux
Wine has some problems running Gtk+ apps, but is surprisingly capable - most of a 'make check' should work under emulation.
- Well supported and tested these days
Microsoft Visual C
- Can produce symbols for Windows debuggers;
- Closed source (although free as part of the platform SDK)
- Not a very good C compiler - lacks a lot of C99 (and even bits of C89) - while GLib and Gtk+ are written with portability in mind, a lot of Gnome applications probably are not
- Currently not usable with Autotools, although a wrapper shell script could perhaps fix this
- C runtime library issue - from VC 7 onwards, the C runtime library used by default is not distributed with all versions of Windows and problems occur when a program and some of its DLLs are linked against different versions of the runtime.
- To use mingw-compiled Gtk+ in an MSVC program, you must force Visual C to link against the original MSVCRT.DLL - which avoids you having to distribute your own C runtime, but apparently it's almost impossible to convince new Visual C versions to actually use this library.
- Better IDE and more popular with Windows-focused developers
Cygwin
- Another gcc port, but with a much thicker portability layer. Good Unix emulation so most Gnome code probably works already, if you can deal with the slow speed and dependency on the large cygwin1.dll.
Build system
In theory both compilers can be used with both build systems, but autotools works best with gcc and MSVC requires it's own build files.
autotools / jhbuild
- Project standard; avoids having to maintain a separate build system
- autotools under MSYS run VERY slowly, and are quite temperamental
- autotools on Linux, however, works great for cross-compiling
jhbuild works, but is currently maintained as a fork: http://afuera.me.uk/jhbuild-windows/
Custom scripts
- It's horrible to maintain a parallel build system, but at least most of the work is already done:
Tor Lillqvist / Dieter Verfaillie: https://www.github.com/dieterv/legacynativebuilds
Fan Chun-wei is maintaining Visual C build files for the Gtk+ stack in Gnome git. A walk-through on how to build the GTK+ stack from scratch can now be found in https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack
- If you want to build anything more than Gtk+ and GStreamer you'll need to do all sorts of work yourself
OpenSUSE Build Service
The windows:mingw project builds packages using mingw64/GCC on virtual hosts, accessible via a web-interface or Linux command line utility. Despite its name, the OBS is very much usable without using openSUSE. It has the following advantages:
- Automated builds, monitoring of build status through web-interface
- It's compiling in the cloud: that's one buzzword-compliance bonus point!
- Provides packages for win32/win64, including Gtk3, all dependencies and some applications
- Can also make installers for applications (currently just Evolution, using NSIS)
- It is possible for multiple people to work on packaging for Windows, so effort can be spread and we can work together.
- A great way to have a completely open-source stack for building great GNOME apps for Windows automatically.
Some downsides are:
The resulting packages are in RPM format, which is quite useless for developers on Windows. It does have the advantage that the dependencies are tracked. There is a Python script to automatically download the latest rpm packages (including dependencies) and repackage them in a zipfile, so a all-in-one gtk zip can be made with a single command.
- These packages are not immediately useful to developers using MSVC. This situation should be improved.
mgwport
mingw.org have recently introduced mgwport which aims to automate building of packages suitable for mingw-get.
Dependencies
mingw on Windows (MSYS)
On the mingw side, MSYS provides a pretty good environment these days. Some things are still needed - currently provided by 'jhbuild bootstrap' using the binary module type. This has always been a hack and is not welcome upstream.
An alternative would be bring together the dependencies using a shell script and provide a binary blob (or an MSYS package repository), avoiding the need for any binary module handing in jhbuild. This looks especially attractive given that we will probably have to use our own version of the compiler at the moment.
mingw on Linux (cross-compiling)
Cross-compiling all the dependencies is a bit more work, but not difficult as almost all open-source software comes with an autotools based build-system and once the cross-building environment is set up, compiling goes pretty smooth.
Packaging/Distribution
- For application developers the recommended approach is to include all the Gtk binaries and dependencies with the application. Nothing gets installed in the system directories, the old approach of a shared Gtk+ runtime that was separately installed and used by all gtk applications has been abandoned.
- This means that a simple zipfile containing the binaries should suffice, because that way the application developer can easily package the binaries with the application in his installer. That being said, something more sofisticated (e.g. keeping track of dependencies) could be useful so that the application developer gets exactly all the binaries he needs. (see the next point) Dependency tracking is not useful for end users though. (see previous point)
- Provisioning is less than ideal - you have a giant ZIP file, or a whole bunch of separate ones. And this is only for Gtk+ - if you want to use eg. GStreamer as well, or some gnu-win32 libraries, you have to search and hack.
Application Packaging
A related problem to distributing the runtime, is also distributing an application using the runtime. The consensus is that all gtk applications should include, on non-unix platforms, a copy of all libraries used. To create installers/bundles which do this a number of utilities exist
- NSIS, WiX, Inno Setup
bockbuild - lightweight package and bundling system for Mono applications on Windows / OSX
python-gtk-windows-deploy - python distutils helper that bundles single python/gtk applications and generates installers for windows
pygtk2exe - similar to above, proof of concept implementation of the same thing as a distutils command class.
What do other projects do
- Qt: supports Visual C and mingw on Windows.
OSSBuild: gstreamer builds for Windows. Claim to have solved the MSVCRT runtime issue - need to investigate how.
Conclusions
Unfortunately there are no clear answers at the moment. We should work with the current momentum, and support building the platform libraries with Visual C using the custom build tools. And support building as much of Gnome as possible with mingw and jhbuild.
Possible solutions / future work
Practical
- We already have to build 32-bit and 64-bit versions - perhaps provide separate MSVC and mingw packages; using the appropriate C runtime library in each case?
- MSYS recently introduced a simple package management system - it seems easy to extend, we could distribute all the Gtk+/Gnome binary packages that way at least for mingw users.
- MSVC users don't generally get a better developer experience than "here's some .ZIP files" anyway, correct?
- Add support to jhbuild for generating binary packages from a build tree - this would be more flexible than Tor's shell scripts, although initially mingw-only
- Merge the windows branch of jhbuild. This requires
- Fixing the binary module type problem - my current feeling is just to remove it and use the mingw-get package manager to provide build deps
- Merging the other various hacks
Cracktical
- Add support to mingw for generating MSVC debugging symbols and linking against newer MSVCRT DLL's, to avoid the need to support actually compiling with MSVC ourselves
Get rid of jhbuild and build everything using Nix
- New JHbuild does proper manifest generation and tracking through install (using DESTDIR) - this will allow automagic installer creating for applications and their dependencies; i.e. generate an innosetup file that includes everything in the manifest for the project, and everything it depends on.
Cross-compile everything using Scratchbox and Wine. This requires fixing the issues that currently prevent Gtk+_programs from running correctly under Wine.