"Robert Ramey" <ramey@rrsd.com> writes:
I would like to see a little more order/organization in the creation of new toolsets.
For example in the current CVS we have for Codewarrior
Cw Cw-9.2 Cwpro-9.2 Cw-8.3 Cwpro-8.3
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 confusion. 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 Boost.Python extensions: # 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 ; } else { return ; } } # 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