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

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

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