If someone of course wants to set all that up and pay for it, I have no objection. Prebuilt binaries are easy on the end user. Garrett Serack has offered up hosted server VMs with Visual Studio
Responding almost bottom up... preinstalled. So for now, I'm going to pretend that the compilers and licenses won't be an issue.
My issue with supplying prebuilt binaries via NuGet is that there are a lot of combinations, and a lot of variants because of MSVCRT and STL incompatibilities - for example, VS Express doesn't support some technologies such as OpenMP, so OpenMP using Boost libraries may have an issue. I see this as a major challenge as well. However, right now clients have to figure it out on their own. It's even worse for libraries that want to use Boost, but require Boost to be built "correctly". If some library needs Boost built with OpenMP support, I want that library to be able to express that dependency cleanly.
It seems to me that if you could convert bootstrap.bat to MSBuild, then packaging up Boost as NuGet ought to be fairly straightforward.
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.
Not really. If you can get NuGet to spit out a b2.exe, the rest of the build is very easy. I'm going to rephrase this to check my own understanding. I think that you are suggesting that the bootstrap / b2 build process should get ported to msbuild. Then, when a user installs the Boost NuGet package, b2 will get built, and then the Boost libraries themselves will get built, all using the current compiler.
I think that could work. I don't think NuGet makes it easy. I think it also will cause long install times. But it has the significant benefit of sidestepping download size issues, and pre-building all the configuration options. I think this could also be packaged up in a way that clients that want boost-thread for the static CRT could just build the libraries they need, and no others. So this idea has significant merits, but my current preference is still to have built binaries.