From: David Abrahams (dave_at_[hidden])
Date: 2006-09-20 11:55:03
"John Maddock" <john_at_[hidden]> writes:
> David Abrahams wrote:
>>> I believe the rationale for not versioning the intel toolset, is
>>> that what matters is the msvc compiler targeted, not the intel
>>> compiler version as far as binary compatibility is concerned, so
>>> basically bbv1 chickened out of versioning the toolset names, and
>>> the auto-link code followed.
>> Except that libraries may have #ifdefs that change their ABIs based on
>> which compiler/version is being used. I think you need the toolset
>> name in there.
> By toolset name you mean the intel version number I presume, since the name
> "iw" is already in there.
> But probably the ABI will change more based on
> _MSC_VER than it will based on INTEL_VERSION ?
ABI of the compiler? Probably that won't change, because MS and Intel
don't want to break binary compatibility, but yes, _MSC_VER would be
the key in that case.
The ABI of libraries is more likely to be altered based on the primary
compiler version (Intel in this case), which is what I'm talking about.
> If we can come up with a better scheme I'm all in favour, but it's not
> obvious to me what it should be or how we get Boost.Build and the auto-link
> code to always do the same thing when Boost.Build doesn't really know what
> the compiler version is (just what the toolset name is).
FWIW, we can start determining the compiler version more accurately.
If you look at tools/build/v2/tools/python.jam you'll see that I added
some code to do autoconf-like steps with Python. We should be doing
the same with all the compilers.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk