Re: GTK+3 win32/64 build environment
Hi, Could someone review the build environment (https://git.gnome.org/browse/gtk3-build-system), so we can see what needs corrections/improvements ? (and possibly, if everything is OK, discuss a planning for a release ? ^^) Regards, Tarnyko tarn...@tarnyko.net writes: Hi folks, The Linux cross-compile buildenv for GTK+3 is available for download : http://www.tarnyko.net/repo/gtk3_build_system/ GTK+3.4.2_build_system-crosslinux-v1.tar.bz2 It currently only works on CentOS 6.0 x86/amd64, but it's easy to extend to other distros -see tree scripts in z_Install. There's no Win64 target yet (have to work on that ), Win32 only for the moment. As for the way the buildenv works, you better read the scripts, but to summarize : it first builds most of the stack statically for Linux, then rebuilds dynamically for Windows using some of the tools compiled before. - I've put the three buildenvs (win32, win64, cross-linux) on Git : https://git.gnome.org/browse/gtk3-build-system/tree/ If someone wants to contribute, here is some TODO : - merge the 3 buildenvs in 1 (should not be hard) ; - enhance the scripts so they use less hard-coded names ; - enhance the scripts so they perform better tests, and give more info to the user regarding what's going on. So we are now able to : - Compile natively 32-bit GTK+3 from 32-bit Windows ; - Compile natively 64-bit GTK+3 from 64-bit Windows ; - Cross-compile 32-bit GTK+3 from 32-bit/64-bit Linux (CentOS 6) ; 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
Re: GTK+3 win32/64 build environment
Hi folks, The Linux cross-compile buildenv for GTK+3 is available for download : http://www.tarnyko.net/repo/gtk3_build_system/ GTK+3.4.2_build_system-crosslinux-v1.tar.bz2 It currently only works on CentOS 6.0 x86/amd64, but it's easy to extend to other distros -see tree scripts in z_Install. There's no Win64 target yet (have to work on that ), Win32 only for the moment. As for the way the buildenv works, you better read the scripts, but to summarize : it first builds most of the stack statically for Linux, then rebuilds dynamically for Windows using some of the tools compiled before. - I've put the three buildenvs (win32, win64, cross-linux) on Git : https://git.gnome.org/browse/gtk3-build-system/tree/ If someone wants to contribute, here is some TODO : - merge the 3 buildenvs in 1 (should not be hard) ; - enhance the scripts so they use less hard-coded names ; - enhance the scripts so they perform better tests, and give more info to the user regarding what's going on. So we are now able to : - Compile natively 32-bit GTK+3 from 32-bit Windows ; - Compile natively 64-bit GTK+3 from 64-bit Windows ; - Cross-compile 32-bit GTK+3 from 32-bit/64-bit Linux (CentOS 6) ; Regards, Tarnyko ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 16 Apr 2013, at 00:24, Michael Torrie wrote: Is it desirable to continue to compile against msvcrt.dll instead of a more recent, VS-compatible version? Is the issue simply one of licensing for the dll itself (IE distributing it to Linux environments to compile against is not permitted)? Of course this problem of incompatible msvcrt dlls goes well beyond GTK. All windows projects have to deal with this issue. A distribution of Python might be compiled with VS 2008, and the developer writing C api python modules might be using VS 2009. Maybe there's not a good solution in general. You've touched on a thorny subject here, Michael. With care (and a lot of luck) you can distribute programs whose modules link to different 'C' runtimes, different heap managers, different file system managers etc - but generally speaking, it's asking for trouble. It inevitably leads to programs that you can't debug effectively. And secondly, it's a great way to guarantee that your customers will report all kinds of problems which you can't seem to reproduce. So if you're building your app with VS2008 you should link against GTK's supplied VS2008 modules (or if you've got the time and confidence, build the GTK+ stack yourself, using the supplied VS2008 projects). But therein lies the problem... the VS projects aren't maintained any more AFAIK. :-( For our product (Mixbus) I build the entire GTK+ stack (and all supporting libraries) from my own VS projects which I'm slowly starting to upload to GitHub. I only opened a GitHub account a few days ago so don't expect too much too soon. It'll be weeks or even months before I can get everything uploaded. It's been clear to me for a long time that there's no one size fits all solution for building on Windows. The aim should be to get to a stage where Windows devs can have a choice of different build methodologies.At the very least, GTK+ should support building with MinGW (natively), building with MinGW (by cross compiling from Linux) and building from VS projects. But if others could eventually be added (waf / CMake etc) I'm sure there'd be developers who'd appreciate it. I'm just not sure if there are sufficient people with the time to do it. And on the subject of time... let's not forget that there's a much bigger problem where GTK/Windows is concerned - a now enormous backlog of patches which nobody ever seems to have the time to apply or test. I can't see the point in creating sophisticated build methodologies if the end product is still riddled with bugs that were theoretically fixed years ago. Having a choice of build methodologies will encourage more devs to build GTK+ themselves - and that's a good thing because it helps them to eliminate multiple heap managers etc, which is always a boost to reliability. But along the way, somebody at the GTK end needs to be applying those patches and finally making a dent in that bug list. That's a big part of the equation that's been missing since Tor left.. Just my 2 cents... John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
於 2013/4/16 下午 03:53, John Emmas 提到: snip So if you're building your app with VS2008 you should link against GTK's supplied VS2008 modules (or if you've got the time and confidence, build the GTK+ stack yourself, using the supplied VS2008 projects). Yes, so this is the main reason why building the GTK+ stack is also supported for Visual Studio 2008/2010. But therein lies the problem... the VS projects aren't maintained any more AFAIK. :-( The projects for GLib, ATK, GDK-Pixbuf, Pango and GTK+ are kept up-to-date for Visual Studio 2008 and 2010, at least for the library DLLs, as I happen to be the one that maintains them. The latest stable release tarballs of GLib, Pango, ATK, GDK-Pixbuf and GTK+ (2 and 3) should be building as long as the dependencies outlined in https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack are met. Please let us know via Bugzilla if there is something that's not kept up-to-date for those. The gdbus-codegen and gio-querymodules GLib tools are not yet built via the project files, though, which is something I hope to do soon. And on the subject of time... let's not forget that there's a much bigger problem where GTK/Windows is concerned - a now enormous backlog of patches which nobody ever seems to have the time to apply or test. I can't see the point in creating sophisticated build methodologies if the end product is still riddled with bugs that were theoretically fixed years ago. Having a choice of build methodologies will encourage more devs to build GTK+ themselves - and that's a good thing because it helps them to eliminate multiple heap managers etc, which is always a boost to reliability. But along the way, somebody at the GTK end needs to be applying those patches and finally making a dent in that bug list. That's a big part of the equation that's been missing since Tor left.. I agree with you here. I think it might be a good idea to eventually put together lists of items on GNOME Live! that aren't working for the GTK+ stack on Windows so people can see and try to conquer those issues (some might be even CRT-specific[1]) [1]: for example, https://bugzilla.gnome.org/show_bug.cgi?id=693646 With blessings. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Sun, Apr 14, 2013 at 03:37:41AM +0200, tarn...@tarnyko.net wrote: I will upload all scripts to Git as soon as I get my account approved. What steps did you take? I did not get any voucher request for 'bugzilla.gnome.org'. -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 16 Apr 2013, at 10:38, Fan Chun-wei wrote: The latest stable release tarballs of GLib, Pango, ATK, GDK-Pixbuf and GTK+ (2 and 3) should be building as long as the dependencies outlined in https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack are met. Please let us know via Bugzilla if there is something that's not kept up-to-date for those. The gdbus-codegen and gio-querymodules GLib tools are not yet built via the project files, though, which is something I hope to do soon. Hi Fan, I've already completed gdbus-codegen so I can probably give you some tips. Firstly, the python scripts won't build under Windows. Anywhere you see this:- from . import whatever you'll need to abbreviate it to:- import whatever I could never figure out why the original statements wouldn't work. I've got other Python scripts with exactly the same type of statements but they seem to build okay. I spent days trying to figure out what was wrong but eventually I gave up. There was also one specific script (I think it was called parser.py) which I needed to move into it's own module (subfolder). I created a subfolder called parse. So instead of this:- from . import parser The relevant source(s) ended up like this: from parse import parser Of course, it'd be great if you can figure out why the build problems exist in the first place but if you can't, the above modifications do work. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Olav, Olav Vitters writes: On Sun, Apr 14, 2013 at 03:37:41AM +0200, tarn...@tarnyko.net wrote: I will upload all scripts to Git as soon as I get my account approved. What steps did you take? I did not get any voucher request for 'bugzilla.gnome.org'. Sorry I saw your message a bit late ; Martyn already approved my account on his side, we've been discussing that before. -- Regards, Olav ___ 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
Re: GTK+3 win32/64 build environment
On 04/13/2013 07:37 PM, tarn...@tarnyko.net wrote: As a majority of you told me it was so easy and effective to cross-compile from Linux, rather than doing it navitely on Windows, I finally felt like trying it. Well, after some hacking... you were right ^^. I extracted my GTK+3 buildenv on my favorite Linux distro, installed some packages, adapted some scripts, hacked around 2-3 specific problems, and it ran just fine. Now I've got a complete GTK+3 Win32 bundle, generated from Linux. So now we have two fast-identical buildenvs, one for Windows and one for Linux. Just a drawback : like I previously said, cross-compiling GTK+3 from Linux requires to build the stack twice. It's no big deal, just that the Linux buildenv has more specific scripts -I'm currently rewriting them. I will upload all scripts to Git as soon as I get my account approved. Thanks a lot for your advices. Thanks for doing all this hard work. We'll all benefit from in. Question for you and for other windows GTK developers. Is it desirable to continue to compile against msvcrt.dll instead of a more recent, VS-compatible version? Is the issue simply one of licensing for the dll itself (IE distributing it to Linux environments to compile against is not permitted)? Of course this problem of incompatible msvcrt dlls goes well beyond GTK. All windows projects have to deal with this issue. A distribution of Python might be compiled with VS 2008, and the developer writing C api python modules might be using VS 2009. Maybe there's not a good solution in general. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: GTK+3 win32/64 build environment
Another thing to consider. The closer to the developer the building can happen, the more likely it will be that developers writing new features will not break the build for the other os. This can be accomplished by using a CI system like Jenkins. But even closer is right on the developers machine. If most GTK development happens on Linux, then being able to test there would be best. I ran into this on a project of my own recently. Just about every time we tweaked the code on Linux, it would break windows. And visa versa. I got so tired of it, I changed it so that, when built on fedora, it both builds and cross compiles by default now, and has saved a lot of time since I discover the build breakages while I'm coding the particular feature, not days afterwards. Thanks, Kevin From: gtk-devel-list [gtk-devel-list-boun...@gnome.org] On Behalf Of tarn...@tarnyko.net [tarn...@tarnyko.net] Sent: Thursday, April 11, 2013 6:12 AM To: gtk-devel-list@gnome.org Subject: Re: GTK+3 win32/64 build environment Thanks folks. Now, regarding what was said previoulsy in this thread, I will try to list pros and cons of, respectively, native build and cross-compilation. Points listed in the end of each list have less importance or accuracy than the first ones. Then a decision regarding the choice might be made. Native build + easier (works around most problems in configure scripts and Makefiles) + independant from OS/distro - harder integration with GNOME infrastructure - slower - might need a commercial license of Windows Cross-compilation - + better integration with GNOME infrastructure + faster - needs patches in most configure scripts - needs to use standalone versions of Perl/Python OR patch Makefiles to be compatible with most common versions of Perl/Python (possible ? needs study) - needs to build stack twice (Linux native versions of some tools needed). So the speed gain might be countered (needs study) - might not be independant from OS/distro (need to choose a particular distro/package manager and stick to it ?) Regardless of what will be decided, I think that I need a Git account to push the current build scripts to the GNOME infrastructure. Will apply for it now. 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
Re: GTK+3 win32/64 build environment
Hi, I hope I am not too late in the discussion, Marc-André pointed me to it yesterday :) i was not in the mailing list before so I don't know how to jump in the discussion. I am the author and current maintainer of cerbero, and like he described it previously in this thread we are currently using it to build and package GStreamer and its dependencies (more than 100) for Linux, Windows, OS X, Android and IOS. You can check the results in http://docs.gstreamer.com/display/GstSDK/Home I believe cerbero could be very helpful for building and packaging Gtk+ on Windows and OS X. It's a build system that is platform and architecture aware using recipes that are Python classes, which make it's very useful for building software for different platforms and architecture and work around all the build issues that are specific to a given platform or architecture. I will try to highlight its different features to help you in making your decision. Bootstrap === Bootstrapping is handled internally by cerbero, taking care of installing the toolchain and building or installing all the build dependencies (m4, libtool, autoconf, automake, gettext, yasm, cmake, etc...). On Linux it requires a base system with python and git, on OS X is requires additionally installing XCode (for the packaging tools) and on Windows it also requires Mingw/msys and WiX (for the packaging) Bootstrapping is as easy as: $ cerbero bootstrap Or for Windows cross-compilation: $ cerbero -c config/cross-win64 bootstrap For Windows we provide pre-compiled native and cross toolchain for w32 and w64 using mingw-w64 (that are also built using cerbero), so it's not tighted to a specific distro for cross-compilation. Build The build process is split in 2 big steps: source handling and build handling. We have backends for SVN, Git and tarballs for the sources and Makefiles, Autotools and CMake for the build. Projects are described using recipes, which are Python classes, so it's really easy customizing the build process for any kind of project, adding new backends or overwriting the steps in the recipe itself sub-classing the step functions. cerbero supports native and cross-compilation for Windows and universal builds in OS X, where each project is built in a separate tree for the different target archs (ppc, i386, x86_64) and merged into universal binaries. Packaging Besides building, cerbero is also able to create native packages such as MSI installer in Windows and .pkg packages in OSX. There are 3 kind of packages available: * Package: base package that creates merge modules in Windows and .pkg in OS X * SdkPackage: collection of Package's creating final installer (MSI installer in Windows and a meta-package .pkg in OS X) * Application: creates an installer for applications (MSI installer in Windows, .app package in OSX) For each package, a runtime and a development package is created to make the distribution easier. Redistribution and bundling in applications == It's also very easy for applications to embed an redistribute the runtime. On Windows each package included in the final installer is made using Merge Modules and the same for OS X using .pkg We have documented the deployment strategies for applications here: http://docs.gstreamer.com/display/GstSDK/Deploying+your+application Integration with IDE's === Unfortunately not every body likes the shell, make, the autotools and pkg-config, so the integration with the native IDE's is very important. The development package of the SDK allows developers using the regular build process in unix systems, including the libtool libraries and the pkgconfig files but it also allows developers to use VS or XCode. For VS cerbero creates import libraries and a set of VS property sheets similar to pkg-config files. So including Gtk+ in a Visual Studio project is as simple as including the gtk+.props file, which will in turn include all the dependency .props files and set the correct build and link flags. For XCode cerbero creates a real OS X frameworks, so using the SDK is as easy as drag and drop the Gtk+.framework into XCode . I probably missed other features but I hope it's a good starting point to convince you! Cheers, Andoni -- Andoni Morales Alastruey LongoMatch:The Digital Coach http://www.longomatch.ylatuya.es ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hi again folks, As a majority of you told me it was so easy and effective to cross-compile from Linux, rather than doing it navitely on Windows, I finally felt like trying it. Well, after some hacking... you were right ^^. I extracted my GTK+3 buildenv on my favorite Linux distro, installed some packages, adapted some scripts, hacked around 2-3 specific problems, and it ran just fine. Now I've got a complete GTK+3 Win32 bundle, generated from Linux. So now we have two fast-identical buildenvs, one for Windows and one for Linux. Just a drawback : like I previously said, cross-compiling GTK+3 from Linux requires to build the stack twice. It's no big deal, just that the Linux buildenv has more specific scripts -I'm currently rewriting them. I will upload all scripts to Git as soon as I get my account approved. Thanks a lot for your advices. Regards, Tarnyko ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
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. 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
RE: GTK+3 win32/64 build environment
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 Thanks, 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 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: GTK+3 win32/64 build environment
No worries. Just trying to keep everyone safe. Thanks, 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 10:03 AM To: gtk-devel-list@gnome.org Subject: Re: GTK+3 win32/64 build environment 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-boun...@gnome.org] On Behalf Of tarn...@tarnyko.net [tarn...@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 ___ gtk
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 11:05:07AM +0200, tarn...@tarnyko.net wrote: Marc-André Lureau writes: It would be better if you could check in your scripts in a repository, so one could more easily study and eventually contribute to your effort. All the binaries should be fetched or build from the source (and verified). It should be easy and safe to reproduce and modify the build, by anyone at anytime. Agreed. What's GNOME preferred repo system, Git ? Should I get a account on git.gnome.org ? Suggest to do so. Follow https://live.gnome.org/NewAccounts. Note that we want your real name. As 'module voucher' select 'bugzilla.gnome.org' and I'll vouch for you. Anyone on git.gnome.org can create repositories. -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 10/04/13 11:50, tarn...@tarnyko.net wrote: 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. If libtool as shipped by $DISTRO is broken, surely the solution to that is to report bugs and get it fixed, preferably upstream, but failing that, in your favourite distribution? Likewise for the (cross-)compiler. A solution would be to have a standalone MinGW install for Linux. There are several MinGW installations, in several distributions; I'm aware of at least Debian, OpenSUSE and Fedora having it. If the GNOME project wants to cross-compile Windows binaries, the minimum requirement is that building on *one* of those distributions works (OBS seems to be a popular choice); people who want broader support than that are welcome to improve their respective distributions' MinGW stacks, but that's some way off the critical path :-) While I'm sure it would be possible to put together a standalone MinGW tree that expects to be installed in /opt/mingw (or whatever), lots of distribution developers have already done the equivalent work for you. Doing a mini-distribution for that seems somewhat redundant. If users of one Linux distro need to do GNOME-for-Windows builds in a chroot, virtual machine or container with a different distro, that doesn't seem like the end of the world: best-practice in Debian/Ubuntu is to do production package builds in a chroot anyway (via pbuilder or sbuild). Also, if something works on (say) OpenSUSE's stack but not Debian's, then that's either a simple matter of the compiler is in a different place (probably meaning that something is insufficiently automatic), or a bug in Debian's stack (quite possibly of the form please upgrade to gcc x.y.z). Neither seems insurmountable. S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, 2013-04-10 at 14:44 +0200, Marc-André Lureau wrote:
Hi
Their build requirements is similar to yours or anyone:
http://docs.gstreamer.com/display/GstSDK/Building+from+source+using
+Cerbero. We are building the same set of packages after all. Building
only gtk+ is really not enough in many cases. It's not going to fly if
each project distribute its own set of binaries.
Reading the code, Cerebo looks pretty nice. The only obviously lame
thing I saw so far is:
gstreamer-clutter.package:
...
sys_deps_devel = {
Distro.DEBIAN: ['libgl1-mesa-dev', 'libdrm-dev',
'libx11-dev', 'libxext-dev', 'libxfixes-dev',
'libxdamage-dev', 'libxcomposite-dev', 'libxi-dev'],
Distro.REDHAT: [
'libXrender-devel', 'libXv-devel',
'mesa-libGL-devel', 'libXcomposite-devel',
'libXi-devel']}
jhbuild's sysdeps implementation is a lot better because it avoids this
tedious duplicative package name hardcoding.
Maintenance of a shared and proven project can be easier than a new
standalone one. Many people who have experience with distro and
windows build contributed to it. Also I think cerbero isn't that
complicated, it looks quite elegant and powerful for what it does.
So, as far as doing native Windows builds, it looks to me like since
Cerebo is actively used in the GStreamer world which is architecturally
close to GTK+/GNOME, it'd make a lot of sense to use it here.
Tarnyko, have you looked at Cerebo at all?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Thu, Apr 11, 2013 at 8:47 AM, Colin Walters walt...@verbum.org wrote: So, as far as doing native Windows builds, it looks to me like since Cerebo is actively used in the GStreamer world which is architecturally close to GTK+/GNOME, it'd make a lot of sense to use it here. Tarnyko, have you looked at Cerebo at all? as was discussed on IRC, i think we need to differentiate clearly between the 3 different workflows that are involved here: (1) people building GTK+ Windows SDK's for official distribution or personal use (2) people use the GTK+ Windows SDK to develop/build applications on Windows (3) people attempting to package Windows applications that use GTK+ Cerebo looks useful for (1). A zip file with good documentation looks good for (2) Various Windows installers plus good documentation looks good for (3) --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Arnel, Arnel A. Borja writes: I don't know that there's a free version of Windows :D. Now, regarding what Kevin digged out with the license, we know that it's not so free :-(. Short version : cross-compiling GTK+3 is a headaches generator. It's not easy nor efficient, and hard to maintain. I agree, it is hard to maintain. Though I still prefer cross-compilation, since it's faster in compiling. I sometimes fell asleep while compiling in MinGW in native Windows. Agreed, it's a lot faster. Just harder ;-). 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. Is it really compiled statically? I don't see any difference when I moved from native MinGW to OBS. Some packages are static, most are not. Or atleast the old GTK+ 2 builds in www.gtk.org have most of libraries compiled dynamically. I was mostly speaking about MinGW core binaries (the compiler, linker, etc). ldd shows that the compilers refers to the current libc on Debian for instance. Could work though, but needs some trial-and-error. 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). Cross-compiled GTK+ and other libraries use msvcrt, so usually the difference in compiler versions is not a problem except for libstdc++. Don't get me into the libstdc++ thing, it will remind me of hard times :-D (I provide gtkmm packages for win32, was a pain to get right). I'm using Ubuntu, and use the builds for 32-bit and 64-bit Windows that are built using OpenSUSE 12.3. I mix my libraries and programs compiled using GCC 4.6.3 with the ones from OBS that use GCC 4.8.0. Seems to work fine (I've been using them for two years now, I think), except that you should make sure that you use the libstdc++ that comes with your compiler (though it is used by g++, not gcc, and there are no GTK+ dependency that use g++, I believe; I only got this problem last week when I started porting Anjuta since its C++ parser uses g++). Correct, C++ isn't used anywhere during the build process. The problem might be python though, the cross-compiled Python that OBS uses are quite old (2.6). I don't use python so I'm not sure how big the impact would be, but you could compile the base GTK+ stack without python. Because it doesn't work with newer Python (2.7 and ). I think GLib needs it ; could be patched around, have to check. That means you depend on a precise distro version. I recently moved from the builds for OpenSUSE 12.1 to 12.3 (and did that before many times before), upgraded my system many times too (since Ubuntu Oneiric I think), and been using it for about 2 years, so I don't think it is a problem. And I still use the packages I compiled myself before along with the newer set of libraries, seems like there are no problems. 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. Ubuntu, Fedora and OpenSUSE have the cross-compilers in their repos. OBS uses MinGW-w64 GCC 4.8 while I use MinGW-w64 GCC 4.6.3 in Ubuntu. I use their builds alongside each other. A year before I even combine MinGW-32 and MinGW-w64 builds, though I thought that might be a bad idea, and Ubuntu has MinGW-w64 cross-compilers anyway. If you want to build MinGW-w64, you could check OBS which have the most recent GCC cross-compilers. - 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
Re: GTK+3 win32/64 build environment
Thanks folks. Now, regarding what was said previoulsy in this thread, I will try to list pros and cons of, respectively, native build and cross-compilation. Points listed in the end of each list have less importance or accuracy than the first ones. Then a decision regarding the choice might be made. Native build + easier (works around most problems in configure scripts and Makefiles) + independant from OS/distro - harder integration with GNOME infrastructure - slower - might need a commercial license of Windows Cross-compilation - + better integration with GNOME infrastructure + faster - needs patches in most configure scripts - needs to use standalone versions of Perl/Python OR patch Makefiles to be compatible with most common versions of Perl/Python (possible ? needs study) - needs to build stack twice (Linux native versions of some tools needed). So the speed gain might be countered (needs study) - might not be independant from OS/distro (need to choose a particular distro/package manager and stick to it ?) Regardless of what will be decided, I think that I need a Git account to push the current build scripts to the GNOME infrastructure. Will apply for it now. Regards, Tarnyko ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
tarn...@tarnyko.net schreef op do 11-04-2013 om 15:12 [+0200]: Native build + easier (works around most problems in configure scripts and Makefiles) I'd have to disagree here. In order to build gtk on a windows host then you basically need to arrange these things yourself first: - Install msys (which contains sh.exe which is needed to run the configure script) - Install the mingw.org or mingw-w64 compiler - Manually build (or download precompiled files for) all gtk+ dependencies (like gettext, libiconv, pixman, cairo, libjpeg, ...) When you use the cross-compiled packages which various distros are providing then all these steps are already arranged for you. For example on Fedora it's sufficient to run 'yum-builddep mingw32-gtk3' and all dependencies which are needed to allow building of gtk3 will be installed automatically (including the compiler). Once all dependencies are installed it's sufficient to run 'mingw32-configure make' from your source tree and there you go. For Fedora we've created an instruction which describes how commonly used cross-compiling tasks can be performed: https://fedoraproject.org/wiki/MinGW/Tutorial Regards, Erik van Pienbroek Fedora MinGW SIG ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hacking on GTK-Win32 is very annoying if you have to cross compile copy every time you make a change. It would be nice if the build system that comes out of this thread would be useful for more than just making the stock GTK packages. Another flaw with cross compiling is I don't believe there's any way to link to a newer msvcrt.dll. The official windows version of python links against msvcr90 and mixing versions leads to a lot of subtle problems. On Thu, Apr 11, 2013 at 8:44 AM, Erik van Pienbroek e...@vanpienbroek.nlwrote: tarn...@tarnyko.net schreef op do 11-04-2013 om 15:12 [+0200]: Native build + easier (works around most problems in configure scripts and Makefiles) I'd have to disagree here. In order to build gtk on a windows host then you basically need to arrange these things yourself first: - Install msys (which contains sh.exe which is needed to run the configure script) - Install the mingw.org or mingw-w64 compiler - Manually build (or download precompiled files for) all gtk+ dependencies (like gettext, libiconv, pixman, cairo, libjpeg, ...) When you use the cross-compiled packages which various distros are providing then all these steps are already arranged for you. For example on Fedora it's sufficient to run 'yum-builddep mingw32-gtk3' and all dependencies which are needed to allow building of gtk3 will be installed automatically (including the compiler). Once all dependencies are installed it's sufficient to run 'mingw32-configure make' from your source tree and there you go. For Fedora we've created an instruction which describes how commonly used cross-compiling tasks can be performed: https://fedoraproject.org/wiki/MinGW/Tutorial Regards, Erik van Pienbroek Fedora MinGW SIG ___ 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
Re: GTK+3 win32/64 build environment
hi; On 11 April 2013 17:32, Daniel Sabo daniels...@gmail.com wrote: Hacking on GTK-Win32 is very annoying if you have to cross compile copy every time you make a change. It would be nice if the build system that comes out of this thread would be useful for more than just making the stock GTK packages. that's the optimal way to kill this thing in the crib. let's start with something that has fairly well specified constraints and targets and deliverables, and let's leave the future unicorns and rainbows to another time. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hello, On Thursday, 11 April, 2013 08:52 PM, tarn...@tarnyko.net wrote: Short version : cross-compiling GTK+3 is a headaches generator. It's not easy nor efficient, and hard to maintain. I agree, it is hard to maintain. Though I still prefer cross-compilation, since it's faster in compiling. I sometimes fell asleep while compiling in MinGW in native Windows. Agreed, it's a lot faster. Just harder ;-). Usually the harder part is only in the GTK+ package, which includes some tools that it also uses during compilation. In the other packages, especially libraries, it-just-works, since Autoconf will do the stuff for you and most packages don't need porting anyway since they use GLib (and the developers of GLib and GTK+ are always working to ensure that cross-compilation and native compilation with Visual Studio works, so you don't need to worry much about it). In my my computer, I only run ./install glib-2.36.0 then I will get GLib after some minutes. For me, native compilation with MinGW is a lot harder than cross-compilation apart from the speed, since your distribution will provide most of the stuff you need (cross-compiler, libtool, autoconf, intltool, ...), they are up-to-date (OBS have the latest cross-compilers - GCC 4.8.0, while MinGW has 4.7.2; distros usually have the latest autotools, intltool, etc.). In MinGW in Windows, we have to look for things ourselves (intltool is in the GNOME FTP site, compilers in MinGW, etc.). Also, MinGW in Windows uses its own (older) versions of make, which sometimes have problems with sh and other stuff - I always get the headache when some packages will compile for infinity, trying to rebuild itself until the world ends :D (or you kill them using the task manager). The hard part in maintaining is usually checking if the packages are in their latest versions. And sometimes some releases of packages have bugs in Windows (for example, I have some problems with pixman-0.28.2, though I don't think the latest version is required anyway) 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. Is it really compiled statically? I don't see any difference when I moved from native MinGW to OBS. Some packages are static, most are not. Or atleast the old GTK+ 2 builds in www.gtk.org have most of libraries compiled dynamically. I was mostly speaking about MinGW core binaries (the compiler, linker, etc). ldd shows that the compilers refers to the current libc on Debian for instance. Could work though, but needs some trial-and-error. You don't need to worry about them anyway, since Ubuntu, Fedora and OpenSUSE will provide them for you (other distros also have them). Let the distros themselves worry about their own tools. The problem might be python though, the cross-compiled Python that OBS uses are quite old (2.6). I don't use python so I'm not sure how big the impact would be, but you could compile the base GTK+ stack without python. Because it doesn't work with newer Python (2.7 and ). I think GLib needs it ; could be patched around, have to check. I could cross-compile GLib with Python 2.6 without any patches. I don't think GLib requires it, though if you are planning to cross-compile gobject-introspection, you will need (though as far as I know, it only requires Python 2.5). That means you depend on a precise distro version. I recently moved from the builds for OpenSUSE 12.1 to 12.3 (and did that before many times before), upgraded my system many times too (since Ubuntu Oneiric I think), and been using it for about 2 years, so I don't think it is a problem. And I still use the packages I compiled myself before along with the newer set of libraries, seems like there are no problems. 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. Ubuntu, Fedora and OpenSUSE have the cross-compilers in their repos. OBS uses MinGW-w64 GCC 4.8 while I use MinGW-w64 GCC 4.6.3 in Ubuntu. I use their builds alongside each other. A year before I even combine MinGW-32 and MinGW-w64 builds, though I thought that might be a bad idea, and Ubuntu has MinGW-w64 cross-compilers anyway. If you want to build MinGW-w64, you could check OBS which have the most recent GCC cross-compilers. - GTK+3 build process
Re: GTK+3 win32/64 build environment
Hi Andy, Hm.. did I miss the further explanation? :) It's coming ^^. Personally, I would prefer to cross-compile the GTK libraries. That's what I do with the win32 builds for my application already. I also don't like the thought of having to depend on proprietary software in order to build GTK, even if it is for the windows build. I understand that fully. Out of curiosity, collecting info on my side : are you cross-compiling GTK+2 or GTK+3 ? And if you cross-compile, I suppose you are using mingw ; do you install it using your distro's package manager (yum install mingw, apt-get install mingw), or is there such a thing as a standalaone mingw env available in a tarball ? Regards, Tarnyko For the Mac OSX build all the developers have to build their own libraries using Xcode because there are no official binaries and no cross compilers. I don't like that situation very much either. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hi tarnyko On Tue, Apr 9, 2013 at 10:33 PM, tarn...@tarnyko.net wrote: Hi folks, As you may know, I'm currently working on a GTK+3 Win32/64 bundle. Sorry, I failed to reply on the threads before.. The build environments are currently based on MinGW, running on Win32 host (Win64 for the 64-bit builds). They are browsable online here : http://www.tarnyko.net/repo/gtk3_build_system/ It would be better if you could check in your scripts in a repository, so one could more easily study and eventually contribute to your effort. All the binaries should be fetched or build from the source (and verified). It should be easy and safe to reproduce and modify the build, by anyone at anytime. .bat scripts are quite poor, even for a build system. Makefile or python, powershell are probably more suited for the task. There are tons of build systems, but for targetting native windows build [1], I would really suggest looking at cerbero ( http://cgit.freedesktop.org/gstreamer-sdk/cerbero/). It is backing the gstreamer-sdk, which has some professional support, which is a real plus. Furthermore, it can do native and cross compilation, not only for Windows, but for Android and MacOS (and already includes gtk+ builds) The installation steps for cerbero can be a bit tedious, although with chocolatey it could be automated. It has been said that in order to be officially supported, Windows binaries should be compiled on a GNOME-owned machine. That is to say, in order to use my build environment, GNOME should own a Windows machine ^^. Is it the case now ? (no trolling intended, serious question). Have you investigated using a cloud windows server, such as EC2 or rackspace to host the windows machine? Imho, the windows SDK and DDK should be avoided. Only the headers should be required to compile, since we can cross-compile with mingw-headers, I would try to stick to that, probably avoiding any extra license fee or legal problems (I exclude the possibility of using VC completely, as very few projects actually can build with it afaik) It it's the case, then we could keep the buildenv as is. Or we could try to adapt it to a GCC cross-compile install under Linux, but I'd like to avoid that for reasons that I will explain further. If it's not the case, I will obviously need to adapt the buildenv to a GCC cross-compile install under Linux ; same thing, I'd like to avoid that, but I need to know. I believe some work is needed to be able to reuse cross-compiled projects under Windows. For example, the .pc file path will need to be adjusted etc. [1] I am very much a cross-build only guy, because Windows is not my work environment, cross-building is ridiculously easy thanks to projects like mingw-fedora, and scriptscompilers tend to be slower and break more on Windows because they are not tested as often. However, I came to the conclusion that there is no reason to have official gtk cross-built binaries. Each build system (MXE, OBS, fedora-mingw etc.) comes with its own set of packages, distribution, build infrastructure, community etc. It's actually better this way, just not that visible. Choose what you see fits best. But for native build, you don't have anything like that. So this is where this effort should aim. Eventually NuGet integration too. The number of people interested is probably larger in total than people doing cross-compilation. -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hi Marc, Wow wow wow, lots of things there :-). Marc-André Lureau writes: It would be better if you could check in your scripts in a repository, so one could more easily study and eventually contribute to your effort. All the binaries should be fetched or build from the source (and verified). It should be easy and safe to reproduce and modify the build, by anyone at anytime. Agreed. What's GNOME preferred repo system, Git ? Should I get a account on git.gnome.org ? .bat scripts are quite poor, even for a build system. Makefile or python, powershell are probably more suited for the task. Actually, while named .bat, most of these scripts are bash scripts (.sh) using ./configure and make. There are tons of build systems, but for targetting native windows build [1], I would really suggest looking at cerbero I prefer keep using vanilla MinGW, either on Windows or under Linux. Using a very particular and complex buildenv, possibly tied to lots of prerequisites, won't help in a long time. Plus it would mean maintenance for GNOME folks, too. Have you investigated using a cloud windows server, such as EC2 or rackspace to host the windows machine? Imho, the windows SDK and DDK should be avoided. As I said before, the machine should be hosted by GNOME (so no cloud IMHO). GNOME doesn't need to buy a Windows license, there is Hyper-V Server which is freeware. However, I came to the conclusion that there is no reason to have official gtk cross-built binaries. Each build system (MXE, OBS, fedora-mingw etc.) comes with its own set of packages, distribution, build infrastructure, community etc. -- That's why I'm advocating for a native build. Using mingw on Linux usally implies depending on a distro-dependent packaging system. I will make the complete point in one of my next mails. Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 10:41, Marc-André Lureau wrote:
I believe some work is needed to be able to reuse cross-compiled
projects under Windows. For example, the .pc file path will need to be
adjusted etc.
I you mean the paths stated inside .pc files, then pkg-config on
windows should be able to automatically deduce the correct value for
${prefix} based on the location where said package is installed [1]
and ignore whatever is stated as ${prefix} inside the .pc file.
No adjustments should be needed.
This was made so by tml way back, when he used to ./configure
and make install each package into a separate prefix, stringing
things together (both for build and runtime usage) as needed
using PATH, PKG_CONFIG_PATH, ACLOCAL_FLAGS and other env vars.
Quite elegant, one can test (build and/or use) different versions
of packages fast, without having to go and build a complete
bundled distribution for each test (unless there's ABI breaks off
course).
Afaik, no other (meta) build system I've seen up until now is capable
of doing that. Didn't know about Cerbero though, added that to my
already long list of things to look into.
I you mean something else, then please ignore me :)
mvg,
Dieter
[1]
http://cgit.freedesktop.org/pkg-config/tree/parse.c?id=7328e6fc9ec4191105cd4433320ea585d8f95d97#n970
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Dieter Verfaillie writes:
I you mean the paths stated inside .pc files, then pkg-config on
windows should be able to automatically deduce the correct value for
${prefix} based on the location where said package is installed [1]
and ignore whatever is stated as ${prefix} inside the .pc file.
No adjustments should be needed.
I can confirm it works. For instance, my buildenv puts binaries in /opt.
If we move them to c:/gtk3 later, and run pkg-config, and even compile
things, it will infer the new path correctly.
This was made so by tml way back, when he used to ./configure
and make install each package into a separate prefix, stringing
things together (both for build and runtime usage) as needed
using PATH, PKG_CONFIG_PATH, ACLOCAL_FLAGS and other env vars.
Quite elegant, one can test (build and/or use) different versions
of packages fast, without having to go and build a complete
bundled distribution for each test (unless there's ABI breaks off
course).
Afaik, no other (meta) build system I've seen up until now is capable
of doing that. Didn't know about Cerbero though, added that to my
already long list of things to look into.
I you mean something else, then please ignore me :)
mvg,
Dieter
[1]
http://cgit.freedesktop.org/pkg-config/tree/parse.c?id=7328e6fc9ec4191105c
d4433320ea585d8f95d97#n970
___
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
Re: GTK+3 win32/64 build environment
On 2013-04-10 10:12, tarn...@tarnyko.net wrote: Out of curiosity, collecting info on my side : are you cross-compiling GTK+2 or GTK+3 ? I don't know if it was clear or not, but I have only cross compiled my application and have been using pre-build GTK libraries. I have built it using both GTK+2 and GTK+3, but I have only released GTK+2 versions. And if you cross-compile, I suppose you are using mingw ; do you install it using your distro's package manager (yum install mingw, apt-get install mingw), or is there such a thing as a standalaone mingw env available in a tarball ? I have installed mingw32 though my distos package manager (pacman on Arch and emerge/crossdev on Gentoo). I don't think I would use a standalone mingw env on Linux. If I didn't want to use my distos package manager I think I would just download the sources and build mingw myself. I think there are only a couple packages that are needed: the cross versions of gcc and binutils, and then the mingw runtime and w32api? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Andy, Andy Spencer writes: I don't know if it was clear or not, but I have only cross compiled my application and have been using pre-build GTK libraries. I have built it using both GTK+2 and GTK+3, but I have only released GTK+2 versions. OK. Cross-building GTK+3 itself actually has some specific problems, will detail them soon. I have installed mingw32 though my distos package manager (pacman on Arch and emerge/crossdev on Gentoo). I don't think I would use a standalone mingw env on Linux. My point : I would like to avoid depending on a particular distro/package mananger. I'm not closed on this matter, though. If I didn't want to use my distos package manager I think I would just download the sources and build mingw myself. I think there are only a couple packages that are needed: the cross versions of gcc and binutils, and then the mingw runtime and w32api? There's expat too, but yes you've listed most of them. Regards, Tarnyko ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
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
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 12:59 AM, Andy Spencer andy753...@gmail.com wrote: For the Mac OSX build all the developers have to build their own libraries using Xcode because there are no official binaries and no cross compilers. I don't like that situation very much either.\ you don't need xcode, other than the command line tools (i.e. gcc) cross-compiling is not the issue - the requirement to have many OS X frameworks/libraries is. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
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
Re: GTK+3 win32/64 build environment
On Wed, 10 Apr 2013, Andy Spencer wrote: If I didn't want to use my distos package manager I think I would just download the sources and build mingw myself. I think there are only a couple packages that are needed: the cross versions of gcc and binutils, and then the mingw runtime and w32api? That's right. And these days you don't need special versions of the gcc and binutils sources; the primary packages work fine so long as you pass the right magic to the configure script. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hello, Interesting. I'm also using cross-compiled GTK+ 3 and other libraries for my applications. I use the libraries/etc from the mingw32/64 project in OpenSUSE Build Service. I'm using GTK+ 3.6.1 though (which OBS currently have), I'm too busy to compile GTK+ 3.8.0 myself. I use it to build and create NSIS installers for a payroll application, GPInstruct, gWaei and Anjuta. On Wednesday, 10 April, 2013 06:50 PM, tarn...@tarnyko.net wrote: 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 I don't know that there's a free version of Windows :D. Short version : cross-compiling GTK+3 is a headaches generator. It's not easy nor efficient, and hard to maintain. I agree, it is hard to maintain. Though I still prefer cross-compilation, since it's faster in compiling. I sometimes fell asleep while compiling in MinGW in native Windows. 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. Is it really compiled statically? I don't see any difference when I moved from native MinGW to OBS. Some packages are static, most are not. Or atleast the old GTK+ 2 builds in www.gtk.org have most of libraries compiled dynamically. 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). Cross-compiled GTK+ and other libraries use msvcrt, so usually the difference in compiler versions is not a problem except for libstdc++. I'm using Ubuntu, and use the builds for 32-bit and 64-bit Windows that are built using OpenSUSE 12.3. I mix my libraries and programs compiled using GCC 4.6.3 with the ones from OBS that use GCC 4.8.0. Seems to work fine (I've been using them for two years now, I think), except that you should make sure that you use the libstdc++ that comes with your compiler (though it is used by g++, not gcc, and there are no GTK+ dependency that use g++, I believe; I only got this problem last week when I started porting Anjuta since its C++ parser uses g++). The problem might be python though, the cross-compiled Python that OBS uses are quite old (2.6). I don't use python so I'm not sure how big the impact would be, but you could compile the base GTK+ stack without python. That means you depend on a precise distro version. I recently moved from the builds for OpenSUSE 12.1 to 12.3 (and did that before many times before), upgraded my system many times too (since Ubuntu Oneiric I think), and been using it for about 2 years, so I don't think it is a problem. And I still use the packages I compiled myself before along with the newer set of libraries, seems like there are no problems. 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. Ubuntu, Fedora and OpenSUSE have the cross-compilers in their repos. OBS uses MinGW-w64 GCC 4.8 while I use MinGW-w64 GCC 4.6.3 in Ubuntu. I use their builds alongside each other. A year before I even combine MinGW-32 and MinGW-w64 builds, though I thought that might be a bad idea, and Ubuntu has MinGW-w64 cross-compilers anyway. If you want to build MinGW-w64, you could check OBS which have the most recent GCC cross-compilers. - 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
Re: GTK+3 win32/64 build environment
Hi On Wed, Apr 10, 2013 at 11:05 AM, tarn...@tarnyko.net wrote: There are tons of build systems, but for targetting native windows build [1], I would really suggest looking at cerbero I prefer keep using vanilla MinGW, either on Windows or under Linux. Using a very particular and complex buildenv, possibly tied to lots of prerequisites, won't help in a long time. Plus it would mean maintenance for GNOME folks, too. Their build requirements is similar to yours or anyone: http://docs.gstreamer.com/display/GstSDK/Building+from+source+using+Cerbero. We are building the same set of packages after all. Building only gtk+ is really not enough in many cases. It's not going to fly if each project distribute its own set of binaries. Maintenance of a shared and proven project can be easier than a new standalone one. Many people who have experience with distro and windows build contributed to it. Also I think cerbero isn't that complicated, it looks quite elegant and powerful for what it does. -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 11:11 AM, Dieter Verfaillie
diet...@optionexplicit.be wrote:
I you mean the paths stated inside .pc files, then pkg-config on
windows should be able to automatically deduce the correct value for
${prefix} based on the location where said package is installed [1]
and ignore whatever is stated as ${prefix} inside the .pc file.
No adjustments should be needed.
This was made so by tml way back, when he used to ./configure
and make install each package into a separate prefix, stringing
things together (both for build and runtime usage) as needed
using PATH, PKG_CONFIG_PATH, ACLOCAL_FLAGS and other env vars.
Quite elegant, one can test (build and/or use) different versions
of packages fast, without having to go and build a complete
bundled distribution for each test (unless there's ABI breaks off
course).
Interesting, I didn't know (and I wouldn't try, I am cross-compiling guy :)
However, this isn't going to be enough, there are many variables in .pc
which may contain path. Also projects not using pkg-config have the same
problems. Doing a grep under fedora-mingw sys-root reveals that there are
many binaries that refer to hardcoded path too. In general, it's not going
to work if I try to reuse those cross-builds for doing native build.
Fortunately, by now, most of the runtime is working natively, but there are
still corner-cases (this is still one of the first thing you need to fix
when porting a lib/app)
--
Marc-André Lureau
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 15:03, Marc-André Lureau wrote:
Interesting, I didn't know (and I wouldn't try, I am cross-compiling
guy :) However, this isn't going to be enough, there are many
variables in .pc which may contain path.
Yeah, projects not re-using the prefix variable when defining other
paths in their .pc files probably need to be fixed. For example
a .pc.in file having:
prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@
which after evaluation by autoconf's config.status produces
the following .pc file:
prefix=/c/some_project/prefix
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
is OK.
Also projects not using
pkg-config have the same problems.
Those should obviously be fixed to use pkg-config, right? ;)
Doing a grep under fedora-mingw
sys-root reveals that there are many binaries that refer to hardcoded
path too.
Also needs to be fixed imho... One issue like this I never got to
resolve was hardcoded paths in perl scripts (for GTK-Doc iirc). Python
makes this easy by providing the __file__ builtin, but how to do
something like that in perl has been evading me...
Oh well, nobody said supporting relocatable installs for software
usually only expecting to be installed in / was going to be
easy :P
In general, it's not going to work if I try to reuse those
cross-builds for doing native build. Fortunately, by now, most of the
runtime is working natively, but there are still corner-cases (this is
still one of the first thing you need to fix when porting a lib/app)
Yeah, it seems there will always be corner-cases, unfortunately...
mvg,
Dieter
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
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-boun...@gnome.org] On Behalf Of tarn...@tarnyko.net [tarn...@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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 15:03, Marc-André Lureau wrote: Also projects not using pkg-config have the same problems. Doing a grep under fedora-mingw sys-root reveals that there are many binaries that refer to hardcoded path too. I have this problem running my software on windows. I have many places in my Makefile.am's where I use something like: myfile_CPPFLAGS = -DPKGDATADIR=\$(pkgdatadir)\ Which results in a non-relocatable build. It seems like most of my issues with relative build could fixed by patching ./configure to support './configure --prefix=..'. Has anyone tried this, or are there better solutions? My current solution is basically to emulate with some autoconf hacks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 1:07 PM, Andy Spencer andy753...@gmail.com wrote: On 2013-04-10 15:03, Marc-André Lureau wrote: Also projects not using pkg-config have the same problems. Doing a grep under fedora-mingw sys-root reveals that there are many binaries that refer to hardcoded path too. I have this problem running my software on windows. I have many places in my Makefile.am's where I use something like: myfile_CPPFLAGS = -DPKGDATADIR=\$(pkgdatadir)\ Which results in a non-relocatable build. It seems like most of my issues with relative build could fixed by patching ./configure to support './configure --prefix=..'. Has anyone tried this, or are there better solutions? My current solution is basically to emulate with some autoconf hacks. applications should not assume that DATADIR or other run-time located resources are found by using compile time values. GTK makes this mistake on Linux and OS X although I have submitted an initial patch to fix it and eventually unify with windows, where this mistake is not made. currently it seems unlikely that this patch will gain enough support to go in, but you never know. to be relocatable, your app should *fall back* on -DPKGDATADIR but should first try checking for an environment variable and then a path relative to the executable. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 7:18 PM, Paul Davis p...@linuxaudiosystems.comwrote: to be relocatable, your app should *fall back* on -DPKGDATADIR but should first try checking for an environment variable and then a path relative to the executable. Or just rely on g_get_system_data_dirs(), that's what I usually do. https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-system-data-dirs -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 10/04/13 19:07, Andy Spencer wrote: I have this problem running my software on windows. I have many places in my Makefile.am's where I use something like: myfile_CPPFLAGS = -DPKGDATADIR=\$(pkgdatadir)\ Which results in a non-relocatable build. It seems like most of my issues with relative build could fixed by patching ./configure to support './configure --prefix=..'. The glib resource framework could be a solution. If the files are all the kind that get loaded each and every time when the app starts (.ui files, for instance), it makes sense to embed them within the binary. Easier to relocate the app and the startup gets faster. https://developer.gnome.org/gio/stable/gio-GResource.html -- Kalev ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 1:39 PM, Marc-André Lureau marcandre.lur...@gmail.com wrote: On Wed, Apr 10, 2013 at 7:18 PM, Paul Davis p...@linuxaudiosystems.comwrote: to be relocatable, your app should *fall back* on -DPKGDATADIR but should first try checking for an environment variable and then a path relative to the executable. Or just rely on g_get_system_data_dirs(), that's what I usually do. https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-system-data-dirs i assume you mean as the fallback? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 8:08 PM, Paul Davis p...@linuxaudiosystems.comwrote: i assume you mean as the fallback? You said, should first try checking for an environment variable and then a path relative to the executable., what environment variable? PKGDATADIR? Who set it? Is it only for the developper? If you have a good case for that extra environment variable, I would suggest to submit a patch to g_get_system_data_dirs(), It does the later, giving you a list of where to look for the data. So it could easily be tweaked to look for more locations. -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 2:19 PM, Marc-André Lureau marcandre.lur...@gmail.com wrote: On Wed, Apr 10, 2013 at 8:08 PM, Paul Davis p...@linuxaudiosystems.comwrote: i assume you mean as the fallback? You said, should first try checking for an environment variable and then a path relative to the executable., what environment variable? PKGDATADIR? Who set it? application or toolkit specific. the search order should be: getenv (MYAPP_DATA_DIR) get_executable_path () + sub-dir standard system dir(s) compile-time value Is it only for the developper? If you have a good case for that extra environment variable, I would suggest to submit a patch to g_get_system_data_dirs(), It does the later, giving you a list of where to look for the data. So it could easily be tweaked to look for more locations. no. g_get_system_data_dirs() does not work for relocatable applications, at least not on *nix-ish systems. -- Marc-André Lureau ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 2:23 PM, Paul Davis p...@linuxaudiosystems.comwrote: On Wed, Apr 10, 2013 at 2:19 PM, Marc-André Lureau marcandre.lur...@gmail.com wrote: On Wed, Apr 10, 2013 at 8:08 PM, Paul Davis p...@linuxaudiosystems.comwrote: i assume you mean as the fallback? You said, should first try checking for an environment variable and then a path relative to the executable., what environment variable? PKGDATADIR? Who set it? application or toolkit specific. the search order should be: getenv (MYAPP_DATA_DIR) get_executable_path () + sub-dir standard system dir(s) compile-time value Is it only for the developper? If you have a good case for that extra environment variable, I would suggest to submit a patch to g_get_system_data_dirs(), It does the later, giving you a list of where to look for the data. So it could easily be tweaked to look for more locations. no. g_get_system_data_dirs() does not work for relocatable applications, at least not on *nix-ish systems. just to reinforce that point, code from g_get_system_data_dirs(): #ifdef G_OS_WIN32 data_dir_vector = (gchar **) g_win32_get_system_data_dirs_for_module (NULL); #else gchar *data_dirs = (gchar *) g_getenv (XDG_DATA_DIRS); if (!data_dirs || !data_dirs[0]) data_dirs = /usr/local/share/:/usr/share/; data_dir_vector = g_strsplit (data_dirs, G_SEARCHPATH_SEPARATOR_S, 0); #endif G_OS_WIN32 is the only case where the location of the executable/module is taken into account. Total fail for OS X and arguably a PITA for linux etc. as well. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 20:19, Marc-André Lureau wrote:
You said, should first try checking for an environment variable and
then a path relative to the executable., what environment variable?
PKGDATADIR? Who set it? Is it only for the developper? If you have a
good case for that extra environment variable, I would suggest to
submit a patch to g_get_system_data_dirs(), It does the later, giving
you a list of where to look for the data. So it could easily be
tweaked to look for more locations.
g_get_system_data_dirs() on win32 should simply honor XDG_DATA_DIRS
like it does on any other platform/OS and fall back to
FOLDERID_ProgramData
or CSIDL_COMMON_APPDATA (depending on windows version).
Something like what I tried to do a year ago [1], before I got
a) much less time to hack on things and b) distracted with g-i
stuff which I'm now desperately trying to finish before working
on anything else.
From what I remember: I stopped working on the branch when embarking
on an attempt to write a KnownFolders.h implementation for MinGW's
win32api package and mingw-w64 equivalent (attached), eventually
to be #included in glib/gutils.c [2]. The being stuck part was properly
testing for the header in configure.ac with AC_CHECK_HEADER, which
I've not yet figured out how to do (include test passes, compile
test fails, so apparently the header alone is not enough and there's
something else missing wrt the INITGUID stuff)...
If anybody feels like making the KnownFolders.h stuff work (and
getting it in mingw mingw-w64) and un-bit-rotting that branch (and
getting it in glib proper), please feel free to do so. Don't think I'll
be able to go back working on that for at least another couple of
months...
mvg,
Dieter
[1]
https://github.com/dieterv/glib/commit/57c184e66bab81470ae3768330088ef113e3d750
[2]
https://github.com/dieterv/glib/commit/0462418592ee1df93f251772d9bdcd3f6ca13f68
/*
* KnownFolders.h
*
* KNOWNFOLDERID constants
*
* This file is part of the w32api package.
*
* Contributors:
* Created by Dieter Verfaillie diet...@optionexplicit.be
*
* Provenance:
* - File structure and include guards based on /mingw/include/ddk/ndisguid.h
* - EXTERN_C preprocessor macro copied from /mingw/include/basetyps.h
* - DEFINE_FOLDERID_GUID preprocessor macro based on DEFINE_GUID
* from /mingw/include/basetyps.h
* - FOLDERID_* names and values as documented on:
* http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457.aspx
* Note that this page lacks information on FOLDERID_Documents, but:
* - FODERID_Documents name and value and other FOLDERID_* names and values
* verified against the remarks section of:
*
http://msdn.microsoft.com/en-us/library/windows/desktop/dd940483(v=vs.85).aspx
*
* THIS SOFTWARE IS NOT COPYRIGHTED
*
* This source code is offered for use in the public domain. You may
* use, modify or distribute it freely.
*
* This code is distributed in the hope that it will be useful but
* WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY
* DISCLAIMED. This includes but is not limited to warranties of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*
*/
#ifndef __KNOWN_FOLDERS_H
#define __KNOWN_FOLDERS_H
#if __GNUC__ =3
#pragma GCC system_header
#endif
#ifndef _OBJC_NO_COM_
# ifdef __cplusplus
# define EXTERN_C extern C
# else
# define EXTERN_C extern
# endif
#endif
#ifdef INITGUID
# define DEFINE_FOLDERID_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) \
EXTERN_C const GUID n = {l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}
#else
# define DEFINE_FOLDERID_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) \
EXTERN_C const GUID n
#endif
#ifdef __cplusplus
extern C {
#endif
DEFINE_FOLDERID_GUID(FOLDERID_AddNewPrograms,
0xde61d971, 0x5ebc, 0x4f02, 0xa3, 0xa9, 0x6c, 0x82, 0x89, 0x5e, 0x5c, 0x04);
DEFINE_FOLDERID_GUID(FOLDERID_AdminTools,
0x724ef170, 0xa42d, 0x4fef, 0x9f, 0x26, 0xb6, 0x0e, 0x84, 0x6f, 0xba, 0x4f);
DEFINE_FOLDERID_GUID(FOLDERID_AppUpdates,
0xa305ce99, 0xf527, 0x492b, 0x8b, 0x1a, 0x7e, 0x76, 0xfa, 0x98, 0xd6, 0xe4);
DEFINE_FOLDERID_GUID(FOLDERID_CDBurning,
0x9e52ab10, 0xf80d, 0x49df, 0xac, 0xb8, 0x43, 0x30, 0xf5, 0x68, 0x78, 0x55);
DEFINE_FOLDERID_GUID(FOLDERID_ChangeRemovePrograms,
0xdf7266ac, 0x9274, 0x4867, 0x8d, 0x55, 0x3b, 0xd6, 0x61, 0xde, 0x87, 0x2d);
DEFINE_FOLDERID_GUID(FOLDERID_CommonAdminTools,
0xd0384e7d, 0xbac3, 0x4797, 0x8f, 0x14, 0xcb, 0xa2, 0x29, 0xb3, 0x92, 0xb5);
DEFINE_FOLDERID_GUID(FOLDERID_CommonOEMLinks,
0xc1bae2d0, 0x10df, 0x4334, 0xbe, 0xdd, 0x7a, 0xa2, 0x0b, 0x22, 0x7a, 0x9d);
DEFINE_FOLDERID_GUID(FOLDERID_CommonPrograms,
0x0139d44e, 0x6afe, 0x49f2, 0x86, 0x90, 0x3d, 0xaf, 0xca, 0xe6, 0xff, 0xb8);
DEFINE_FOLDERID_GUID(FOLDERID_CommonStartMenu,
0xa4115719, 0xd62e, 0x491d, 0xaa, 0x7c, 0xe7, 0x4b, 0x8b, 0xe3, 0xb0, 0x67);
DEFINE_FOLDERID_GUID(FOLDERID_CommonStartup,
0x82a5ea35, 0xd9cd, 0x47c5, 0x96, 0x29, 0xe1, 0x5d, 0x2f, 0x71, 0x4e, 0x6e);
Re: GTK+3 win32/64 build environment
On 2013-04-10 21:04, Dieter Verfaillie wrote: g_get_system_data_dirs() on win32 should simply honor XDG_DATA_DIRS like it does on any other platform/OS and fall back to FOLDERID_ProgramData or CSIDL_COMMON_APPDATA (depending on windows version). Hit send a bit too soon, that should be: honor XDG_DATA_DIRS if set else $glib_runtime_prefix/share + $exe_runtime_prefix + FOLDERID_ProgramData or CSIDL_COMMON_APPDATA (depending on windows version) mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Dieter Verfaillie schreef op wo 10-04-2013 om 21:04 [+0200]: If anybody feels like making the KnownFolders.h stuff work (and getting it in mingw mingw-w64) and un-bit-rotting that branch (and getting it in glib proper), please feel free to do so. Don't think I'll be able to go back working on that for at least another couple of months... The knownfolders.h header was recently added to mingw-w64 already [1]. Unfortunately it causes a build regression in gdkdnd-win32.c for both gtk2 and gtk3. In the Fedora MinGW gtk2 and gtk3 packages we've worked around this for now with [2]. Before this patch can be included in the upstream gtk+ git it needs to be tested on other compilers (msvc, mingw.org and older mingw-w64 releases) first to make sure it doesn't introduce other breakages. Regards, Erik van Pienbroek Fedora MinGW SIG 1: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=revisionrevision=5589 2: http://pkgs.fedoraproject.org/cgit/mingw-gtk3.git/commit/?id=82ccf489f4763e375805d848351ac3f8fda8e88b ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 19:51, Kalev Lember wrote: The glib resource framework could be a solution. If the files are all the kind that get loaded each and every time when the app starts (.ui files, for instance), it makes sense to embed them within the binary. Easier to relocate the app and the startup gets faster. https://developer.gnome.org/gio/stable/gio-GResource.html They're not, for instance, I also use $(pkglibdir) for loading plugins and $(htmldir) for storing documentation that needs to be accessible by the system's default browser. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-09 22:33, tarn...@tarnyko.net wrote: It it's the case, then we could keep the buildenv as is. Or we could try to adapt it to a GCC cross-compile install under Linux, but I'd like to avoid that for reasons that I will explain further. Hm.. did I miss the further explanation? :) Personally, I would prefer to cross-compile the GTK libraries. That's what I do with the win32 builds for my application already. I also don't like the thought of having to depend on proprietary software in order to build GTK, even if it is for the windows build. For the Mac OSX build all the developers have to build their own libraries using Xcode because there are no official binaries and no cross compilers. I don't like that situation very much either. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
