From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-10-22 12:05:43
On Sunday 22 October 2006 19:43, Rene Rivera wrote:
> 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.
Hmm, my experiments don't confirm this. I go to libs/thread/build and run:
bjam -sBUILD="debug <runtime-build>debug"
the libraries created are:
And there's no 'g' in the library name. So it looks like some code figured out
that <runtime-build>debug does not affect gcc?
> * 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".
So, on Windows only, we also add variation on <runtime-link> property. Right?
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