Re: [Boost-testing] bjam no longer detects user-config.jam in the current working directory

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2007-08-16 15:40:55

Roland Schwarz wrote:
>
> FWIW: The variable is: BOOST_USER_CONFIG and has same meaning than the
> --user-config switch

Yes, BOOST_USER_CONFIG works. Thanks for the info!

> What puzzles me is the stated behaviour that Boost.Build took up
> user-config.jam
> from the current working directory. This can't be true as far as
> I understand.
> The only exception I could think of is when BOOST_BUILD_PATH happens
> to contain
> a path to the current directory, i.e. where bjam is being invoked from.

It was (and still is) exactly the case in my environment:

        export BOOST_BUILD_PATH=`pwd`

and it used to work before the change in bjam Rene pointed out to.
By "used to work" I mean bjam would use user-config.jam in the current
working directory.

> But: In either case: --user-config= will always work. So this is the
> safest bet.

Unfortunately, as I said in the previous mail, on setup phase, when building
process_jam_log, regression.py does not pass bjam-options to bjam. Here is my
regression.py command:

python regression.py setup --toolsets=acc \
       --bjam-options="--user-config=$BOOST_BUILD_PATH/user-config.jam"

and here is how bjam is invoked:

# Building "process_jam_log" 
("/hpadl881/boost/HEAD/regression/boost/tools/jam/src/bin.hpux/bjam" --v2 
"-sBOOST_BUILD_PATH=/hpadl881
/boost/HEAD/regression" "-sBOOST_ROOT=/hpadl881/boost/HEAD/regression/boost" 
acc)...

Thanks,
  Boris

----- Original Message ----- 
From: "Roland Schwarz" <roland.schwarz_at_[hidden]>
To: "Running Boost regression tests" <boost-testing_at_[hidden]>
Cc: "Boris Gubenko" <Boris.Gubenko_at_[hidden]>
Sent: Thursday, August 16, 2007 7:00 AM
Subject: Re: [Boost-testing] bjam no longer detects user-config.jam in the 
current working directory

> Rene Rivera wrote:
>> Boris Gubenko wrote:
>
>>> Is there some environment variable which can be set to point to
>>> user-config.jam ?
>>
>> There was mention of providing a USER_CONFIG env var, but I think that was 
>> rejected.
>
> FWIW: The variable is: BOOST_USER_CONFIG and has same meaning than the
> --user-config switch
>
> What puzzles me is the stated behaviour that Boost.Build took up 
> user-config.jam from the current working directory. This can't be true as far 
> as I understand.
> The only exception I could think of is when BOOST_BUILD_PATH happens to 
> contain a path to the current directory, i.e. where bjam is being invoked 
> from.
>
>
>>
>>> Note that specifying
>>>
>>>   --bjam-options="--user-config=$BOOST_BUILD_PATH/user-config.jam"
>>
>> Yea, that should work.
>
> Hmm, Boost.Build still will take up user-config.jam from BOOST_BUILD_PATH,
> _but_ when building boost libs boost-build.jam will prepend the tools/build/v2 
> directory in front to load the in-tree build system (by calling rule 
> boost-build). Unfortunately in this directory there also is a stock 
> user-config which now will be loaded as a side effect.
>
> Either use --user-config= or BOOST_USER_CONFIG to address this.
>
> Hmm, it also should be possible to only load the bootstrap file from 
> boost-build path and then for user-config.jam have the prvious behaviour. Need 
> to discuss this with volodya.
>
> But: In either case: --user-config= will always work. So this is the safest 
> bet.
>
> Roland aka speedsnail
>