Re: [boost] [Boost-build] [1.35] what gets built and installed?

From: Norbert Unterberg (nunterberg_at_[hidden])
Date: 2007-12-21 16:21:10

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