|
|
Boost Testing : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-06-23 08:24:31
Martin Wille <mw8329_at_[hidden]> writes:
> David Abrahams wrote:
>> Martin Wille writes:
> [...]
>>>include $(BOOST_ROOT)/tools/build/v1/gcc-stlport-tools.jam ;
>>
>>
>> The line above is the wrong way to go about things. Why aren't you
>> using
>>
>> extends-toolset gcc-stlport ;
>>
>> all other such toolsets do?
>
> Because the language used in Jamfiles was a mystery to me when I wrote
> that (mostly, it is still a mystery to me).
Well, "do what the other toolsets do unless it doesn't work" is a good
guideline.
> You may get away with it in this
>> case, but it's a hack.
>
> It works fine for me, since I only run tests for one toolset at a time.
You seem to understand more than you claim about how BB works.
> We'll, hopefully, switch to BBv2 soon; I don't think I need to fix my
> toolset definitions now.
Your choice.
> One example for mysteries: I used 'extends-toolset' for the
> intel-based toolsets. However, while I was able to use 'local' for a
> couple of variables, I wasn't able to use it for PYTHON_ROOT.
> Hence, the intel-7.1-linux toolset reads:
>
> {
> local INTEL_LINUX_VERSION = "70" ;
> local INTEL_LINUX_ROOT = "/usr/local/icc-7.1/compiler70" ;
>
> PYTHON_ROOT = "/usr/local/Python-2.2.3-intel" ;
>
> extends-toolset intel-linux ;
> }
>
I think I can explain the problem you were seeing. Toolset files are
read once for each toolset and target that is being built, but
python.jam is not a toolset file, so it is read only once and its
configuration variables only get set up once.
Until just now, I had forgotten that sometimes you really do need a
python that's built with the same compiler you're testing for -- I
guess that's something we'll need to build into BBv2.
-- Dave Abrahams Boost Consulting www.boost-consulting.com