PyGObject on Windows

[Dieter Verfaillie <dieterv optionexplicit be>]

Hi,

I'm excited to announce that after months of hard work, PyGObject/
gobject-introspection and the stack it depends on finally reached
the point where it is possible to create a GTK+3 Gtk.Window, a
Gtk.Button, connect some signals and make it do something on
Windows [0]. Yay!

To satisfy basic dependencies like zlib, gettext, etc and save some
time, I've started this work on top of the latest GTK+-bundle which
you can find here:
https://github.com/dieterv/legacynativebuilds/downloads [1]

You'll also need pkg-config 0.26-1 from that page as it fixes a
long standing bug and removes the need for the pkg-config wrapper
script that has been used by various people when building
with MinGW/MSYS. Now that the basics are taken care of, let's get
to the exiting bits...

source tarballs:
- libffi-3.0.10rc8: with the attached libffi.patch applied;

master branches with various fixes, workarounds and
sometimes dirty hacks just to get things going [2]:
- glib: https://github.com/dieterv/glib/tree/windows
- gi: https://github.com/dieterv/gobject-introspection/tree/windows
- atk: https://github.com/dieterv/atk/tree/windows
- pango: https://github.com/dieterv/pango/tree/windows
- gdk-pixbuf: https://github.com/dieterv/gdk-pixbuf/tree/windows
- gtk+: https://github.com/dieterv/gtk/tree/windows
- py2cairo: https://github.com/dieterv/py2cairo/tree/windows
- pygobject: https://github.com/dieterv/pygobject/tree/windows

PyGObject is a bit special here: it is the master branch with Johns
patches from bug 642048 applied on top. Except somehow, and only on
Windows it seems, make no longer honors the order of SUBDIRS of the
original gi/Makefile.am, leading to much pain and the build failing
miserably. Never found out why (and frankly got tired of searching),
so I started refactoring the Makefile.am files for libpyglib, gi,
_glib and _gobject into a non-recursive automake project instead.
It's still missing maintainer related rules and needs work to get
the documentation going again, but at least it's a start.
And it works :)

Yes, this also means we would be able to get rid of setup.py and
dsextras.py as nobody seems to have cared about visual studio for
years anyway. And if such a thing becomes needed again in the future,
it would still be available in the sources history.

What does this all mean? Nothing really. It will take even more work
to find proper solutions to some workarounds I've used and even more
work to massage all those changes into patches and patch-sets that can
be proposed for inclusion on bugzilla. That means all this is eventually
going to have to be reviewed by the various maintainers of these
modules, not all of which have experience with or interest in Windows
support. Frustrating times ahead!

So hold your horses there, we're still a long way from providing
binaries or even an installer! There's also some portability trouble
ahead that I haven't yet studied nor completely understand yet,
but some functions seem to get special treatment on Windows?

For example, in glib: g_file_test doesn't exist, but g_file_test_utf8
does. In gdk-pixbuf: gdk_pixbuf_new_from_file doesn't exist, but
gdk_pixbuf_new_from_file_utf8 does. And there's a scary amount
of other examples all over the place...

At first sight, this seems to be intentional (if we can trust the
various .symbols files), but poses trouble with language bindings as
for example PyGObject's gtk-demo.py doesn't work out of the box.
Bummer...

Oh well, constructive comments, review and help in any shape or form
most welcome!

mvg,
Dieter

[0] Well, PyGObject/GI showed it's first sign of life on Windows
    Thursday 07/07/2011 20:02:10 CEST, but it didn't yet do much ;)

[1] There's more info on GTK+-bundle maintenance in this thread:
    http://mail.gnome.org/archives/gtk-devel-list/2011-July/msg00012.html

[2] Warning: windows branches for each repo are treated as local topic
    branches that just happen to be shared there, so do expect
    non-fast-forward updates!

ps. If you made it here: Apologies for the lack of a non-TL;DR version
    and thanks for reading :)

--- Makefile.am  2011-06-14 12:58:05 +0200
+++ Makefile.am        2011-06-14 17:32:31 +0200
@@ -189,6 +189,9 @@ AM_CFLAGS += -DFFI_DEBUG
 endif

 libffi_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LTLDFLAGS) $(AM_LTLDFLAGS)
+if X86_WIN32
+libffi_la_LDFLAGS += -no-undefined
+endif

 AM_CPPFLAGS = -I. -I$(top_srcdir)/include -Iinclude -I$(top_srcdir)/src
 AM_CCASFLAGS = $(AM_CPPFLAGS)
diff -Naurp libffi-3.0.10rc8-orig//Makefile.in libffi-3.0.10rc8/Makefile.in
--- Makefile.in  2011-06-14 12:58:05 +0200
+++ Makefile.in        2011-06-14 17:33:39 +0200
@@ -506,7 +506,7 @@ nodist_libffi_la_SOURCES = $(am__append_
 libffi_convenience_la_SOURCES = $(libffi_la_SOURCES)
 nodist_libffi_convenience_la_SOURCES = $(nodist_libffi_la_SOURCES)
 AM_CFLAGS = -g $(am__append_28)
-libffi_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LTLDFLAGS) $(AM_LTLDFLAGS)
+libffi_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LTLDFLAGS) $(AM_LTLDFLAGS) -no-undefined
 AM_CPPFLAGS = -I. -I$(top_srcdir)/include -Iinclude -I$(top_srcdir)/src
 AM_CCASFLAGS = $(AM_CPPFLAGS)
 all: fficonfig.h