Boost logo

Boost Interest :

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-26 22:23:57

Doug Gregor wrote:
> On Thu, Jun 26, 2008 at 8:00 PM, David Abrahams <dave_at_[hidden]> wrote:
>> Doug Gregor wrote:
>>> On Thu, Jun 26, 2008 at 1:02 PM, troy d. straszheim <troy_at_[hidden]> wrote:
>>>> Personally I find the embedding of toolset and version in library names to
>>>> be problematic... in this case it makes the FindBoost.cmake really
>>>> complicated and binds the (what should be simple) business of using the
>>>> libraries to details that are utterly irrelevant here.
>>> While I, personally, agree with you, I just don't think this is
>>> feasible. FindBoost is there so that people can use Boost from CMake,
>>> and that includes using existing and future Boost releases that depend
>>> on Boost.Build's mangled library names. I disagreed with the mangled
>>> approach from the start, but we're stuck with it.
>> Really? I must've missed something. What practical alternative did we
>> have at the start,
> Don't mangle library names. Those very few users who need to build
> with multiple compilers will just keep separate build/install
> directories.

But as you know, it's not just about multiple compilers: it's about
incompatible ABI options and interface changes across versions of Boost.

> 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
 Are all of those letters solving non-problems?

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.

Don't get me wrong; I'd rather drop mangling too; it just isn't obvious
to me (yet) that Boost isn't unlike the other C++ libraries out there in
important ways that warrant keeping it.

> It's simple and works very well. The library name-mangling
> stuff we do causes these users a *huge* amount of complication.

I know :(

That doesn't mean we can drop it. But I'd like to be convinced.

>> and if we didn't need it then, why can't we quit now?
> I'm referring to the FindBoost.cmake module, which needs to deal with
> Boost as it is deployed now, mangled library names and all.
> For the CMake-based Boost build system, we could consider dropping the
> idea of versioned libraries entirely. We've already decided not to
> even attempt support for building with multiple compilers in a single
> invocation. However, dropping versioned libraries means we won't be
> producing the same things as bjam, so it could make the switch to
> CMake harder.

Or it could make everybody really, really happy that they won't have to
deal with mangling again :-)

Dave Abrahams
BoostPro Computing

Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at