|
|
Boost Interest : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-06-27 08:24:59
On Thu, Jun 26, 2008 at 10:02 PM, Doug Gregor <doug.gregor_at_[hidden]> 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. 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