Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at