Re: [jamboost] Re: boost parallel build, will it get better?

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-04-29 09:53:58

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> 
>>In testing.jam, I'm trying another approach -- the tested command is
>>not run directly, but via
>>
>> $(LAUNCHER) $(COMMAND)
>>
>>so you can do
>>
>> bjam --v2 testing.launcher=valgrind
>>
>>This can be generalized to all toolsets, but seems like a lot of
>>work with no apparent benefit.
> 
> 
> Maybe so, but I don't see how the current system can work.

If it makes the code more flexible it's a benefit. If it makes it's more 
explicit, and less fragile, it's a benefit. I'd love to see the "using" 
interface standardized to have fine control of the actual tool 
configuration as possible. And to take a note from the recent autoconf 
discussion we should at minimum support the same level of configuration 
it has in this aspect:

Nick Rasmussen wrote:
> The AC_PROG_CC and AC_PROG_CXX print this out by default now at the
> bottom of the configure --help output. e.g.:
> 
> Some influential environment variables:
> CC C compiler command
> CFLAGS C compiler flags
> LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
> nonstandard directory <lib dir>
> CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
> headers in a nonstandard directory <include dir>
> CPP C preprocessor
> CXX C++ compiler command
> CXXFLAGS C++ compiler flags
> CXXCPP C++ preprocessor

We could have something like:

using gcc : gcc-3.4-arm :
CC=/x/y/bin/arm-gcc CPP=/x/y/bin/arm-gcc
CXX=/x/y/bin/arm-g++ CXXCPP=wave
ROOT=/x/y ;

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org