|
|
Boost Interest : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-06-27 08:57:07
Beman Dawes wrote:
>
>
> On Thu, Jun 26, 2008 at 10:02 PM, Doug Gregor <doug.gregor_at_[hidden]
> <mailto:doug.gregor_at_[hidden]>> wrote:
>
> 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.
The point is that most people won't need to, and those that do will
simply install the libraries to separate subdirectories. I go through
this with gcc all the time. I have no idea how distributions build gcc
different versions so that they can coexist on the same system, but I've
been told I simply need to set up a different --prefix= (install root)
when building and installing multiple versions side-by-side (and I can
attest that if I don't do that, all hell breaks loose). So I install
gcc-4.3.1 under /usr/local/gcc-4.3.1, which means the binaries are in
/usr/local/gcc-4.3.1/bin, the libraries are under
/usr/local/gcc-4.3.1/lib, headers are in /usr/local/gcc-4.3.1/include, etc.
So for different boost variants, for users could -- for example --
create their own mangled parent directory under which everything gets
installed, e.g.:
boost-1.35-mt-x64/
boost-1.35-mt-x64/lib
boost-1.35-mt-x64/include
etc...
which (among other things) would allow them to leave out the cryptic
mangled bits for variations they don't care about. How many people care
about linking against a static runtime?
That said, I think most people never need to look at mangled library
names on Windows, because auto-linking takes care of grabbing the right
binary. I'm just not convinced that mangling causes the same kinds of
problems for windows developers, so maybe we need to keep it on that
platform.
> 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.
Huh? They want Boost to have more mangling, and yet they're unwilling
to use it for their own libs? I don't get it. Maybe it's because their
libs build in the IDE, which manages all of the necessary isolation and
PATH settings automatically?
> 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.
Well, surely, that script wouldn't need to be complex! I'm perfectly
willing to write such a thing if nobody else steps up.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com