How to handle name mangling in "versioned" toolsets?
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? Thanks, John.
"John Maddock" <john@johnmaddock.co.uk> writes:
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?
It seems to me that versioned mangling should only be neccessary where it indicates an ABI change, so indicating which version of the intel compiler you're using is pointless -- unless you want to consider ODR violations caused by verion-specific workarounds in header files? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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.
participants (3)
-
David Abrahams -
Edward Diener -
John Maddock