Re: EXTERNAL: Re: win32 installer?

[Dieter Verfaillie <dieterv optionexplicit be>]

On 17/07/2012 14:23, John Stowers wrote:
> > Yup, that's the bundle (a first step towards a proper sdk), which
> > I'm uploading to http://optionexplicit.be/projects/gnome-windows/GTK+3/
> > from time to time... For now at least, once stable it'll go to
> > ftp.gnome.org :)
>
> aside #1:
>
> Did you/anyone check out the jhbuild-like build system the gstreamer
> folks created to build the gstreamer SDK on windows/other? It looks
> quite nice (and obviously worked as recently as 1 month ago...)

I just wrote a couple of notes in this mail (towards the end of the 
message):
https://mail.gnome.org/archives/gtk-devel-list/2012-July/msg00027.html

Which lists a couple of things jhbuild is not (yet?) capable of doing.
Above all, I don't like it not building out of tree though :P

> aside #2:
>
> Getting a windows built SDK working is on my TODO for GUADEC (at least
> a python + gobject-introspection one at the pygobject hackfest).

pygobject should be good to go (unless regressions snuck in while I
wasn't looking). g-i has my branch which depends on the XDG_DATA_DIRS
fix from https://github.com/dieterv/glib/commits/windows
There's a couple of questions left to solve there too...

Then we have to devise a way to get rid of all those _utf8
backward compatibility defines. Otherwise, on all platforms you'd
be able to use in python gdk_pixbuf_new_from_file() except on
32 bit windows where it would be gdk_pixbuf_new_from_file_utf8()...
For example see:
http://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/gdk-pixbuf-io.c#n1160
(over here, cgit line numbers do not correspond with their
respective source lines so search for #undef gdk_pixbuf_new_from_file).

I've spent some time thinking on this and it seems to me we can safely
remove all of them (in gtk, gdk-pixbuf, glib, etc) without risking
breakage because these where introduced to ensure abi compatibility
with some ancient glib (2.12 iirc) 32 bit win32 binaries. Now, some
changes broke abi anyway somewhere between glib 2.24 (corresponds with
gtk bundle 2.16) and glib 2.28 (corresponds with gtk bundle 2.24)
so there's no longer any reason to keep these old
"g_locale_to_utf8 (filename," alternatives around.

Does this sound sane? Would it even be acceptable? It sure would be
the easiest way out. Note: somebody should at least independently
check these facts before anybody goes further down this road though,
I might have misunderstood the intent of those alternatives, who
knows ;)

> Anyone else interested in hacking on this with me?

Yes! Unfortunately I won't be at GUADEC :(

mvg,
Dieter