Re: [boost] NuGet packages for boost

Subject: Re: [boost] NuGet packages for boost
From: Ben Craig (ben.craig_at_[hidden])
Date: 2013-09-17 17:10:40

> It seems to me that if you could convert bootstrap.bat to MSBuild, 
> then packaging up Boost as NuGet ought to be fairly straightforward.
> 
> Niall

It depends on how you want to present things to users.  I think that you 
are suggesting having consuming NuGet clients rebuild boost on their 
machine.  That might work, but that seems like it would require porting a 
lot of the existing bjam code.

A really straightforward approach was prototyped by Sergey Shandar.  You 
build 32-bit Boost and 64-bit Boost, adjust the consuming packages lib 
path and include path, and you're done.  That package is more than 200 MB 
though, and it didn't include a lot of the build variants that clients 
might expect.

So here are some general build questions that would need to be answered:

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

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

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