|
|
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
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?
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 http://www.boostpro.com