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.com<mailto: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.com<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.com<mailto: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 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<mailto: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<mailto: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