Re: GTK+3 win32/64 build environment

[tarnyko tarnyko net]

Kevin, 

Fox, Kevin M writes: 

> I dug up the license for Microsoft Hyper-V Server. Here it is:
> http://www.microsoft.com/en-us/download/details.aspx?id=497 
>
> See USE RIGHTS. section 'e' bullet 2. Does compiling gtk mesh with bullet 2? If so, your good to go. If not, you do not have a license to do what you are attempting. Looking at it, unless you are running at least one vm under it, and you are building the software for the purposes of managing and servicing the virtual machine (One might be able to make that argument), I'd guess not. IANAL 

You are making a point here. I didn't read this section carefully. IANAL 
neither, but if there is a doubt, we should not use the software. Sorry for 
having suggested that btw, shoud have been more precautionous. 

Regards,
Tarnyko 

> Thanks,
> Kevin 
>
> ________________________________________
> From: gtk-devel-list [gtk-devel-list-bounces gnome org] On Behalf Of tarnyko tarnyko net [tarnyko tarnyko net]
> Sent: Wednesday, April 10, 2013 3:50 AM
> To: gtk-devel-list gnome org
> Subject: Re: GTK+3 win32/64 build environment 
>
> 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. 
>
> 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/ 
>
> and a screenshot of it running "gtk3-demo" while buildenv is compiling GLib
> : 
>
> http://www.tarnyko.net/repo/hyperv_gtk3.png 
>
>  ---------------- 
>
> Short version : cross-compiling GTK+3 is a headaches generator. It's not
> easy nor efficient, and hard to maintain. 
>
> Long version with individual points for techs : 
>
>  - MinGW/GCC for Windows is a standalone compiling environment : basically,
> you just drop all files in a directory, and it will work, regardless of the
> OS version you are using. That's because most of the base utils and
> libraries are compiled statically. 
>
> 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). 
>
> That means you depend on a precise distro version.
> Plus, my tests have proven that it matters while building. There are some
> fixes for libtool and the compiler itself in the buildenv (see the 64-bit
> one) ; if you use a different version, it will sometimes break the build. 
>
> 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. 
>
>  - GTK+3 build process sometimes needs to run the binaries it has just
> generated.
> For instance, it runs "glib-compile-schemas" on its XML files to create the
> "schemas.compiled" catalog. Without it, GTK+ programs won't run. 
>
> You cannot obviously run Win binaries under Linux -and using wine is not an
> option here. The only way is to generate, at the same time, the Linux
> version of the same binary ; that is to say, generate the stack *twice*. One
> time you obtain "glib-compile-schemas" for Linux, put it safe somewhere,
> then later during the Windows build you tell it to use
> *this* particular binary at this particular point. Ugly patches. Or you let
> the end-user do this, which is not user-friendly. 
>
>  - You won't be able to test and Q/A the binaries you just produced.
> 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. 
>
> I think I have covered the most important points ; opinions and arguments
> are welcome. I'm sometimes available on IRC channel for discussions, too. 
>
> Regards,
> Tarnyko
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list