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

From: David Abrahams (dave_at_[hidden])
Date: 2007-03-20 08:25:25

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

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

OK, thanks.

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

I also realize that sticking the version in the target name is
completely unnecessary.  

>> > 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 don't think that makes sense.  For example, on cygwin the python dll
can be found in the same directory as its import library.  Does it
make sense to entirely give up control over which one we link to?

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

OK, that's fine.  I hope it will help you solve the real mysteries.  I
still like the idea of having a libpython target that's symmetric with
rt, dl, et. al., but that's just an aesthetic consideration.

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

Thanks.

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