Boost logo

Boost-Build :

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


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk