Re: [Boost-build] [boost] [bbv2][autolink] Re: Naming of32/64bitlibs

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.

HTH.

-- 
-- 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