Dave Abrahams 6c13901b8c Fix a bug wherein multiple python interpreters could get set on a ...

target.  My explanation from a mail to Martin Wille:


  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.


[SVN r37272]

2007-03-23 14:21:49 +00:00

35 KiB

Raw Blame History

View Raw