[report][autolink] conflicts with new toolset names
Excuse my being a little insistent on this,but I think the problem should be addressed one way or another, as it's causing tons of regressions. I've prepared a patch for tools/build/v1/boost-base.jam (attached). Is it OK to commit? Original message: autolink assumes the following toolset tags for libraries generated under the MSVC familiy of compilers: 6.0, 6.5 --> "v6" 7.0 --> "vc7" 7.1 --> "vc71" 8.0 --> "vc80" Yet tools/build/v1/boost-base.jam does the following: local include-minor-version = YES ; switch $(toolset) { case borland* : toolset-tag += bcb ; case como* : toolset-tag += como ; case cwpro8* : toolset-tag += cw 8 ; case cwpro9* : toolset-tag += cw 9 ; case cw-* : toolset-tag += cw ; include-minor-version = ; case darwin* : toolset-tag += ; case edg* : toolset-tag += edg ; case gcc* : toolset-tag += gcc ; case intel-linux* : toolset-tag += il ; case intel-win32* : toolset-tag += iw ; case kcc* : toolset-tag += kcc ; case kylix* : toolset-tag += bck ; case metrowerks* : toolset-tag += cw ; case mingw* : toolset-tag += mgw ; case mipspro* : toolset-tag += mp ; case msvc* : toolset-tag += vc 6 ; case sunpro* : toolset-tag += sw ; case tru64cxx* : toolset-tag += tru ; case vacpp* : toolset-tag += xlc ; case vc[678][_]* : { toolset-tag += vc ; toolset-tag += [ MATCH "vc([678])[_]([0123456789]*)" : $(toolset) ] ; } case vc[678]* : { toolset-tag += vc ; toolset-tag += [ MATCH "vc([678])" : $(toolset) ] ; } case * : toolset-tag += [ MATCH "^([^-]*)" : $(toolset) ] ; } if $(include-minor-version) { toolset-tag += [ MATCH "[-]([0123456789]+)[_.]([0123456789]*)" : $(toolset) ] ; } else { toolset-tag += [ MATCH "[-]([0123456789]+)[_.][0123456789]*" : $(toolset) ] ; } which does not match autolink expectations for the following toolsets adhering to the new naming conventions: vc-6_5 --> vc65 (expected vc6) vc-7_0 --> vc70 (expected v7) I guess it suffices to apply the following postrule in boost-base.jam switch $(toolset-tag) { case vc6* : toolset-tag = vc6 ; case vc70 : toolset-tag = vc7 ; } but someone more acquainted with bjam than me might come up with a nicer reformulation. Currently, this is breaking dozens of tests in the metacomm engine, which recently switched to vc-6_5-stlport and vc-7_0 toolsets. Do I commit this? Someone can tackle the issue more elegantly? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 2672a2673,2681
# boost/config/auto_link.hpp expects toolset tags that do not always # match the above algorithm for MSVC 6.x and 7.0. # switch $(toolset-tag) { case vc6* : toolset-tag = vc 6 ; case vc70 : toolset-tag = vc 7 ; }
Excuse my being a little insistent on this,but I think the problem should be addressed one way or another, as it's causing tons of regressions. I've prepared a patch for tools/build/v1/boost-base.jam (attached). Is it OK to commit?
There is a simpler (temporary) fix, which is to add <define>BOOST_ALL_NO_LIB=1 to those new toolsets. But in principle I agree with your fix (especially if it works!), Rene Rivera is responsible for that code however, and the best person to check with. John.
Original message:
autolink assumes the following toolset tags for libraries generated under the MSVC familiy of compilers:
6.0, 6.5 --> "v6" 7.0 --> "vc7" 7.1 --> "vc71" 8.0 --> "vc80"
Yet tools/build/v1/boost-base.jam does the following:
local include-minor-version = YES ; switch $(toolset) { case borland* : toolset-tag += bcb ; case como* : toolset-tag += como ; case cwpro8* : toolset-tag += cw 8 ; case cwpro9* : toolset-tag += cw 9 ; case cw-* : toolset-tag += cw ; include-minor-version = ; case darwin* : toolset-tag += ; case edg* : toolset-tag += edg ; case gcc* : toolset-tag += gcc ; case intel-linux* : toolset-tag += il ; case intel-win32* : toolset-tag += iw ; case kcc* : toolset-tag += kcc ; case kylix* : toolset-tag += bck ; case metrowerks* : toolset-tag += cw ; case mingw* : toolset-tag += mgw ; case mipspro* : toolset-tag += mp ; case msvc* : toolset-tag += vc 6 ; case sunpro* : toolset-tag += sw ; case tru64cxx* : toolset-tag += tru ; case vacpp* : toolset-tag += xlc ; case vc[678][_]* : { toolset-tag += vc ; toolset-tag += [ MATCH "vc([678])[_]([0123456789]*)" : $(toolset) ] ; } case vc[678]* : { toolset-tag += vc ; toolset-tag += [ MATCH "vc([678])" : $(toolset) ] ; } case * : toolset-tag += [ MATCH "^([^-]*)" : $(toolset) ] ; } if $(include-minor-version) { toolset-tag += [ MATCH "[-]([0123456789]+)[_.]([0123456789]*)" : $(toolset) ] ; } else { toolset-tag += [ MATCH "[-]([0123456789]+)[_.][0123456789]*"
: $(toolset) ] ; }
which does not match autolink expectations for the following toolsets adhering to the new naming conventions:
vc-6_5 --> vc65 (expected vc6) vc-7_0 --> vc70 (expected v7)
I guess it suffices to apply the following postrule in boost-base.jam
switch $(toolset-tag) { case vc6* : toolset-tag = vc6 ; case vc70 : toolset-tag = vc7 ; }
but someone more acquainted with bjam than me might come up with a nicer reformulation.
Currently, this is breaking dozens of tests in the metacomm engine, which recently switched to vc-6_5-stlport and vc-7_0 toolsets.
Do I commit this? Someone can tackle the issue more elegantly? Thank you,
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
--------------------------------------------------------------------------------
2672a2673,2681
# boost/config/auto_link.hpp expects toolset tags that do not always # match the above algorithm for MSVC 6.x and 7.0. # switch $(toolset-tag) { case vc6* : toolset-tag = vc 6 ; case vc70 : toolset-tag = vc 7 ; }
--------------------------------------------------------------------------------
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"John Maddock" <john@johnmaddock.co.uk> writes:
Excuse my being a little insistent on this,but I think the problem should be addressed one way or another, as it's causing tons of regressions. I've prepared a patch for tools/build/v1/boost-base.jam (attached). Is it OK to commit?
There is a simpler (temporary) fix, which is to add <define>BOOST_ALL_NO_LIB=1 to those new toolsets.
But in principle I agree with your fix (especially if it works!), Rene Rivera is responsible for that code however, and the best person to check with.
Right. And Rene will be on vacation until the 18th. I say check it in and be prepared to back it out if anything implodes or Rene objects. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Jun 14, 2005, at 11:03 AM, David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
Excuse my being a little insistent on this,but I think the problem should be addressed one way or another, as it's causing tons of regressions. I've prepared a patch for tools/build/v1/boost-base.jam (attached). Is it OK to commit?
There is a simpler (temporary) fix, which is to add <define>BOOST_ALL_NO_LIB=1 to those new toolsets.
But in principle I agree with your fix (especially if it works!), Rene Rivera is responsible for that code however, and the best person to check with.
Right. And Rene will be on vacation until the 18th.
I say check it in and be prepared to back it out if anything implodes or Rene objects.
Agreed. We need to get these regressions under control if we're going to get 1.33.0 any time soon. Doug
participants (4)
-
David Abrahams -
Doug Gregor -
Joaquín Mª López Muñoz -
John Maddock