On Fri, Jun 27, 2008 at 8:57 AM, David Abrahams <
dave@boostpro.com> wrote:
> <mailto:
doug.gregor@gmail.com>> 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.
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...
I'm very familiar with that model. It's what the commercial project I mentioned is doing for the third-party libraries that don't mangle names. It is a PITA. Most of the developers have never used the command line, so I end up getting stuck with a lot of really crappy build work for libraries like iconv and xerces simply because I know how to use command line tools.
I want to emphasize that these are skilled software developers with a decade or more of experience each. They are used to Windows, where stuff just installs and works with their IDE.
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?
Some teams I work with use only static linking because they see it as more robust and cutting the number of bug reports and cutting the number of configurations that have to be tested against.
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.
Exactly.
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?
Right. They use the VC++ IDE, and look at me like I'm from another planet when I suggest that some tasks are best completed from the command line.
> 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.