Re: [jamboost] Re: runtime-link

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 13:21:57

Vladimir Prus <ghost_at_[hidden]> writes:

> The question is really whether <runtime-link> is link compatible or not.
> And it's orthogonal to all the other discussion, that why I suggest
> to leave it out for a moment.

OK.

>>>Or "external" libraries. Let's use this term, as opposed to "internal".
>> 
>> 
>> I could live with that, but...
>> 
>> I think internal/external are not very descriptive terms, especially
>> when multiple projects are involved, and most especially for new
>> users. I'd prefer "prebuilt" and something else... "boost built?",
>> "rebuildable?"
>
> I get your point. You're right, with several project "external"
> can mean anything. I'll try to come with a better name for
> "internal", then.

Until then, internal/external shall be the working terminology.

>>>Why should I use static runtime but dynamic version of
>>>those 10 libraries?
>> 
>> 
>> All 10? I can't think of a reason. For one library, it might be
>> something like the Boost.Python library, which manages plugins and
>> interactions between them. In that case, it might be important to have
>> a single repository of some central information (i.e. the DLL's global
>> data).
>
> That's it! If you can't think of a reason then "all-static" can
> make all external libraries static. The ones available only
> as DLLs will be handled specially. For example, declaration
> of target will say that it's always DLL.
>
> We can introduce a win-specific feature which controls runtime-link 
> separately, and make "all-static" contain <runtime-link>false,
> as you suggest. I'll leave it to Win32 users to decide.
>
> What's important, is that plain <link>all-static will do
> the same thing both on Linux and Windows.

OK, I think. We /really/ need a different name for all-static
though. I don't want to have to explain the difference between
"static" and "all-static" to users (I've already forgotten the
meaning), nor why there's no "all-dynamic".

>>>Let's decide if the "static runtime, dynamic external libraries" use
>>>case is common enough. Everything else will depend on it.
>> 
>> 
>> I don't know how common it is. It doesn't need to be easy to specify
>> this, just possible.
>
> It is possible. If the only declaration for zlib is
>
> system-lib zlib : <file>.... <link>shared ;
>
> then it will cause dynamic linking of zlib in all cases.

Unacceptable solution, IMO. This is intrusive on the zlib
definition. Suppose both versions exist for some reason, but I want a
particular shared library to link only to the dynamic zlib? Also, it's
dangerous because indirect "include" dependencies could bring in a
static definition for zlib.

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution