Boost logo

Boost-Build :

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

lib mkl
   : guide
   : <address-model>64

  lib mkl_lapack
   : mkl
   : <link>static:<name>mkl_lapack
   : <library-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
   : <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

-- Noel

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at