Boost logo

Boost-Build :

From: digiharmon (digiharmon_at_[hidden])
Date: 2002-03-22 16:50:45

In the header for boost-base.jam there is the following comment:

# This system is designed to support building the "same" targets with
# build tool suites (e.g. msvc, gcc,...) and build variants (e.g.
# release...). Although it currently varies across two dimensions, it
# trivially support extension to three or more, e.g. in case of cross-
# builds.

How "trivial" is trivial? The reason I ask is that I see places that
this is already becoming an issue. For example to handle differences
in threading options for different versions of gcc, gcc-tools.jam has:

# set threading options for various platforms:
if $(NT)
flags gcc CFLAGS <threading>multi : -mthreads ;
else if $(UNIX)
switch $(JAMUNAME)
case CYGWIN* :
flags gcc CFLAGS <threading>multi : -mthreads ;
case SunOS* :
flags gcc CFLAGS <threading>multi : -pthreads ;
flags gcc LINKFLAGS <threading>multi : -pthreads ;
flags gcc FINDLIBS <threading>multi : rt ;
NO_GNU_LN = true ; # sun seems not to use the GNU linker with
case BeOS :
# BeOS has no threading options, don't set anything here.
case Darwin :
# MacOS X, doesn't need any threading options set
# -lpthread is linked to by default.
# There is no gcc/g++, we need to use cc/c++ instead:
GCC ?= cc ;
GXX ?= c++ ;
case * :
flags gcc CFLAGS <threading>multi : -pthread ;
flags gcc LINKFLAGS <threading>multi : -pthread ;
flags gcc FINDLIBS <threading>multi : rt ;

How hard would it be to factor out the OS and/or cpu from the
toolset? Is it actually a trivial matter? I don't understand the
internals well enough to know the answer.

I can see real benefits to this, aside from code cleanliness and the
ability to support cross-compiles. For example, I'd like to be able
to have one copy of my tree on a network volume and be able to build
all my various platform builds into the same location. Currently this
isn't really doable, since most of them are various flavors of unix
using gcc, so the object file pathnames collide and clobber each

At face value, the brute force approach seems like it might work. I
could make multiple copies of the gcc-tools.jam for each platform --
solaris-x86-gcc-tools.jam, solaris-sparc-gcc-tools.jam, macosx-ppc-
gcc-tools.jam, etc. I might even be able to use the extends-toolset
rule similar to the way intel-win32-tools.jam derives from the base
msvc-tools.jam. This doesn't seem like it will scale very well
though, especially since my toolset-specific requirements will get
multipled in the Jamfiles rather than inherited. For example, where I
used to have something like:


I would have to put:

<...other platforms-gcc>USE_GCC_STUFF=1

Should I just do the brute force way, or is there a better solution
that doesn't wreck havok on the current system?



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