[boost] Re: How to handle name mangling in "versioned" toolsets?

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-06-28 18:50:43

John Maddock wrote:
> At present we have two types of toolsets:
>
> 1) Unversioned toolsets such as "intel-win32", which produce
> unversioned toolset suffixes to library names, "iw" in this case.
>
> 2) Versioned toolsets such as "intel-win32-7.1-vc6-stlport-4.5.3"
> which produce versioned toolset suffixes to library names, "iw71" in
> this case.
>
> This produces a problem with the autolinking code which can take
> either approach, but not both (or at least not both auto-magically,
> and this is causing some regression test failures at present).  In
> other words I'm
> asking for some kind of consistent policy here;  note that if the
> choice is to consistently use "versioned" toolsets then we're
> committing ourselves to constantly updating the build system and
> autolinking code to keep up with
> new compiler releases.  So, I guess I'm leaning towards "unversioned"
> mangled toolset names, but would like more some feedback, so: what
> does everyone else think?

I think versioning is better because end-users easily get confused if there
is a non-versioned toolset around and they have forgotten to what version
that toolset applies, or does it apply to all versions and, if so, starting
with what version. Furthermore, if the ABI changes, you will have a
non-versioned toolset with a generic name and a versioned toolset for
particular versions, and now the end-user must remember, let's say, that an
early versioned toolset is for version 2.1, a non-versioned toolset is for
2.2, 2.3, and 2.4 and finally the most recent versioned toolset is for 2.5.
Finally if you have to add a versioned toolset because of an ABI change, you
need all versioned toolsets after that since if you go back to non-versioned
for any reason you now have discontinuous non-versioned toolsets.

I think you are asking for trouble with non-versioned toolsets because you
must essentially keep them non-versioned forever after the first one and
end-users will not like the idea that they have libraries with the same name
but for different versions on their machine. It is too easy to accidentally
link the wrong version that way as part of DLL hell. At least with versioned
toolsets, despite the PITA for the developer of maintaining their versions
as implementations get updated, linking and using them is foolproof.