Re: [Boost-build] Python's "alternatives" issue

From: David Abrahams (dave_at_[hidden])
Date: 2007-03-19 19:16:31

on Mon Mar 19 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:

> running "bjam -n" in libs/python/test, I get:
>
>   error: No best alternative for /python-2.4
>     next alternative: required properties: (empty)
>              full requirements:  <name>python2.4 <toolset>msvc,<runtime-link>shared:<threading>multi
>         matched
>     next alternative: required properties: (empty)
>              full requirements:  <name>python2.4 <toolset>msvc,<runtime-link>shared:<threading>multi
>         matched
>
> which is no wonder, in fact. Looking at
> python.jam:declare-libpython-target, I see that it does not take any
> parameters for condition,

I don't know what you mean exactly by "parameters for condition," but
the condition is passed to declare-libpython-target in its
"requirements" parameter.

> and therefore declares identical targets
> if version and target-os are the same. I see the following
> arrangment:
>
>       local libpython-target-name = [ declare-libpython-target $(version) : $(target-os) : $(condition) ] ;

There's the condition, in the last argument to
declare-libpython-target.  What am I missing?

I note that you also don't seem to be working with the latest code, as
the variable passed as the last argument is now called
target-requirements.

>         alias python
>           : $(system-libs) 
>           : $(condition)
>           :
>           : <include>$(includes) <library-path>$(libraries) <library>$(libpython-target-name)
>           ;
>
>
> Whereas the 'python' target is declared with 'condition', 'condition' is not passed
> to declare-libpython-target, 

??  I'm really confused.  I don't see how you can say that.

> which leads to this problem. I don't quite understand why this
> two-stage scheme is used, and there's no comment to explain it.

What two-stage scheme?

> There are two possible solutions:
>
> 1. Pass 'condition' to declare-libpython-target

Already doing that.

> 2. Kill declare-libpython-target, add proper <name> property to
> 'python' target directly.

As far as I can tell, declare-libpython-target _is_ adding a proper
<name> property... to the libpython target.  But maybe I'm missing
something.

> Dave, can you clarify what's the purpose of  'declare-libpython-target'.

Well, the body of python.configure was (and still is) too long, so I
tried to factor out as many logically coherent units as possible, and
this was one of them.  If you're asking why there's an invocation of
the "lib" rule and a separately declared libpython target at all, the
story goes like this:

* The old code (see HEAD) used <find-shared-library> in the python
  alias to refer to the python library instead of a "lib" target.

* <find-shared-library> is really wrong, because libpython isn't
  necessarily a shared library at all.

* I went looking for information about what to use instead, and I
  found this posting:
  http://thread.gmane.org/gmane.comp.lib.boost.build/13689/focus=13693
  Where you say

    The <find-library-*> feature are not for users, which should use
    'lib' target anyway.

So I figured the right thing to do would be to define a "lib" target
for the python library.

So maybe that's what you mean by "two-stage."  Well, in general
libpython can be used in two different ways (extending and embedding),
so it seems rational to make it a separate target.  I can see that
it's being directly used only by that one alias ("python"), so maybe
there's a way to eliminate it as a separate target, but that way isn't
obvious to me, and it's also not clear why that should change anything
about the problem Martin is seeing.  As I wrote to you semi-privately,
I'm up against the limitations of my understanding of Boost.Build now.

Incidentally, I also notice that I'm adding libpython by using the
<library> feature instead of just listing it in the sources, and I
don't know why.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com