RE: GTK+3 win32/64 build environment

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.

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


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 :

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

Now an important part - gobject-introspection as used by the bindings at
the moment requires doing this.  But see:

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:

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

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

gtk-devel-list mailing list
gtk-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]