Re: GTK+3 win32/64 build environment

[tarnyko tarnyko net]

Colin, 

> > 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. 

It runs in a VM. You have to allocate 2 Gb of RAM to it during install time, 
but can decrease that later.
It can get security updates automatically, or manually via pre-downloaded 
packages, too.
But you won't be able to use some software on it (MSVC e.g.). So if it's 
wanted, yes a mainstream version of Windows would be better in this case.e, 

> > 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. 

Yes, Python and Perl are the worst problems. Doing this right on the long 
run with a cross-compile env would require some effort. 

> > 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. 

Correct, didn't even realize that. 

> >  - 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 

Ouch. Will see your link. 

> > 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.

Didn't know about that, thanks, will take a look. 

> >  - 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 =/ 

Yes, that's why the native build option is easier, works around this problem 
and lots of others too. 

PS : Don't forget that I'm alone doing this work now. I'm documenting 
everything as time goes on, but choosing difficult options will make my work 
more difficult too ;-). 

Regards,
Tarnyko