Re: [Boost-build] Parallel builds and runs

From: Noel Belcourt (kbelco_at_[hidden])
Date: 2006-02-22 01:17:28

On Feb 21, 2006, at 12:38 PM, David Abrahams wrote:

> "Noel Belcourt" <kbelco_at_[hidden]> writes:
>
>> On Feb 21, 2006, at 12:02 AM, Vladimir Prus wrote:
>>
>>> Hi Noel,
>>> Essentially, you ask if Boost.Build supports MPI. I think nobody
>>> ever tried, so we can't claim such support. However:
>>>
>>>> 1) compiling for MPI using the compiler wrapper scripts (mpicc,
>>>> mpiCC)
>>> If the question in replacing 'gcc' with 'mpicc' in command lines?
>>
>> Yes.
>>
>>> Well, you can specify a custom compiler name in 'gcc' invocation, or
>>> you can inherit new "mpicc" toolset from gcc.jam and change it as
>>> needed.
>>
>> Okay, I'll try this out.
>>
>>>> 2) honoring the requested <toolset> by loading the appropriate
>>>> module(s)
>>> I don't understand what you mean here, sorry.
>>
>> Sorry, I was a bit too terse.  Consider Darwin (Tiger actually) where
>> I can have both gcc 3.3 and 4.0 compilers installed and can use the
>> gcc_select command to swap which gcc compiler is picked up.  The
>> ability to swap the default compiler is what I mean by loading a
>> module.  On many of our systems, we have numerous compilers installed
>> and need to load the appropriate compiler module(s) before we build.
>>
>> For example, if on Darwin I asked for a gcc 3.3 build but the last
>> invocation of gcc_select left the 4.0 compilers as the defaults, would
>> bjam detect that the wrong compilers were being run?  I guess my
>> question is does bjam perform a version check on the compiler if the
>> user has requested a specific compiler version?
>
> I know that's a common configuration technique, but Boost.Build
> doesn't work that way.  It's designed so you can build with as many
> versions of the compiler as you like, in one invocation.  So you
> should arrange your
>
>        using gcc : ... ;
>
> invocations in user-config.jam (or site-config.jam) so that they can
> run the compilers without using gcc_select.  For example, my
> user-config.jam contains:
>
>   using gcc : 4.0.2 : /usr/local/gcc-4.0.2/bin/g++.exe ;
>
>   using gcc : 3.4.4 ;  # this one is what you get when you just say
>                        # "gcc" at the command line.
>
>   using gcc : 4.0.0 : /usr/local/gcc-4.0.0/bin/g++.exe ;
>
>   using gcc : 2.95 : /bin/g++-2.exe ;

Dave,

This solution would be ideal if, on our other systems, the paths to the 
compilers, linkers, and communication libraries were known and fixed.  
Unfortunately the paths are only known each time we login and load the 
necessary modules as sysadmin can and does move the installations 
around with regularity.  Since we can't use the above solution we're 
reduced to using bjam to build for a single toolset at a time on those 
systems, which really isn't a problem.

I'll definitely use this technique for the systems we control though.

Thanks.

-- Noel