Boost logo

Boost-Build :

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-10-22 11:43:46

Vladimir Prus wrote:
> On Sunday 22 October 2006 12:44, John Maddock wrote:
>> Vladimir Prus wrote:
>>> Hmm, in which cases will 'g' appear, and for what toolset?
>> "g" indicates a debug runtime, so it should be set for msvc debug builds,
>> and for STLport debug builds, but not for compilers that don't have
>> debugging runtimes: refer to the logic in bbv1 for what we did before.
> Ok, I think I know what's going on. In V1 and V2, debug builds have
> <runtime-debugging>on set as well. V1 knows that runtime-debugging property
> has no effect on any toolset except for msvc, so 'g' is not added for those
> toolsets.
> Rene, am I right about this?

I don't think so. Here's what I know...

* V1 uses <runtime-build>debug (equivalent to V2 <runtime-debugging>on)
for the "debug" variant.

* V1 uses <runtime-build>release for the "release" variant.

* V1 does not have any special logic for figuring out if a toolset has
or doesn't a debug runtime. And hence sets the "g" unconditionally when
<runtime-build>debug is present.

* Only a small number of V1 toolsets are specified such that they use
different real runtimes based on the <runtime-build> feature (cw, dmc,
msvc, and stlport).

* The Boost V1 Jamfile builds all the variants resulting from
specifying: "debug release [debug-python] <runtime-link>static/dynamic
<threading>single/multi" on Windows (regardless of toolset). And
otherwise from: "debug release [debug-python] <threading>single/multi".
The only rationale I can think of for that difference right now is that
there where no non-Windows platforms we supported that had distinct
debug/release runtimes.


-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at