Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
On 13/06/2013 00:06, Garrett Serack wrote: Awesome! I'll pop into your #hexchat-devel IRC channel tomorrow if you want to chat about it, or need some help getting started with our tools (we're still a bit behind on docs) Hi Garrett and Arnav, I'm the lead Windows developer for Harrison's Mixbus DAW:- http://www.harrisonconsoles.com/mixbus/website/ I'm based in the UK so I'm typically about 6 hours ahead of the rest of my team who are mostly US based. If I get a chance I'll join you on hexchat-devel but the earliest I could manage it would be around mid-day (CST). Not a problem if you're already done by then but it'd be great to meet up. Mixbus is also built using MSVC although we're still running VS2005. There's no particular policy about sticking with that. It's just been very reliable and hasn't caused us any problems. Anyway, hopefully see you both later. John Emmas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Hi Garrett, I maintain a GCC/MinGW build environment for GTK+ these days ; but I'm interested as well, so I might join the channel if nobody minds. Regards, Tarnyko Garrett Serack writes: Awesome! I’ll pop into your #hexchat-devel IRC channel tomorrow if you want to chat about it, or need some help getting started with our tools (we’re still a bit behind on docs) Hmm. Now that I think about it, I added a bunch of cmdlets that I never even mentioned in the docs at all (things for generating template build/packaging scripts) G From: Arnavion [mailto:arnav...@gmail.com] Sent: Wednesday, June 12, 2013 2:12 PM To: Garrett Serack Cc: gtk-devel-list Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x Awesome! I'll look into integrating this into our build script somehow. -Arnav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Sure, the more the merrier! In the longer term, I *really* want to make sure we can support GCC as well. G -Original Message- From: tarn...@tarnyko.net [mailto:tarn...@tarnyko.net] Sent: Thursday, June 13, 2013 1:45 AM To: Garrett Serack Cc: Arnavion; gtk-devel-list Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x Hi Garrett, I maintain a GCC/MinGW build environment for GTK+ these days ; but I'm interested as well, so I might join the channel if nobody minds. Regards, Tarnyko Garrett Serack writes: Awesome! I’ll pop into your #hexchat-devel IRC channel tomorrow if you want to chat about it, or need some help getting started with our tools (we’re still a bit behind on docs) Hmm. Now that I think about it, I added a bunch of cmdlets that I never even mentioned in the docs at all (things for generating template build/packaging scripts) G From: Arnavion [mailto:arnav...@gmail.com] Sent: Wednesday, June 12, 2013 2:12 PM To: Garrett Serack Cc: gtk-devel-list Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x Awesome! I'll look into integrating this into our build script somehow. -Arnav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Howdy Folks, (apologies for resurrecting this older thread, but it felt the most appropriate way to continue this conversation...) (and, apologies for the long-ish email, it's a big topic :D ) My name is Garrett Serack - I work as a Senior Developer in at Microsoft in the Open Source Technology Center -- my role here is to help get open source software running better on Windows--my management specifically cares about things on Windows *Server* (ie, PHP, Apache, MySQL, Node.js etc) , but so very many things are needed for some of those that it's really not much of a distinction. Aaaanyway. In addition to the (W)AMP stack I have an extremely strong interest to see quality builds of the whole GTK+ stack (and as many apps as will run) make their way onto Windows. This spring, we added support for Native C/C++ packages to NuGet (a library package manager that up till now was .NET only) -- this makes it pretty darn easy to produce, share and consume C/C++ libraries in VC10, VC11 (and beyond). The packaging of the libraries is extremely flexible in that it can handle all the different variations of a given library across any number of 'pivots' -- Compiler (VC6,7,8,9,10,11,etc) , Linkage (static, dynamic, ltcg, sxs), Configuration (Release, Debug), C Runtime Library Linkage (static,dynamic), Platform (x86, x64, arm) ... and pretty much any other varation that you want to provide variations on. The support for VC is handled by generating a msbuild .targets file that gets imported into the consuming project which intelligently sets up all the settings needed to actually compile and link against the package. Working with some members of our community, we also started making builds available of common open-source libraries -- and then we started to hit GTK+ and friends, and as I dug deeper into the process of building all of them, it became clear that the better approach would be to work with everybody who is trying to build the libraries and try to make one consistent approach to building and packaging the libraries up on Windows. We've been working to make better basic project (.vcxproj) templates than the less-than-stellar ones that ship with Visual Studio. We've distiled down the necessary stuff to make it far simpler to make project files for building all of these libraries, and remove all the cruft and confusing stuff that's come from a decade and a half of Visual Studio development. I've also done a ton of work to improve automating over a given set of projects to produce all the different variations of a given build, for multiple compilers, so that when we package up a given library, we give as many variations as possible. My goal here is to make these libraries easy to build and consume for as many varations (compilers, platforms, etc) as possible. I know that this can be done with a single set of VCXProj files (which wne properly iterated over, can generate all combinations of the libraries for all the VC compilers). I'd like to work along with anyone who's interested. Garrett Serack garre...@microsoft.com twitter: @fearthecowboy Things I've been considering - Generate some files for CMake as well and include them in the library, which would make it possible to consume libraries in CMake-based builds. This wouldn't be too difficult, since in the generator I've already got all the information I need to produce the files, it's just likely to be at least a couple weeks worth of work. I should actually ping Bill Hoffman on that... - At some point in the future, I'd also like to add toolset support for GCC so that MSBuild could compile with it as well (I think adding in the right stuff to the project at http://daffodil.codeplex.com/ would be the best for that) - Currently, the tools for building the packages rely heavily on the MSBuild infrastructure, so it's not currently possible to run them on non-Windows platforms, but it may be possible to move towards using Mono's xbuild (or, just treat the vcxproj .targets files as xml and just 'do what we know we need to' instead of using the flimsy wrappers in msbuild's object model.) More Information === Announcement: http://coapp.org/news/2013-04-26-Announcing-CoApp-Tools-For-NuGet.html Packging Native Libraries Tutorial: http://coapp.org/tutorials/building-a-package.html https://www.youtube.com/watch?v=l4MAkR13JPA Channel 9 interview: http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-16-Garrett-Serak-Inside-NuGet-for-C -- View this message in context: http://gtk.10911.n7.nabble.com/Windows-32-64bit-downloads-and-or-bundles-for-2-x-and-3-x-tp80686p81291.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Hi Garrett, You mentioned that you have done work to provide builds of common open-source libraries. Can you provide more information on this? - Do you mean that these builds are done using MSVC? - Does this include any libraries that GTK depends on? I am curious to see if any of the work we do on http://gtk.hexchat.org can be reduced (or merged into yours). Thanks, Arnav On Wed, Jun 12, 2013 at 10:19 AM, GarrettSerack garre...@microsoft.comwrote: Howdy Folks, (apologies for resurrecting this older thread, but it felt the most appropriate way to continue this conversation...) (and, apologies for the long-ish email, it's a big topic :D ) My name is Garrett Serack - I work as a Senior Developer in at Microsoft in the Open Source Technology Center -- my role here is to help get open source software running better on Windows--my management specifically cares about things on Windows *Server* (ie, PHP, Apache, MySQL, Node.js etc) , but so very many things are needed for some of those that it's really not much of a distinction. Aaaanyway. In addition to the (W)AMP stack I have an extremely strong interest to see quality builds of the whole GTK+ stack (and as many apps as will run) make their way onto Windows. This spring, we added support for Native C/C++ packages to NuGet (a library package manager that up till now was .NET only) -- this makes it pretty darn easy to produce, share and consume C/C++ libraries in VC10, VC11 (and beyond). The packaging of the libraries is extremely flexible in that it can handle all the different variations of a given library across any number of 'pivots' -- Compiler (VC6,7,8,9,10,11,etc) , Linkage (static, dynamic, ltcg, sxs), Configuration (Release, Debug), C Runtime Library Linkage (static,dynamic), Platform (x86, x64, arm) ... and pretty much any other varation that you want to provide variations on. The support for VC is handled by generating a msbuild .targets file that gets imported into the consuming project which intelligently sets up all the settings needed to actually compile and link against the package. Working with some members of our community, we also started making builds available of common open-source libraries -- and then we started to hit GTK+ and friends, and as I dug deeper into the process of building all of them, it became clear that the better approach would be to work with everybody who is trying to build the libraries and try to make one consistent approach to building and packaging the libraries up on Windows. We've been working to make better basic project (.vcxproj) templates than the less-than-stellar ones that ship with Visual Studio. We've distiled down the necessary stuff to make it far simpler to make project files for building all of these libraries, and remove all the cruft and confusing stuff that's come from a decade and a half of Visual Studio development. I've also done a ton of work to improve automating over a given set of projects to produce all the different variations of a given build, for multiple compilers, so that when we package up a given library, we give as many variations as possible. My goal here is to make these libraries easy to build and consume for as many varations (compilers, platforms, etc) as possible. I know that this can be done with a single set of VCXProj files (which wne properly iterated over, can generate all combinations of the libraries for all the VC compilers). I'd like to work along with anyone who's interested. Garrett Serack garre...@microsoft.com twitter: @fearthecowboy Things I've been considering - Generate some files for CMake as well and include them in the library, which would make it possible to consume libraries in CMake-based builds. This wouldn't be too difficult, since in the generator I've already got all the information I need to produce the files, it's just likely to be at least a couple weeks worth of work. I should actually ping Bill Hoffman on that... - At some point in the future, I'd also like to add toolset support for GCC so that MSBuild could compile with it as well (I think adding in the right stuff to the project at http://daffodil.codeplex.com/ would be the best for that) - Currently, the tools for building the packages rely heavily on the MSBuild infrastructure, so it's not currently possible to run them on non-Windows platforms, but it may be possible to move towards using Mono's xbuild (or, just treat the vcxproj .targets files as xml and just 'do what we know we need to' instead of using the flimsy wrappers in msbuild's object model.) More Information === Announcement: http://coapp.org/news/2013-04-26-Announcing-CoApp-Tools-For-NuGet.html Packging Native Libraries Tutorial: http://coapp.org/tutorials/building-a-package.html https://www.youtube.com/watch?v=l4MAkR13JPA Channel 9 interview:
RE: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Yes, we’ve done some of the libraries in that stack already: (*really* nice job on that page script by the way, it’s the clearest instructions for that stuff that I’ve ever seen :D ) Off that page, we already have win-iconv zlib libffi freetype libxml2 libpng glib pixman openssl And yes, we’ve done these using MSVC ( vc10, vc11 * release, debug * static, dynamic *x86, x64 ) The VC12 preview release is coming at the //build conference this month, and we’ll add that into our matrix when that comes out. (it may be late july-ish, I think we’re going to make a change to split up the .lib/.dll files into smaller, fine grained satellite packages) I was looking at your scripts to see if we could merge efforts there too. (one of the things that lead me here was looking at your page) You can see most of the ‘native’ nuget packages we’ve built in the gallery : https://nuget.org/profiles/coapp/ (well, a few of those are .NET pkgs, but look for the ones marked ‘native’ ) Right now, we shallow fork projects here (https://github.com/coapp-packages/ ), and add our build files (usually found right now in the /COPKG/ folder in the project) The script file that iterates over the variations is the .buildinfo (example: https://github.com/coapp-packages/freeglut/blob/master/COPKG/.buildinfo ) And you can see one of our simplified .vcxproj files (https://github.com/coapp-packages/freeglut/blob/master/COPKG/freeglut.vcxproj ) -- this still loads in VC10 and VC11 too. Nice part about these builds, is that they’re all pretty atomic – dependencies are brought in using the packages and so anyone can generally rebuild an individual package. Garrett From: Arnavion [mailto:arnav...@gmail.com] Sent: Wednesday, June 12, 2013 12:03 PM To: Garrett Serack Cc: gtk-devel-list Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x Hi Garrett, You mentioned that you have done work to provide builds of common open-source libraries. Can you provide more information on this? - Do you mean that these builds are done using MSVC? - Does this include any libraries that GTK depends on? I am curious to see if any of the work we do on http://gtk.hexchat.org can be reduced (or merged into yours). Thanks, Arnav On Wed, Jun 12, 2013 at 10:19 AM, GarrettSerack garre...@microsoft.commailto:garre...@microsoft.com wrote: Howdy Folks, (apologies for resurrecting this older thread, but it felt the most appropriate way to continue this conversation...) (and, apologies for the long-ish email, it's a big topic :D ) My name is Garrett Serack - I work as a Senior Developer in at Microsoft in the Open Source Technology Center -- my role here is to help get open source software running better on Windows--my management specifically cares about things on Windows *Server* (ie, PHP, Apache, MySQL, Node.js etc) , but so very many things are needed for some of those that it's really not much of a distinction. Aaaanyway. In addition to the (W)AMP stack I have an extremely strong interest to see quality builds of the whole GTK+ stack (and as many apps as will run) make their way onto Windows. This spring, we added support for Native C/C++ packages to NuGet (a library package manager that up till now was .NET only) -- this makes it pretty darn easy to produce, share and consume C/C++ libraries in VC10, VC11 (and beyond). The packaging of the libraries is extremely flexible in that it can handle all the different variations of a given library across any number of 'pivots' -- Compiler (VC6,7,8,9,10,11,etc) , Linkage (static, dynamic, ltcg, sxs), Configuration (Release, Debug), C Runtime Library Linkage (static,dynamic), Platform (x86, x64, arm) ... and pretty much any other varation that you want to provide variations on. The support for VC is handled by generating a msbuild .targets file that gets imported into the consuming project which intelligently sets up all the settings needed to actually compile and link against the package. Working with some members of our community, we also started making builds available of common open-source libraries -- and then we started to hit GTK+ and friends, and as I dug deeper into the process of building all of them, it became clear that the better approach would be to work with everybody who is trying to build the libraries and try to make one consistent approach to building and packaging the libraries up on Windows. We've been working to make better basic project (.vcxproj) templates than the less-than-stellar ones that ship with Visual Studio. We've distiled down the necessary stuff to make it far simpler to make project files for building all of these libraries, and remove all the cruft and confusing stuff that's come from a decade and a half of Visual Studio development. I've also done a ton of work to improve automating over a given set of projects to produce all the different variations of a given build, for multiple compilers, so
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Awesome! I'll look into integrating this into our build script somehow. -Arnav On Wed, Jun 12, 2013 at 1:15 PM, Garrett Serack garre...@microsoft.comwrote: Yes, we’ve done some of the libraries in that stack already: ** ** (*really* nice job on that page script by the way, it’s the clearest instructions for that stuff that I’ve ever seen :D ) ** ** Off that page, we already have win-iconv zlib libffi freetype libxml2 libpng glib pixman openssl And yes, we’ve done these using MSVC ( vc10, vc11 * release, debug * static, dynamic *x86, x64 ) ** ** The VC12 preview release is coming at the //build conference this month, and we’ll add that into our matrix when that comes out. (it may be late july-ish, I think we’re going to make a change to split up the .lib/.dll files into smaller, fine grained satellite packages) ** ** I was looking at your scripts to see if we could merge efforts there too. (one of the things that lead me here was looking at your page) ** ** You can see most of the ‘native’ nuget packages we’ve built in the gallery : https://nuget.org/profiles/coapp/ (well, a few of those are .NET pkgs, but look for the ones marked ‘native’ ) ** ** Right now, we shallow fork projects here ( https://github.com/coapp-packages/ ), and add our build files (usually found right now in the /COPKG/ folder in the project) The script file that iterates over the variations is the .buildinfo (example: https://github.com/coapp-packages/freeglut/blob/master/COPKG/.buildinfo )* *** ** ** And you can see one of our simplified .vcxproj files ( https://github.com/coapp-packages/freeglut/blob/master/COPKG/freeglut.vcxproj) -- this still loads in VC10 and VC11 too. ** ** Nice part about these builds, is that they’re all pretty atomic – dependencies are brought in using the packages and so anyone can generally rebuild an individual package. ** ** Garrett ** ** *From:* Arnavion [mailto:arnav...@gmail.com] *Sent:* Wednesday, June 12, 2013 12:03 PM *To:* Garrett Serack *Cc:* gtk-devel-list *Subject:* Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x** ** ** ** Hi Garrett, You mentioned that you have done work to provide builds of common open-source libraries. Can you provide more information on this? - Do you mean that these builds are done using MSVC? - Does this include any libraries that GTK depends on? I am curious to see if any of the work we do on http://gtk.hexchat.orgcan be reduced (or merged into yours). Thanks, Arnav ** ** On Wed, Jun 12, 2013 at 10:19 AM, GarrettSerack garre...@microsoft.com wrote: Howdy Folks, (apologies for resurrecting this older thread, but it felt the most appropriate way to continue this conversation...) (and, apologies for the long-ish email, it's a big topic :D ) My name is Garrett Serack - I work as a Senior Developer in at Microsoft in the Open Source Technology Center -- my role here is to help get open source software running better on Windows--my management specifically cares about things on Windows *Server* (ie, PHP, Apache, MySQL, Node.js etc) , but so very many things are needed for some of those that it's really not much of a distinction. Aaaanyway. In addition to the (W)AMP stack I have an extremely strong interest to see quality builds of the whole GTK+ stack (and as many apps as will run) make their way onto Windows. This spring, we added support for Native C/C++ packages to NuGet (a library package manager that up till now was .NET only) -- this makes it pretty darn easy to produce, share and consume C/C++ libraries in VC10, VC11 (and beyond). The packaging of the libraries is extremely flexible in that it can handle all the different variations of a given library across any number of 'pivots' -- Compiler (VC6,7,8,9,10,11,etc) , Linkage (static, dynamic, ltcg, sxs), Configuration (Release, Debug), C Runtime Library Linkage (static,dynamic), Platform (x86, x64, arm) ... and pretty much any other varation that you want to provide variations on. The support for VC is handled by generating a msbuild .targets file that gets imported into the consuming project which intelligently sets up all the settings needed to actually compile and link against the package. Working with some members of our community, we also started making builds available of common open-source libraries -- and then we started to hit GTK+ and friends, and as I dug deeper into the process of building all of them, it became clear that the better approach would be to work with everybody who is trying to build the libraries and try to make one consistent approach to building and packaging the libraries up on Windows. We've been working to make better basic project (.vcxproj) templates than the less-than
RE: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Awesome! I’ll pop into your #hexchat-devel IRC channel tomorrow if you want to chat about it, or need some help getting started with our tools (we’re still a bit behind on docs) Hmm. Now that I think about it, I added a bunch of cmdlets that I never even mentioned in the docs at all (things for generating template build/packaging scripts) G From: Arnavion [mailto:arnav...@gmail.com] Sent: Wednesday, June 12, 2013 2:12 PM To: Garrett Serack Cc: gtk-devel-list Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x Awesome! I'll look into integrating this into our build script somehow. -Arnav On Wed, Jun 12, 2013 at 1:15 PM, Garrett Serack garre...@microsoft.commailto:garre...@microsoft.com wrote: Yes, we’ve done some of the libraries in that stack already: (*really* nice job on that page script by the way, it’s the clearest instructions for that stuff that I’ve ever seen :D ) Off that page, we already have win-iconv zlib libffi freetype libxml2 libpng glib pixman openssl And yes, we’ve done these using MSVC ( vc10, vc11 * release, debug * static, dynamic *x86, x64 ) The VC12 preview release is coming at the //build conference this month, and we’ll add that into our matrix when that comes out. (it may be late july-ish, I think we’re going to make a change to split up the .lib/.dll files into smaller, fine grained satellite packages) I was looking at your scripts to see if we could merge efforts there too. (one of the things that lead me here was looking at your page) You can see most of the ‘native’ nuget packages we’ve built in the gallery : https://nuget.org/profiles/coapp/ (well, a few of those are .NET pkgs, but look for the ones marked ‘native’ ) Right now, we shallow fork projects here (https://github.com/coapp-packages/ ), and add our build files (usually found right now in the /COPKG/ folder in the project) The script file that iterates over the variations is the .buildinfo (example: https://github.com/coapp-packages/freeglut/blob/master/COPKG/.buildinfo ) And you can see one of our simplified .vcxproj files (https://github.com/coapp-packages/freeglut/blob/master/COPKG/freeglut.vcxproj ) -- this still loads in VC10 and VC11 too. Nice part about these builds, is that they’re all pretty atomic – dependencies are brought in using the packages and so anyone can generally rebuild an individual package. Garrett From: Arnavion [mailto:arnav...@gmail.commailto:arnav...@gmail.com] Sent: Wednesday, June 12, 2013 12:03 PM To: Garrett Serack Cc: gtk-devel-list Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x Hi Garrett, You mentioned that you have done work to provide builds of common open-source libraries. Can you provide more information on this? - Do you mean that these builds are done using MSVC? - Does this include any libraries that GTK depends on? I am curious to see if any of the work we do on http://gtk.hexchat.org can be reduced (or merged into yours). Thanks, Arnav On Wed, Jun 12, 2013 at 10:19 AM, GarrettSerack garre...@microsoft.commailto:garre...@microsoft.com wrote: Howdy Folks, (apologies for resurrecting this older thread, but it felt the most appropriate way to continue this conversation...) (and, apologies for the long-ish email, it's a big topic :D ) My name is Garrett Serack - I work as a Senior Developer in at Microsoft in the Open Source Technology Center -- my role here is to help get open source software running better on Windows--my management specifically cares about things on Windows *Server* (ie, PHP, Apache, MySQL, Node.js etc) , but so very many things are needed for some of those that it's really not much of a distinction. Aaaanyway. In addition to the (W)AMP stack I have an extremely strong interest to see quality builds of the whole GTK+ stack (and as many apps as will run) make their way onto Windows. This spring, we added support for Native C/C++ packages to NuGet (a library package manager that up till now was .NET only) -- this makes it pretty darn easy to produce, share and consume C/C++ libraries in VC10, VC11 (and beyond). The packaging of the libraries is extremely flexible in that it can handle all the different variations of a given library across any number of 'pivots' -- Compiler (VC6,7,8,9,10,11,etc) , Linkage (static, dynamic, ltcg, sxs), Configuration (Release, Debug), C Runtime Library Linkage (static,dynamic), Platform (x86, x64, arm) ... and pretty much any other varation that you want to provide variations on. The support for VC is handled by generating a msbuild .targets file that gets imported into the consuming project which intelligently sets up all the settings needed to actually compile and link against the package. Working with some members of our community, we also started making builds available of common open-source libraries -- and then we started to hit GTK+ and friends, and as I dug deeper into the process of building
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Hi Martyn, I remember having browsed Berke's website some months ago. There's no relation between us, but it's definitely well-maintained and polished (I'm especially fond of the dependency graph ^^). Our build systems seem to be quite different. As Arnavion pointed out, this one uses VC++ whereas I use MinGW. I prefer MinGW for the following reasons : - MinGW can be used from Linux (cross-compilation). In fact, I just made it work, see my former mail on the list ; - patches are easier to push upstream (MinGW = GCC, which is kind of the reference compiler). Plus, please note that generated binaries may be incompatible (libgtk-3-0.dll generated by MSVC won't play nice with libglib-2.0.dll generated by MinGW e.g.). However, a VC++ build has the advantage of being of better use to people who prefer, or are required, to work with this particular compiler. And it allows them to use newer versions of msvcrt.dll, too. Maybe the 2 build systems can coexist in harmony. Some examples come to mind, like ClamAV for Windows (http://oss.netfarm.it/clamav/), whose author provides binaries generated by the 2 systems, ultimately letting users choose which one they prefer. It may be a good option if we both reach a good level a maturity. I think it's ultimately up to you and the GTK+ devs... Please find some notes on your questions and suggestions below : Martyn Russell writes: On 12/04/13 02:30, Arnavion wrote: Hello, Hello Arnavion, I am a fellow Hexchat dev with bviktor, and I thought I'd just provide a few clarifications:- 1. The instructions to build GTK+ on gtk.hexchat.org http://gtk.hexchat.org are for building using Visual Studio 2012, as opposed to Tarnkyo's work that uses MinGW. We use VS to build our entire stack (GTK and its deps, openssl, and Hexchat itself). 2. We have indeed found several problems getting these to build with VS. To that end, we have a bunch of patches scoured from the GTK bug tracker and other places, as well as a few we've written ourselves. These patches can be seen on https://github.com/hexchat/gtk-win32 3. Our goal was to make it easy for the user to build the stack using our instructions, for which we also provide a build script on the same repository. (hexchat-build.ps1) Thank you for those. I would like to add that I know there are differences, but what I want to bring to the windows offering for users/developers is some unity and consistency so people not only have a choice between all flavours (32bit, 64bit, MSVC, MinGW, sources, binaries, bundles, etc). I would like to see: - Patches upstreamed in all cases where possible (like the ones you mention Arnavion). I'm currently doing this for GTK+ itself and some external deps : https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00110.html - Downloads available from gtk.org, not external sites to give end users a consistency and feeling these binaries are authentic and affiliated (this is most important IMO). I often wondered when I downloaded Tor's binaries back in the day why they weren't on gtk.org and was wary of that. - People taking maintainer-ship of providing bundles, msvc builds, etc and helping with updates to the gtk.org website in respect to that. I'm OK to claim maintainership for my build system, giving mail addresses and URLs to contact me in case of question/problem. I just registered on Git BTW, you have mail on bugzilla ^^ (https://bugzilla.gnome.org/show_bug.cgi?id=695600). - A well documented FAQ to help people with their disciplines on Windows (e.g. for MSVC or MinGW, for 32bit OR 64bit, etc). The current documentation is ... well ... old and chaotic IMO. I would like some easy steps people can follow to understand *which* Windows download they need depending on what they're doing (e.g. bundles for just everything with MinGW, or the hexchat stuff for MSVC sources only, etc). It should be as easy as installing GTK+ on a Linux distribution, this is something you can do in a few steps. As it currently stands, it's easier to build on a Linux distribution than to use on Windows. Perhaps this is too utopian? But we should make it easy for people to use GTK+ on Windows. Looking at how you install or use Qt (for example), they have a similar problem. There are a bunch of steps to get started. I think GTK+ would look attractive if it was well supported and documented on Windows right from the download link. By that I mean, in 2 or 3 steps, from downloading, you're done setting it up. Same here, news on Bugzilla ^^ (https://bugzilla.gnome.org/show_bug.cgi?id=695600). In the end, I realise there are different requirements here, some people want just binaries to link against, others want to build the entire stack. But I think we should consider each of these use cases and have a clear wizard/path on the website to make it easy for people to get started with GTK+ on Windows with their compiler and architecture of choice.
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Hello Martyn, I would like to add that I know there are differences, but what I want to bring to the windows offering for users/developers is some unity and consistency so people not only have a choice between all flavours (32bit, 64bit, MSVC, MinGW, sources, binaries, bundles, etc). I would like to see: - Patches upstreamed in all cases where possible (like the ones you mention Arnavion). These patches usually do make it upstream. A quick glance through the bugs from which we got some of our patches shows many of them resolved and fixed. ( https://bugzilla.gnome.org/show_bug.cgi?id=665507 is one that hasn't). I've personally partially resolved an issue I had reported with a patch (gtk/gtk-statusicon.patch in the github repository, for https://bugzilla.gnome.org/show_bug.cgi?id=696505 , and I will attach it to the bug soon). The reason we keep the patches around even after they've been merged into upstream is that upstream often merges them into a version later than the one we use. We can't bump versions as often as we'd like because of the inter-dependencies between components. Upgrading any portion of the stack even by a minor revision always involves some time spent to see which new things are broken (and they always are), some time spent to find new patches (hopefully!) for the new things that are broken, a lot of time spent fixing the stock VS solutions, etc. We do try to upgrade as often as possible and this has allowed us to remove many patches, but relying solely on latest upstream doesn't work for us and for our Windows users. - Downloads available from gtk.org, not external sites to give end users a consistency and feeling these binaries are authentic and affiliated (this is most important IMO). I often wondered when I downloaded Tor's binaries back in the day why they weren't on gtk.org and was wary of that. - People taking maintainer-ship of providing bundles, msvc builds, etc and helping with updates to the gtk.org website in respect to that. Of course. I believe bviktor suggested linking to gtk.hexchat.org because we update it quite frequently and thus would want changes to be immediate. If a similar guarantee could be made for hosting on gtk.org, then we would be happy to use that and maintain it. - A well documented FAQ to help people with their disciplines on Windows (e.g. for MSVC or MinGW, for 32bit OR 64bit, etc). The current documentation is ... well ... old and chaotic IMO. I would like some easy steps people can follow to understand *which* Windows download they need depending on what they're doing (e.g. bundles for just everything with MinGW, or the hexchat stuff for MSVC sources only, etc). It should be as easy as installing GTK+ on a Linux distribution, this is something you can do in a few steps. As it currently stands, it's easier to build on a Linux distribution than to use on Windows. I agree. Especially regarding the ease of use, building with MSVC is quite difficult work compared to doing the same on Linux. For example, look at https://github.com/hexchat/gtk-win32/blob/master/cairo/mod.md to see how we have to mofify the stock cairo VS solution to be usable. When I started work on the build system, the first thing I did was to codify the long build instructions ( http://web.archive.org/web/20130329205336/http://gtk.hexchat.org/#zlibhttp://web.archive.org/web/20130329205336/http://gtk.hexchat.org/ ) into a build script, precisely so that it would be easy to build. Perhaps this is too utopian? But we should make it easy for people to use GTK+ on Windows. Looking at how you install or use Qt (for example), they have a similar problem. There are a bunch of steps to get started. I think GTK+ would look attractive if it was well supported and documented on Windows right from the download link. By that I mean, in 2 or 3 steps, from downloading, you're done setting it up. Indeed it would. For our build, this is the state we are at right now. The user just has to check out the git repository of patches and solutions, download the few build environment dependencies (MozillaBuild and others), and run the build script. In the end, I realise there are different requirements here, some people want just binaries to link against, others want to build the entire stack. But I think we should consider each of these use cases and have a clear wizard/path on the website to make it easy for people to get started with GTK+ on Windows with their compiler and architecture of choice. Are there different requirements? I'm not sure what the scope of tarnyko's work is, but the Hexchat site provides both sources + build instructions as well as precompiled binaries. Of course our binaries are incompatible with binaries obtained from elsewhere, since they were all built with MSVC and thus all link to the v110 CRT instead of the old CRT used by MinGW. Thank you for your time, Arnav ___ gtk-devel-list
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Hello, I am a fellow Hexchat dev with bviktor, and I thought I'd just provide a few clarifications:- 1. The instructions to build GTK+ on gtk.hexchat.org are for building using Visual Studio 2012, as opposed to Tarnkyo's work that uses MinGW. We use VS to build our entire stack (GTK and its deps, openssl, and Hexchat itself). 2. We have indeed found several problems getting these to build with VS. To that end, we have a bunch of patches scoured from the GTK bug tracker and other places, as well as a few we've written ourselves. These patches can be seen on https://github.com/hexchat/gtk-win32 3. Our goal was to make it easy for the user to build the stack using our instructions, for which we also provide a build script on the same repository. (hexchat-build.ps1) Thanks, Arnav On Thu, Apr 11, 2013 at 10:17 AM, Martyn Russell mar...@lanedo.com wrote: Hello all, I was approached by Berke Viktor today and asked to include the site: http://gtk.hexchat.org On the GTK+ Win32/Win64 pages on gtk.org. I thought I would bring it up here for discussion. This is for v2.x only at this point. I've CCed Berke because he is not on the mailing list and sadly isn't interested in joining, so don't forget to reply-all ;) Berke insists he is interested in continuing maintenance of this site though. -- Just to be clear, I have no problem adding this to gtk.org, but my goal here is not to confuse end user/developers who want a win32/win64 build with multiple different hosted downloads. It doesn't look like _we_ the community are doing it if we do that and it's not a clear consistent well formed message either IMO. I am also aware of the bundles work that Tarnyko has been doing and am interested to know how that relates here. At this stage the fact that work is for GTK+ 3.x is the only main difference I can see from my quick look. In an ideal world, the goal would be to merge ALL works from Tarnyko, Berke and what we already have on the site into something that's well documented and clear to people wanting to use GTK+ 2.x and 3.x on Windows 32 and 64 bit. I am especially interested in hearing from Tarnyko on this since he has been pushing the win32 bundles for GTK+ 3.x lately. Including in this bug, which I'm in the process of working on with him: https://bugzilla.gnome.org/**show_bug.cgi?id=695600https://bugzilla.gnome.org/show_bug.cgi?id=695600 Thoughts? -- Regards, Martyn Founder and CEO of Lanedo GmbH. __**_ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/gtk-devel-**listhttps://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
