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