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

From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2007-03-20 03:34:14

Hi Volodya,

On Mar 20, 2007, at 1:13 AM, Vladimir Prus wrote:

> On Tuesday 20 March 2007 02:16, David Abrahams wrote:
>>> 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.

What precisely does this mean (allows to accurately request only  
shared or static library)?  This sounds like you mean no toolset  
permits only static or shared?  We have several toolsets that permit  
only static, in one case, and only shared, in a completely different  
case.

For example, on the Cray xt3, we require <runtime-link-static> which  
requires <link>static which excludes <find-shared-library> as a  
matching property.  Other toolsets requires only <runtime-link- 
shared> since they all use different version of the Myrinet (MPI)  
libraries and a statically bound executable won't run on a system  
unless it has the same internal Myrinet version number (that's why we  
have to ship only <runtime-link-shared> for external release even  
though we support static linking internally.

Not sure if this is the same case but we definitely have cases where  
the OS (or library) only supports static or shared, not both.

-- Noel