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

From: Edward Diener (eldiener_at_[hidden])
Date: 2007-12-20 17:44:00

John Maddock wrote:
> Rene Rivera wrote:
>> A tangent... I can't change the default to vary depending on the
>> compiler used. I can only change it depending on the platform one
>> *runs*
>> on. Which may be inappropriate in a cross-compile context.
>>
>> Could you provide some rationale for why those specific variants?
>> Maybe
>> I'm just confused as to why release and debug, and not just debug if
>> you
>> are trying to satisfy the "default" IDE. (note, I'm not an "IDE"
>> person,
>> at least as IDE's are currently defined by the industry)
> 
> snipped...
> 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.

Even the above which you cite is prone to problems.

Recently I was using the release build of ImageMagick DLLs for VC, which 
I built from source,  against a debug version of a program I created 
using the same version of VC, and ImageMagick crashed when I had to pass 
to ImageMagick some dynamically allocated data. When I looked at 
Dependency Walker naturally I saw two versions of the VC RTLs and I 
suspect the crash had to do with the fact that the release and debug 
versions of the RTL do not understand each other's dynamically allocated 
memory ( the debug version may be sticking in data which allows closer 
checking of valid dynamically allocated areas ).

Once I synched up my versions so that the debug version of my 
application was using the debug version of the same ImageMagick DLLs, 
there were no problems.

So to back you up further, and whether it is the case with most other 
compilers I do not necessarily know, but using VC libraries has to be 
absolutely in synch with each other or else problems will occur and the 
end-user is asking for trouble.

I actually believe that the default build for Boost Build for the 
end-user, upon downloading Boost and following the basic Boost Build 
instructions, should be to automatically build all variants of a library 
for a particular compiler, and only if the end-user wants to limit the 
variants to build should he have clear documentation which tells him how 
to build some subset or single variant of a particular Boost library for 
a particular compiler.

Needless to say the instructions for the latter should be clear and easy 
to understand and find. If the end-user does not want all variants, then 
he should read the documentation and find out how to limit himself.

It is MUCH safer to build all variants by default, even if the build 
takes significantly longer, than to hear endless questions from 
end-users to Boost programmers, who have much better things to do than 
fielding them, about why their library is not linking with the 
end-user's module, only to find that the end-user never built the 
correct library for his use because the default was to build a different 
variant.