Re: [Boost-testing] Martin Wille x86_64 V2 - python

From: David Abrahams (dave_at_[hidden])
Date: 2007-03-23 10:22:04

on Fri Mar 23 2007, Martin Wille <mw8329-AT-yahoo.com.au> wrote:

> I wrote:
>> David Abrahams wrote:
>>> http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/output/Martin%20Wille%20x86_64%20V2-boost-bin-v2-libs-python-test-builtin_converters-test-gcc-4-1-0_linux_x86_64-debug_release.html
>>> seems to indicate corruption of the python executable.  Is everything
>>> OK with that installation?
>> 
>> 
>> I can run the Python executable without problems. The error message 
>> looks like Python tried to execute the python binary as a Python script. 
>
> That's exactly what's happening. The following is from bjam.log from my 
> recent x86/64 run, the third line says that an unrelated python binary 
> gets used to run the correct python binary:
>
> PYTHONPATH=/b/r/rc/results/boost/bin.v2/libs/python/test/gcc-4.1.2_linux_x86_64/debug
> export PYTHONPATH
>   /usr/bin/python2.4 /usr/local/python/2.4/gcc-4.1.0/bin/python2.4 
> "../libs/python/test/test_builtin_converters.py"   > 
> "/b/r/rc/results/boost/bin.v2/libs/python/test/builtin_converters.test/gcc-4.1.2_linux_x86_64/debug/builtin_converters.output" 
> 2>&1

I suspect I know the reason for this problem, and I've checked in a
fix.

IIUC, your configuration looks like:

   using python : 2.4 : ... ;
   using python : 2.4 : ... : : : <toolset>gcc <toolset-gcc:version>4.1.2_linux_x86_64 ;
   using python : 2.4 : ... : : : <toolset>gcc <toolset-gcc:version>4.1.0_linux_x86_64 ;

The intention is of course that the latter pythons will be used in
preference to the former one if their conditions are matched more
explicitly.  

We are using the "flags" rule to directly associate the interpreter
command with targets being built, provided the condition passed is
matched.

    # Set up the PYTHON variable to point at the interpreter.
    flags python.capture-output PYTHON $(condition:J=/) : $(interpreter-cmd) ;

Here's an excerpt of docs for the condition parameter on flags:

             condition * :    # A condition when this flag should be applied.
                              # Should be set of property sets. If one of
                              # those property sets is contained in build
                              # properties, the flag will be used.

So what happens is that, because it's less specific, the flags
invocation for the first python matches when either of the latter
pythons was supposed to match, and the PYTHON variable that is used to
hold the interpreter command on the testing target accumulates both
interpreters.

We have a mechanism for "choose the closest property match," but it
doesn't apply to the flags rule: it's target alternatives.  Since we
define target alternatives for the python library anyway, I think I
can handle this by creating a property to hold the interpreter command
and associating it with the appropriate target alternative, then
keying off *that* command to set up flags.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com