From 6c13901b8c3fbbc83968ea452bfd5ebdc3a5f041 Mon Sep 17 00:00:00 2001 From: Dave Abrahams Date: Fri, 23 Mar 2007 14:21:49 +0000 Subject: [PATCH] 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 : ... : : : gcc 4.1.2_linux_x86_64 ; using python : 2.4 : ... : : : gcc 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] --- v2/tools/python.jam | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/v2/tools/python.jam b/v2/tools/python.jam index 33855df6d..d2daa9dbe 100644 --- a/v2/tools/python.jam +++ b/v2/tools/python.jam @@ -525,6 +525,9 @@ local rule compute-default-paths ( # The version of the python interpreter to use feature.feature python : : propagated ; +feature.feature python.interpreter : : free ; + +flags python.capture-output PYTHON : ; # Return a list of candidate commands to try when looking for a Python # interpreter. prefix is expected to be a native path. @@ -790,9 +793,7 @@ local rule configure ( condition += $(target-os) ; - # Set up the PYTHON variable to point at the interpreter. - flags python.capture-output PYTHON $(condition:J=/) : $(interpreter-cmd) ; - + # Set up the PYTHON variable to point at the interpreter. local target-requirements = $(condition) ; local system-libs ; for local x in [ system-library-dependencies $(target-os) ] @@ -836,6 +837,8 @@ local rule configure ( dll-path += $(exec-prefix) ; } + local usage-requirements = $(includes) $(interpreter-cmd) ; + # # Declare the "python" target. This should really be called # python_for_embedding @@ -847,7 +850,7 @@ local rule configure ( : : $(target-requirements) : - : $(includes) $(fwk) + : $(usage-requirements) $(fwk) ; } else @@ -861,7 +864,7 @@ local rule configure ( # the system libs is a mystery, but if we don't do it, on # cygwin, -lpythonX.Y never appears in the command line # (although it does on linux). - : $(includes) $(libraries) $(dll-path) python.lib + : $(usage-requirements) $(libraries) $(dll-path) python.lib ; } @@ -886,7 +889,7 @@ local rule configure ( : : $(target-requirements) : - : $(includes) + : $(usage-requirements) ; } }