|
|
Boost Testing : |
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