|
|
Boost Interest : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-06-27 11:46:15
On Fri, Jun 27, 2008 at 8:57 AM, David Abrahams <dave_at_[hidden]> wrote:
> 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...
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.
My work flow for Boost development goes like this: I've got a three monitor
setup. I run VC++ 9.0 on the central monitor, with a IDE solution for the
library I'm working on that builds dlls, tests, and examples. The tests are
automatically executed by a post-build step, so I new need to leave the IDE,
and if there is a test failure it takes me right to the line of the test
that failed.
I've got a command line window open on another monitor, and when the tests
are passing in the IDE, I launch a simple .bat file that runs bjam on all
the compilers I've got installed, runs process_jam_log, and brings up the
results in a browser that is open on the third monitor. To repeat the tests
from the command line, I just hit the up arrow and return.
Note that the Jamfile involved is right from the SVN working copy; I don't
have to maintain a second Jamfile for my own use.
I don't care about how the internals work, but I'd like to mainain a very
similar workflow and ease-of-setup for new compilers or other build/test
variants.
--Beman