Re: [jamboost] Expanding toolsets to vary by platform

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-03-22 17:27:08

On 2002-03-22 at 09:50 PM, digiharmon_at_[hidden] (digiharmon) wrote:

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

The trivial aspect of it is that all it would take is to add another
subvariant feature to encompass the new orthogonal aspect. In this case one
might add a "platform" feature. Then the above coould become:

flags gcc PLATFORM <platform> ;
switch $(PLATFORM)
{
case NT*:
flags gcc CFLAGS <threading>nulti : -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 

[...etc]
}

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

It would be doable with the added subvariant spec. It would then put the
objects in separate subdirectories depending of the value of "platform".

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

Never use the brute force way, it tends to fight back ;-)

[Hopefully the other message I posted about cross-compilation will show up
soon.]

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]