I am a Windows developer who aleady used boost, and UI think I might share my experience. From my point of view, I do not understand the discussion about the default build type. For serious windows developers, there is no default. John Maddock wrote:
It's probably more accurate to say that it's an MSVC'ism: folks using msvc really don't like distributing dll's with their applications. The complaints to the main Boost mailing list to "please make static linking the default" were really quite persistent until I changed.
From my point of view, I do not understand the discussion about the default build type. For serious windows developers, there is no default. Whenever you create a new project in visual studio, you are asked the questino about using static or dynamic linked runtime. Whatever you select, you need to think about it, and both have serious consequences to your application and the way you distribute it: Static linking means you can just distribute one executable, and you are done. This is nice for small projects, and for tools and utilites you distribute. But it usually makes your application much bigger than it needs to be. But: As soon as your application is split into more than one module (multible EXE files or DLL), you want and need the code reuse. And then you are forced (not really, but you'd better do it) to switch to dynamic runtime. Otherwise you need to be very careful with object/memorys ownership, usage of C++ objects and so on. So whenever I get a third party library to use in my apps, I do not ask how it is built. I just expect at least the mentioned four variants: Debug/Relase vs Dynamic/static linkage. When I rebuild without special options (like --static or --debug) I expect all four variants to be built. And if that is too much, I would expect that I have to chose explicitly which one to build. There is another variant that needs to be considered: statically link to a boost library which then links dynamically to the C/C++ runtime. That way you could hide boost within your application/dll, while still be able to use your compiler*s DLL runtime which might already be on the custome's pc anyway. BTW, all these variants, if built, should be automatically selected with auto-link, of course.
BTW, while it is technically possible to use the one of the release runtimes in a debug build with msvc, almost no one does that - the IDE makes it rather tricky to do, and in my experience it often causes hard to track down issues - not least because it confounds the expectations of any other non-Boost libraries that autolink.
Under windows, the difference between debug and release builds is essential and important. You simply can not run a debug application with a release boost library linking to a debug CRT. The program would most likely fail with very strange errors. Think for instance of iterator debuggin support in the MS std::C++ runtime.
IMO the minimum for msvc is the 4 variants that match the 4 runtimes shipped with vc8.
Well, or 6 variants, as I said above. In our applicatinos, boost is still considered more of a utility part of the application than a runtime library, so it should be possible to do a stati link to boost while linking the dll runtime. At least bost build system should be able to build these libs if required. Norbert