Re: [boost] [Boost-build] [1.35] what gets built and installed?

From: John Maddock (john_at_[hidden])
Date: 2007-12-20 04:38:08

Rene Rivera wrote:
>> There's a great deal of documentation that would have to change to
>> reflect this as well.
>
> Perhaps... Do you know which docs they might be?

Nope, but I can guess (and would hope) that all the libraries with separate 
source will mention this somewhere.

>> There's also a rationale for why static linking is the default
>> behaviour in our docs here:
>> http://www.boost.org/more/separate_compilation.html#static_or_dynamic
>
> Hm, that doesn't sound to me as a rationale, it's more like an excuse.

Ouch.

> And I suspect the anecdotal evidence about regex is outdated.
> Currently
> we usually recommend, in emails, irc, etc., to use dynamic libraries
> because of memory management problems with static libs. I remember we
> mention this in some docs, but I don't remember the specific docs at
> the moment.

It's probably more accurate to say that it's an MSVC'ism: folks using msvc 
really don't like distributing dll's with their applications.  The 
complaints to the main Boost mailing list to "please make static linking the 
default" were really quite persistent until I changed.

>> There's a further issue with building only one variant under MSVC: it
>> doesn't work!
>
> Interesting definition of "doesn't work". ;-)

Well you can't mix lib's built against the release runtime, with those built 
against the debug runtime, so debug builds are all but impossible if you 
only ship a release build.  Personnally I'd say that was broken ;-)

>> We need to be *very* careful with this, or the complaints will be
>> loud and vociferous!
>
> OK, currently the most common questions and gripes I get are:
>
> * There's are a bunch of stuff built. Which one do I pick?
> * Why does it take so long to build?
> * Why can't I just add a single "-lboost_thread"?
>
> And the majority of questions I get are not from developers that are
> using Boost. But from developers who are using Boost as a third party
> library. And hence the user is only interested in satisfying the
> dependency.

Understood, and on Linux that may well make sense.

>> Dymanic *and* static lib, as Release, multithreaded, dynamic runtime
>> single build on Unix variants (2 build variants).
>
> So, all the problems you mention above are autolink issues. What
> problems building more than the dynamic libs on Unix address?

Mainly it gives the user a choice as to static or dynamic linking: same as 
you get if you build with libtool for example.

>> Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic
>> runtime on Win32 compilers (that's 4 build variants).
>
> A tangent... I can't change the default to vary depending on the
> compiler used. I can only change it depending on the platform one
> *runs*
> on. Which may be inappropriate in a cross-compile context.
>
> Could you provide some rationale for why those specific variants?
> Maybe
> I'm just confused as to why release and debug, and not just debug if
> you
> are trying to satisfy the "default" IDE. (note, I'm not an "IDE"
> person,
> at least as IDE's are currently defined by the industry)

I'm mainly focussing on msvc here, since that's all that supports 
auto-linking anyway (if we ignore msvc-lookalikes for now).  The problem is 
that msvc ships with multiple C/C++ runtimes: 6 of them for VC71, 4 for VC8, 
and wait for it... either 8 or 16 depending how you count them for Borland.

Libraries built against one runtime *can not be used with any other*, if you 
try to do so the program may well link OK, but will almost certainly crash 
at runtime.  This is why regex started supporting auto-linking even before 
Boost: without it even experienced programmers often pick the wrong build 
variant and then you get a persistent stream of complaints along the lines 
of "why does your stupid library crash", which are very time consuming to 
track down and solve.  IMO it would actually be better to provide no build 
system at all for msvc users and say "use your IDE", than to only build one 
variant.  One variant gives the impression that it'll work everywhere when 
it most certainly will not.

BTW, while it is technically possible to use the one of the release runtimes 
in a debug build with msvc, almost no one does that - the IDE makes it 
rather tricky to do, and in my experience it often causes hard to track down 
issues - not least because it confounds the expectations of any other 
non-Boost libraries that autolink.

>> That's an absolute minimum IMO.  Even then we will have to be very
>> careful that our build instructions indicate very clearly how to
>> build the other variants, especially for those msvc users :-)
>
> The goal is not to build a minimum, but to build *1* and leave
> building
> more up to the user. I personally think we've reached the point where
> the Boost libraries are used generically enough that the variant we
> build should be the one most likely to be used in the field. So
> perhaps
> I'm wrong in thinking that the release/mt/dynamic is the one.

IMO the minimum for msvc is the 4 variants that match the 4 runtimes shipped 
with vc8.

I can't comment on Borland: I seem to remember that the static runtimes 
shipped by Borland are more stable than the dll's (or have fewer issues 
anyway), but perhaps a Borland user can comment?

Cheers, John.