|
Boost-Build : |
From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 08:50:00
Vladimir Prus <ghost_at_[hidden]> writes:
> Rene Rivera wrote:
>
>> The biggest case for linking statically to *all* libraries, system and
>> internal, is when you are doing utilities that need to work at OS boot time.
>> Things like, cp, sh, etc. at least for *nix OSs.
>
> Ah.. completely forgot about this one.
And I never knew about it... though it's rather obvious once you think
about it. Thanks for the education!
>> Or more specifically have a single feature, perhaps "<link>", that
>> enumerates the above three options, instead of just false/true...
>>
>> <link>shared -- The default (#1 above).
>> <link>static -- Internal libraries linked static (#2 above).
>> <link>maximum-static -- As many libraries as possible are linked static
>> (#3 above)... In some platform, like MacOSX, some libraries must be dynamic
>> linked.
>>
>> Having it this way eliminates the need to worry about what the "runtime"
>> libraries are.
>
> That's an excellent idea! And even if somebody desires to find-tunue
> C runtime only, we've a way for extension: just add new values to the
> <link> feature. Maybe "maximum-static" can be "all-static"?
>
> I'm eager to implement it as soon as possible. Anybody has objections?
I think there was much confusion about the meaning of runtime-link in
v1; many people thought they should set it to dynamic in order to
build a shared library. I am concerned about the name "link" being
even more confusable in that same way.
Otherwise, sounds good to me!
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
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