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-boun...@gnome.org] On Behalf Of tarn...@tarnyko.net [tarn...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
