[boost] Re: toolset proliferation

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