Re: [Boost-build] Shorten output directory names

From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2006-12-11 15:08:56

On Dec 11, 2006, at 8:28 AM, Jared W. Robinson wrote:

> This isn't perhaps the answer you're looking for, but instead of using
> feature flags, you can specify <cflags>, <cxxflags> and <linkflags> --
> that way, the features of the compiler don't show up as part of the
> build path. Here's an example:
>
> project :
>   : build-dir buildoutput
>   : requirements
>     <toolset>msvc:<cflags>/GS
>     <toolset>msvc:<linkflags>/FORCE:MULTIPLE

Hi Jared,

Thanks for the idea.  We would use this technique if we could figure  
out how.  We have introduced several features and are attempting to  
compose them with the address-model feature and we've found we need  
to do much more than just set compile and linker options.  Here's  
some other features we've introduced.

feature mpi : vendor myrinet infiniband : optional ;
feature blas : vendor mkl atlas goto source : propagated optional ;

We allow our users to select which blas library to use.  Some of our  
systems have multiple Blas libraries (vendor, MKL, Atlas, Goto) and  
on other systems we have no optimized Blas library at all, which is  
why the Blas source option exists.  We give the user the ability to  
select which Blas libraries to use on the command line.  Here's how  
we handle vendor supplied Blas libraries on the Sun and Ibm.

# sun.jam
flags sun.link OPTIONS <blas>vendor :  -lsunmath -lsunperf ;

# vacpp.jam
flags vacpp FINDLIBS <blas>vendor : essl m ;

Here's an example of selecting the MKL library based on the address- 
model and whether building static or shared.  User's applications  
reference the alias lapack which does nothing on systems with vendor  
supplied Blas libraries.  If no vendor Blas libraries exist, the  
lapack target defaults to building Blas from source code.  If the  
user asks for MKL libraries, this is how we figure out which  
libraries to link in and how to find them.

alias lapack ;
lib guide ;

lib mkl
   : guide
   : <address-model>32
     <link>static:<name>mkl_ia32
     <link>shared:<name>mkl
   ;

lib mkl
   : guide
   : <address-model>64
     <link>static:<name>mkl_em64t
     <link>shared:<name>mkl
   ;

  lib mkl_lapack
   : mkl
   : <link>static:<name>mkl_lapack
     <link>shared:<name>mkl_lapack
   :
   : <library-path>$(intel-mkl-libpath)
     <link>shared:<dll-path>$(intel-mkl-libpath)
   ;

# for missing second() in libmkl_lapack
# gcc defines second() somewhere so this not needed for gcc
explicit mkl_second ;
lib mkl_second
   : [ glob $(lapack-root)/SRC/second.f ]
   ;

alias lapack
   : mkl_lapack
     mkl_second
   : <blas>mkl <toolset>intel
   :
   : <blas>mkl <toolset>intel
   ;

alias lapack
   : mkl_lapack
   : <blas>mkl <toolset>gcc
   :
   : <blas>mkl <toolset>gcc
   ;

The values of lapack-root and intel-mkl-libpath have default values  
that can be overridden by the user.  This solution seems to work okay  
so far but I'm not sure it's the right approach.  Any ideas on better  
solutions?

-- Noel