From: David Abrahams (dave_at_[hidden])
Date: 2004-08-31 11:47:11
"Robert Ramey" <ramey_at_[hidden]> writes:
> I would like to see a little more order/organization in the creation of new
> For example in the current CVS we have for Codewarrior
> This is only an example. The same problem is occurring in gcc and mingw
This is a temporary condition. After this we're going to retire
BBv1 and switch to BBv2, which has a saner toolset protocol (one
toolset file per family).
> It creates a couple of problems
> a) we're not all testing with the same Jamfile. This leads to a lot of
> b) If I have a jam file which needs special treatment for a particular
> compiler, I have to included a line for each toolset - and that can change
> in the future creating another obscure bug to track down.
No you don't. I know it's not documented, but you can put a
rule name in the requirements and use pattern matching within the
rule. For example, here are some rules that get used to build
# Normally on Linux, Python is built with GCC. A "poor QOI choice" in
# the implementation of the intel tools prevents the use of
# intel-linked shared libs by a GCC-built executable unless they have
# been told to use the GCC runtime. This rule adds the requisite
# flags to the compile and link lines.
rule python-intel-use-gcc-stdlib ( toolset variant : non-defaults * )
if ( ! $(PYTHON_WINDOWS) )
&& ( ! <define>BOOST_PYTHON_STATIC_LIB in $(non-defaults) )
&& [ MATCH (intel) : $(toolset) ]
return <stdlib>gcc ;
# Force statically-linked embedding applications to be multithreaded
# on UNIX.
rule python-static-multithread ( toolset variant : properties * )
if ! $(PYTHON_WINDOWS)
local x = <define>BOOST_PYTHON_STATIC_LIB <threading>single ;
if $(x) in $(properties)
properties = [ difference $(properties) : <threading>single ] <threading>multi ;
return $(properties) ;
# Borland compilers are not supported
rule boost-python-disable-borland ( toolset variant : properties * )
if [ MATCH .*(bcc|borland).* : $(toolset) ]
properties += <build>no ;
return $(properties) ;
> c) The documentation on the "getting started" page is way out of sync with
> the toolsets in existences.
> A somewhat related problem - or maybe the cause of the above is the fact
> that the Jamfile doesn't have access to the compiler version.
You can extract some information from the toolset name.
> I'm not sure
> what to do about this. But, here's a suggestion for consideration to start
> the discussion.
> Right now we pass a variable to bjam with the toolset name. e.g
> bjam -sTOOLS=cwpro-9.2
> How about the idea
> Bjam -sTOOLS=cw -sCOMPILER_VERSION=9.2 -sSTD_LIBRARY=stlport
Just hang on for BBv2. It'll all get better.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk