[Boost-build] NuGet packages for boost

Subject: [Boost-build] NuGet packages for boost
From: Ben Craig (ben.craig_at_[hidden])
Date: 2013-09-17 14:07:56

NuGet is a package manager that has traditionally been focused on .NET, 
but it has recently added support for C++ libraries.  Here is a 
presentation by the lead developer adding C++ support to NuGet:
http://channel9.msdn.com/Events/GoingNative/2013/Find-Build-Share-Use-Using-NuGet-for-C-and-Cpp-Libraries

I would like to see boost packages added to NuGet, and to have these 
packages be "official" packages.  I am a contributor on another project 
(Thrift) and I would like to be able to produce NuGet packages for Thrift, 
and I would like that package to have a "magically" working Boost 
dependency.

Sergey Shandar has made some unofficial packages.
Blog describing his effort: 
http://sergey-shandar.blogspot.com/2013/08/boost-on-nugetorg.html
Nuget packages he has submitted:
https://www.nuget.org/profiles/sergey.shandar/

So some questions:

1. If someone (perhaps me) authored the boost NuGet package build process, 
would the person in charge of releasing Boost be willing to publish the 
NuGet packages that get created?

2. Which build variants / pivots would we support for "normal" libraries?
This has been discussed some here: 
http://boost.2283326.n4.nabble.com/Pre-build-MSVC-Boost-binaries-td4650161.html
My inclination is to pivot on the following axes for most libraries:
release, debug
Win32, x64, Arm
static, dynamic
static-crt, dynamic-crt
vc10, vc11_xp, vc12 (xp?)  (I don't think earlier IDEs don't support 
NuGet)
The main pivot this is omitting is single threaded vs. multi threaded.  I, 
personally, don't think that single threaded CRTs make much sense these 
days.

3. Which build variants / pivots would we support for "unusual" libraries?
I would call the python, locale, and regex libraries "unusual" in that 
they have dependencies on non-boost libraries.  We need to figure out 
which versions of the external libraries to use.  If these external 
libraries have dependencies at runtime, then we will need to make sure 
that they have NuGet packages as well.

4. How should we package this in NuGet?  One mega "boost" library, or lots 
of little "boost-thread" style libraries?
My preference is to do lots of little libraries.  This is more work. 
Ideally, we would also mention the dependencies between boost libraries in 
the NuGet package, but I don't currently see any place where these 
dependencies are documented.

The CoApp tools that make NuGet packaging "easy" are supposed to get an 
update soon that will allow for redirector packages (my term).  These 
packages don't contain binaries, but they can have conditional 
dependencies on the particular configuration that you do use.  If we used 
that capability, then users would only download the particular 
configurations they care about, and not 5 GB worth of binaries.