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
> 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
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk