Re: GTK+3 win32/64 build environment

[Colin Walters <walters verbum org>]

On Wed, 2013-04-10 at 12:50 +0200, tarnyko tarnyko net wrote:
> OK folks. 
>
> As the initial contributor of the win32 buildenv, here are my reasons for 
> preferring a native build instead of cross-compiling from Linux. Sorry if it 
> is long, but I think explaining things will help. 

Thanks!  Personally my primary interest for a while has been in getting
a reliable mingw32 cross build of just GLib up, but I haven't found the
time.

> First, please note that we don't have to buy a Windows license. There is a 
> *free* (as in free beer) edition of Windows named "Hyper-V Server". It's 
> stripped-down in terms of GUI, but works well for this purpose. 
>
> Here is a link to licensing stuff : 
>
> http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/db3f 
> c7d7-1772-41fb-b878-4574b3c39703/ 

Hmmm...but it looks to me like this edition is only designed for
physical deployments, whereas I think we'd really want it virtualized
(both for developers running Linux on their laptops who want to test,
and inside the GNOME infrastructure).  Or does it run in a VM ok?

At least for GNOME servers it'd likely be worth paying for an actually
supported version of Windows so it gets security updates, even if it is
completely firewalled off from the world.

> MinGW under Linux is mostly installed via a package manager ("yum install 
> mingw32-gcc-c++" on Fedora e.g.). You don't get to choose which version of 
> the compiler you install. Same thing for the dependencies (libtool, expat, 
> perl, python...). These versions are likely to change regarding the distro 
> your are using, and you cannot copy their files from one computer to another 
> because binaries are compiled dynamically (= depend on this particular box' 
> libc a.s.o). 

There are hybrid approaches here - the most realistic to me is to reuse
a current distribution cross toolchain (e.g. we're not building
mingw-gcc in GNOME), but if we need to update some other dependency, we
could do so.

I guess you're right though, the full "SDK" case does kind of explode
due to the perl/python dependencies.

> A solution would be to have a standalone MinGW install for Linux. I've 
> googled for one without success. If one doesn't exist, the ultimate solution 
> whould be to create one by recompiling MinGW statically myself, that means 
> recompiling the compiler : I don't know anything about that, it will take 
> lots of time. 

That doesn't help us though even if it existed due to the Perl/Python
deps among others.

>  - GTK+3 build process sometimes needs to run the binaries it has just 
> generated.

Now an important part - gobject-introspection as used by the bindings at
the moment requires doing this.  But see:
https://bugzilla.gnome.org/show_bug.cgi?id=592311

> For instance, it runs "glib-compile-schemas" on its XML files to create the 
> "schemas.compiled" catalog. Without it, GTK+ programs won't run. 

The way this is solved for the e.g. GNU/Linux cross case is it's assumed
you have glib-genmarshal on the host.  See:
https://git.gnome.org/browse/glib/tree/configure.ac#n2630

We can definitely do some of this for Windows, but we have to be careful
about files that are architecture dependent.  For glib-compile-schemas
in particular, variants are host endianness by default.

>  - You won't be able to test and Q/A the binaries you just produced.

That's where virtualization comes in.

> Wine cannot be used because it's not reliable with GTK+3 ; last time I tried 
> under Debian, fonts were disproportional and pictures sometimes stripped. 
> You have to run them on a native Windows OS. 

Wine admittedly is an insane monstrosity, but some of that is likely
fixable.


So at a high level...there's quite a bit to figure out.  The SDK problem
is just hard =/