Expanding toolsets to vary by platform

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 
multiple
# build tool suites (e.g. msvc, gcc,...) and build variants (e.g. 
debug,
# release...). Although it currently varies across two dimensions, it 
should
# trivially support extension to three or more, e.g. in case of cross-
platform
# 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 
gcc
}
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 
other.

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:

<gcc><define>USE_GCC_STUFF=1

I would have to put:

<solaris-x86-gcc><define>USE_GCC_STUFF=1
<solaris-sparc-gcc><define>USE_GCC_STUFF=1
<macosx-ppc-gcc><define>USE_GCC_STUFF=1
<...other platforms-gcc>USE_GCC_STUFF=1
<...yada-yada>

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

thanks,
Jerry