Re: [Boost-cmake] Cmake & Boost Libraries

From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-06-26 23:15:00

On Thu, Jun 26, 2008 at 10:23 PM, David Abrahams <dave_at_[hidden]> wrote:
> Doug Gregor wrote:
> But as you know, it's not just about multiple compilers: it's about
> incompatible ABI options

Yes, I know. This is typically handled by having the user just set the
options needed and putting the libraries into some place where all of
the libraries compiled with those options will reside. Problems can
crop up if users are sloppy, of course, so this approach is less safe.

> and interface changes across versions of Boost.

soversions are the right way to deal with this issue, not name mangling.

>
>> People have been doing this on Unix systems for many,
>> many years.
>
> With C++?  I know there are a few C++ libraries out there but I didn't
> think many of them had the kind of variations that we seem to want to
> have.  What do other libraries do about each of the features described
> in
> http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html#library-naming?
>  Are all of those letters solving non-problems?

They are real problems, but how many users will ever use more than
one, default variant of the library?

> Just for example, in single-threaded programs, we apparently don't want
> to make people pay for synchronization when shared_ptr is copied,
> because then they'll say our general-purpose shared_ptr is slow.  But
> then you need separate libraries for single- and multi-threaded
> programs.  OK, shared_ptr is header-only, but I hope you get my point.

I suggest that the vast majority of users should be using the
multi-threaded versions; those that truly will only use Boost in
single-threaded environments and are copying shared_ptrs so often that
their performance is at risk can flip the right switches to build
Boost differently. Few people need that freedom, so the rest of the
users shouldn't pay for it with more complexity.

  - Doug