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.
>>>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?",
> 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
> 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
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