RE: GTK+3 win32/64 build environment

["Fox, Kevin M" <kevin fox pnnl gov>]

What the software does not technically disallow and what the software license allows are two different things.

IANAL, but the license appears to only allow it to run on a physical machine, not a virtual one.

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 5:10 AM
To: gtk-devel-list gnome org
Subject: Re: GTK+3 win32/64 build environment

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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list