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.