Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x

[GarrettSerack <garretts microsoft com>]

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
garretts 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.