Re: [Boost-build] v2 Python toolset doesn't faithfully reproduce v1

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-07-22 03:13:45

On Saturday 22 July 2006 10:32, Vladimir Prus wrote:

> > Yes, it's problematic.  On Unix, dynamically loaded python extensions
> > get the python symbols from the executable.  If we're extending
> > Python, then that's the python executable itself.  If we're embedding
> > Python, it's the embedding application, which is supposed to be linked
> > to libpython.a
>
> Yep, we'll end up with two copies of symbols, but is this going to cause
> real problems?
>
> Anyway, I'll try to change this. That raises, again, this question: Do we:
>
>    - Document that for embedding, application should be explicitly linked
> to Python
>    - Add new target "boost_python_for_embedded", that will alias to
>      Boost.Python, Python, and any auxilliary libraries.
>
> I'm fine with just adding /boost/python to all embedding applications, as
> far as tests are concerned. You know better, though.

I've just checked in the attached. Let me know if something looks wrong.

- Volodya

Don't link Boost.Python to python library, and don't require
<threading>multi for embedding applications.

* libs/python/build/Jamfile.v2: (boost_python): Don't link
  to /python//python. Use /python//python_for_extensions.

* libs/python/test/Jamfile.v2: Remove <threading>multi project
  requirements. 
  (py-run): Link to /python//python.
  (exec): Likewise.

* tools/build/v2/tools/python.jam: (pthread): Declare.
  (init-unix): Add 'pthread' to extra-libs.