** This comment represents the aggregate changes merged from the **
** 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 path=/branches/RC_1_34_0/boost/tools/build/; revision=37186
Fix bug reported by Markus SchÃ¶pflin

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37202
Fix failure to print the cmd-or-prefix argument when --debug-configuration is passed.

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37203
Make sure that the libpython target is declared with distinct requirements each time, thus forming valid target alternatives.

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37210
Make sure sys.platform isn't required

Update darwin handler so it will fall back to the standard *nix method
if Python isn't installed as a framework.

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37211
tools/build/v2/tools/python.jam:

 * 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 path=/branches/RC_1_34_0/boost/tools/build/; revision=37215
Merge

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37239
Fix python's generator error

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37243
Properly set up <dll-path> for windows embedding targets.

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37251
Some simplifications.  Building on Cygwin from an NT bjam is broken again :(

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37252
Merge: Remove outdated comment

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37254
factor out the search through Wow6432node in the registry of software

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 path=/branches/RC_1_34_0/boost/tools/build/; revision=37255
Fix extension module suffix on HPUX for Python 2.4 and below

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37269
Removed pthread from hpux system libs per request of Boris
Grubenko (see http://docs.hp.com/en/8759/options.htm#opt-mt)

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37270
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 path=/branches/RC_1_34_0/boost/tools/build/; revision=37272
remove hard-coded -mt

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37308
Fix the use of system library dependencies

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37310
Remove -lpthread for SunOS

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37320
Get rid of the trailing blanks

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37322
Support for --with-pydebug builds.

python.jam:

  Support for the specification of "_d" extension suffix.

  In compute-default-paths, fixed the check for residence in
  a "PCBuild.*" directory so we can build against Windows Python built
  in a source distribution.

common.jam:

  Fixed generation of the "y" tag to look for <python-debugging>on
  rather than the whole debug-python build variant.

  Fixed some grammar and spelling.

virtual-target.jam:

  Added the ability to forego the prepending of "." to a
  generated-target-suffix by specifying the suffix enclosed in <...>

libs/python/build/Jamfile.v2:

  #define BOOST_DEBUG_PYTHON when <python-debugging>on

svn path=/branches/RC_1_34_0/boost/tools/build/; revision=37326