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
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
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: function in glib/gqueue.c relies on undefined behavour?
In order to support varargs ('...', http://en.wikipedia.org/wiki/Stdarg.h) C
compilers put function call arguments backwards on the stack. This allows
functions that don't care about extra arguments to simply not offset back far
enough on the stack to notice them. No modern C compiler excludes support for
varargs and glib relies on varargs anyway. So its not really an issue.
Thanks,
Kevin
From: gtk-devel-list-boun...@gnome.org [gtk-devel-list-boun...@gnome.org] On
Behalf Of Giovanni Gherdovich [g.gherdov...@gmail.com]
Sent: Monday, December 31, 2012 9:02 AM
To: gtk-devel-list@gnome.org
Subject: function in glib/gqueue.c relies on undefined behavour?
Hi all,
I stumbled upon the implementation of the function
g_queue_free_full from glib/gqueue.c and there is
something I don't understand:
it takes a unary function as input, i.e.
something of type
void (*) (void *)
and forward it (to the function g_queue_foreach)
as a binary function, by casting it to the type
void (*) (void *, void *)
For the records, the second argument
(which is meant to be discarded, I guess)
gets the value NULL.
At first sight, I would have imagined that
this is not valid C code, but lives in the gray land
of indefined behaviours;
you can't give two arguments to a function that requires only one!
But it compiles, and work as expected (the second arg
is actually ignored).
Am I missing something?
Here a code snippet the resume the situation;
it is taken from glib/gqueue.c and glib/gtypes.h.
It doesn't compile, it's just to put all definitions
in the same place to better explain what I mean.
8--
typedef void* gpointer;
typedef void (*GFunc) (gpointer data,
gpointer user_data);
typedef void (*GDestroyNotify) (gpointer data);
void
g_queue_free_full (GQueue *queue,
GDestroyNotify free_func)
{
g_queue_foreach (queue, (GFunc) free_func, NULL);
g_queue_free (queue);
}
void
g_queue_foreach (GQueue *queue,
GFunc func,
gpointer user_data)
{
GList *list;
g_return_if_fail (queue != NULL);
g_return_if_fail (func != NULL);
list = queue-head;
while (list)
{
GList *next = list-next;
func (list-data, user_data);
list = next;
}
}
8--
Again for the record, the function g_queue_free_full
was added with this commit
http://git.gnome.org/browse/glib/commit/?id=1d4009e6f7e1d368b3e3df2fa41b007277b600d8
between tags 2.31.4 and 2.31.6; as the patch description states,
it is a convenience method and fixes the bug
https://bugzilla.gnome.org/show_bug.cgi?id=657433
Best regards
Giovanni Gherdovich
___
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: Working on 119189 this weekend
Hi C.J, Correct me if I'm wrong, but I thought something like this was already done. GtkGLext http://www.k-3d.org/gtkglext/Main_Page Kevin -Original Message- From: gtk-devel-list-boun...@gnome.org [mailto:gtk-devel-list-boun...@gnome.org] On Behalf Of C.J. Adams-Collier Sent: Thursday, February 05, 2009 4:04 PM To: gtk-devel-list@gnome.org Subject: Working on 119189 this weekend Hey all, I'm planning some time to work on 119189 this weekend. I'm going to see if I can put together a patch to add gtkgl.c and friends into gtk. http://bugzilla.gnome.org/show_bug.cgi?id=119189 Behdad has suggested (and correct me if I've got this wrong, Behdad) that he feels that instead of creating a dedicated OpenGL drawing widget (similar to GtkDrawingArea), it would be better to add a method to the API which allows a widget to be imbued with the ability to have OpenGL primitives drawn to it. What are your thoughts? Cheers, C.J. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
