Boost logo

Boost :

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-11-20 21:18:29


Roland Schwarz wrote:
> David Abrahams wrote:
>> ... Why don't you try the instructions and see if they work
>> for you? Where they fail, we'll have to fix something.
>
> My findings so far:
>
> 1) bjam --v2 switch still necessary (I tried in the HEAD)

In the RC branch that is not the case. We need to keep the BBv1
available in HEAD so that we can do comparisons between them. Although I
guess we could add a "--v1" in HEAD, but perhaps it's not worth the effort.

> 2) toolset=msvc builds e.g. boost_thread-vc-mt-gd-1_35.lib, i.e.
> no toolset version

Which follows what BBv1 does. But maybe that's not a good thing seing as
one was very unlikely to use an unversioned toolset.

> 3) toolset=gcc chooses the compiler which is closer in PATH.
> If you think this is reasonable enough, there is no need
> for action. I'd suggest to possibly mention it in the doc.
> I suspect msvc auto toolset choice is different, isn't it?
> This will choose the newer, not the "closer in PATH" one,
> does it?

I think we need to make this consistent across toolsets. AFAIR we've
always preferred using the most recent toolset version.

> 4) For gcc I get a lot of
> warning: Unable to construct ./stage-unversioned
> messages upfront

Don't know what those are about.

> 5) It is possible to "invent" arbitrary toolset versions.
> e.g. it is possible to bjam --v2 --toolset=gcc-17.4 which
> results e.g. in boost_thread-gcc174-mt-d-1_35.dll.
> Don't know if this is expected, In particular I don't know
> which compiler really is getting used here (I suspect
> again the closer one in PATH)

Except for the auto-detected toolsets the version is entirely up to the
user. This is true in both the command line and in the user-config.jam.

-- 
-- 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 list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk