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

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

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

> On Tuesday 20 March 2007 10:34, K. Noel Belcourt wrote:
>> 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.
>
> I mean that I personally don't know any toolset that can say: "I want
> library X to be shared/static, if such flavour is not found, bail
> out". In fact, I only know of gcc that tries to support that -- but
> its "-shared" means "prefer shared libs", while its "-static" means
> "link only to static", so they are not symmetric.

I'm not sure that matters.  If we tell users that they should use
"find-xxx-library" when they _know_ there's an xxx library present and
they want to be sure to use that one and not some yyy flavor of the
same library, either behavior is sufficient.  We can even say that
when an xxx library isn't present, the behavior is unspecified.

The behaviors of the GCC flags are obviously useful to some people or
they wouldn't exist, and I don't see why they shouldn't be supported.

>> 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.
>
> I'm saying that if OS allows both static and shared, I don't know any
> way to ask for a specific flavour of a specific library and always get
> it.

Yeah, but so what?  You can ask for that flavour and
get-it-if-it's-available.

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