On Thu, Jun 26, 2008 at 10:02 PM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Thu, Jun 26, 2008 at 8:00 PM, David Abrahams <dave@boostpro.com> wrote:
> Doug Gregor wrote:
>> On Thu, Jun 26, 2008 at 1:02 PM, troy d. straszheim <troy@resophonic.com> 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. People have been doing this on Unix systems for many,
many years. It's simple and works very well.

Doug, you need to explain this to us Windows developers who don't have a clue as to how to manage multiple build variants of libraries without name mangling.

FWIW, I'm working on a commercial project now where developers are unhappy with Boost because we don't include 32-bit/64-bit builds in the name mangling.

These same folks decide not to use name mangling in their own libraries, and as a result are running into constant hassles.

Note that this isn't an issue of different compilers, but rather debug | release, and 32-bit | 64-bit builds with the same compiler.

I'd love to see name mangling go away, but how are we supposed to manage build variants without mangling?

The library name-mangling
stuff we do causes these users a *huge* amount of complication.

> 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.

The more I think about that, the more concerned I become that's a showstopper for me. Why can't you provide a wrapper that makes it appear that there is support for multiple compilers?

CMake won't work for me, and I suspect a lot of other developers, if I have to write complex scripts before I can even start to use it.

--Beman