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]
Make path-to-native work on zero or more paths, which simplifies lots
of code.
Factor native path translation out of compute-default-paths and into its caller.
Remove the path-to-native translation on the prefix from
candidate-interpreters, as the passed prefix has to be native anyway.
Fix the capturing of the exec_prefix for use in setting dll-path for
windows targets.
[SVN r37255]
* add ".lib" to the target name for libpython. *** This is a kluge!
I don't know why it should be necessary ***, but when I was
inserting debugging code that did
ECHO [ $(target).name ] ;
it would always drop the 2nd digit, e.g. python-2.4 would come out
as "python-2". This change prevented it.
* Fixed spelling and grammar in comments
* Fix the incorrect assumption in capture-output that only one Python
extension will participate (also in tools/build/v2/testing.jam).
[SVN r37215]
** bbv2python branch. **
gcc.jam: build and use import libraries on Cygwin and Windows, but
accept DLL-only linking with prebuilt DLLs.
builtin.jam: fix default-host-os so that <target-os> actually becomes
a functional feature. Improve English in comments
property-set.jam: add str method so we can print them in generator
debugging output.
generators.jam: improved debugging output
build-system.jam: add missing semicolon
python.jam:
* fix cross-NT/CYGWIN build support
* add condition to the build requirements of the python targets
os.jam:
* add the ability to get constants for a particular OS
builtin.jam:
* remove "optional" attribute from host-os
* fix confusing indents
python.jam
----------
* Removed comments about known problems because they make no sense.
* Unified MacOS initialization with NT and *nix
* Updated comment describing init behavior
* Support for passing Python command as first argument
* Removed unused get-python-interpreter and get-python-version rules,
since they can't work with that interface. Working versions of
these will be reinstated for Doug Gregor in the near future.
* When invoking Python to collect configuration info, collect it all at at once.
* When a Cygwin symlink is found by an NT build of bjam, give hints
about where to find the file it points at.
* Lots of refactoring
* Make the logic work plausibly even when no Python executable can be found
darwin.jam
----------
* Simplified logic for setting up FRAMEWORK_PATH
* Corrected logic for setting up -framework option
feature.jam
-----------
* Make feature.defaults, feature.attributes, feature.values, and
feature.get-values resilient to feature names being passed without
grist.
gcc.jam, python.jam, builtin.jam
--------------------------------
* Include some progress volodya has made toward support for <suppress-import-lib>
[SVN r37186]
This change addresses how Darwin handles compiling for frameworks. The
python frameworks require specific #include syntax that is not present
in the boost source code so this change specifically adds python
framework includes to the compile line.
[SVN r33402]
