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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-03-20 03:13:15

On Tuesday 20 March 2007 02:16, David Abrahams wrote:

> 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.

Doh, CVS decided to keep me on bbv2python branch! I'm getting
the other error, that I'm investigating.

> > 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?

'python' target that depends on some other python target having
version in target name.

> > 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.

That's in theory, in practice we might rename 'find-shared-library' to
'find-library' since no toolchain allows to accurately request only shared or
static library.

> * 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.

But it's not user code. But anyway, that's not what I find important.

> 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, 

Add <name>XXXX to the 'python' target, and change its type from alias
to lib? I'm gonna try it while I'm on it.

> 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.  

Such a change is only to simplify code.

> 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.

Okay, I'll see if that can be made simpler.

- Volodya