borland-5.6.4, auo_link and common-names (v1)
The boost/build/v1 common-names rule computes a toolset name of "bcb56" when using borland-5.6.4-tools. The boost/config/auto_link.hpp file does not discriminate between bcb5.5 and bcb5.6, using "bcb". Auto link therefore fails. I have made the following local fix to auto_link.hpp, since to me the common-names toolset name computation seems to be self-consist across toolsets. Whould it be possible to fix either auto_link.hpp or the boost build v1 common-names rule - whichever makes more sense. Thanks Hugo Index: auto_link.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/auto_link.hpp,v retrieving revision 1.9 diff -u -r1.9 auto_link.hpp --- auto_link.hpp 21 Jan 2004 11:54:55 -0000 1.9 +++ auto_link.hpp 22 Mar 2004 14:09:39 -0000 @@ -120,9 +120,14 @@ // vc71: # define BOOST_LIB_TOOLSET "vc71" -#elif defined(__BORLANDC__) +#elif defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) // CBuilder 6: +# define BOOST_LIB_TOOLSET "bcb56" + +#elif defined(__BORLANDC__) + + // BCB: # define BOOST_LIB_TOOLSET "bcb" #elif defined(__ICL)
Hugo Duncan wrote:
The boost/build/v1 common-names rule computes a toolset name of "bcb56" when using borland-5.6.4-tools. The boost/config/auto_link.hpp file does not discriminate between bcb5.5 and bcb5.6, using "bcb". Auto link therefore fails.
I have made the following local fix to auto_link.hpp, since to me the common-names toolset name computation seems to be self-consist across toolsets.
Whould it be possible to fix either auto_link.hpp or the boost build v1 common-names rule - whichever makes more sense.
I would think the auto link needs fixing, as you suggest. Otherwise it would not be possible to test with different versions of borland on the same machine. But there is a problem in that if someone uses the regular borland toolset against a 5.6 install the autolink would then fail as it would have bcb56, but the raw toolset would produce bcb. Don't know how to solve that problem though :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera <grafik.list@redshift-software.com> wrote:
But there is a problem in that if someone uses the regular borland toolset against a 5.6 install the autolink would then fail as it would have bcb56, but the raw toolset would produce bcb. Don't know how to solve that problem though :-(
Doesn't the same problem exist if you use vc7.1 with the msvc toolset? Or to paraphrase the qustion, is a toolset per version the "intended" way of using bjam?
Hugo Duncan <hugoduncan@users.sourceforge.net> writes:
Rene Rivera <grafik.list@redshift-software.com> wrote:
But there is a problem in that if someone uses the regular borland toolset against a 5.6 install the autolink would then fail as it would have bcb56, but the raw toolset would produce bcb. Don't know how to solve that problem though :-(
Doesn't the same problem exist if you use vc7.1 with the msvc toolset? Or to paraphrase the qustion, is a toolset per version the "intended" way of using bjam?
That part of BBv1 evolved without sufficient intention. Right now, it's the only way in BBv1. BBv2 is much better about that. IIUC there's only a small list of tasks remaining before we can switch to BBv2. I think we'll need more people than just Vladimir (despite his laudable efforts) to put attention on it if we want that to happen soon. -- Dave Abrahams Boost Consulting www.boost-consulting.com
The boost/build/v1 common-names rule computes a toolset name of "bcb56" when using borland-5.6.4-tools. The boost/config/auto_link.hpp file does not discriminate between bcb5.5 and bcb5.6, using "bcb". Auto link therefore fails.
It was done deliberately that way, because historically we've only had one Borland toolset, so the names were not versioned.
I have made the following local fix to auto_link.hpp, since to me the common-names toolset name computation seems to be self-consist across toolsets.
Whould it be possible to fix either auto_link.hpp or the boost build v1 common-names rule - whichever makes more sense.
What we really need to do before the next major release, is figure out how to get the compiler version into bjam so that the name mangling doesn't depend upon the toolset name, that way the bjam names and the auto_link names could always be in synch, Rene? John.
"John Maddock" <john@johnmaddock.co.uk> writes:
What we really need to do before the next major release, is figure out how to get the compiler version into bjam so that the name mangling doesn't depend upon the toolset name, that way the bjam names and the auto_link names could always be in synch, Rene?
IMO it's time, instead, to make the final push to move to BBv2, which uses the same toolset for all versions of a compiler. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
What we really need to do before the next major release, is figure out how to get the compiler version into bjam so that the name mangling doesn't depend upon the toolset name, that way the bjam names and the auto_link names could always be in synch, Rene?
IMO it's time, instead, to make the final push to move to BBv2, which uses the same toolset for all versions of a compiler.
I agree with that... I'll get back to doing some v2 work after we get the BuildBot system running ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
The boost/build/v1 common-names rule computes a toolset name of "bcb56" when using borland-5.6.4-tools. The boost/config/auto_link.hpp file does not discriminate between bcb5.5 and bcb5.6, using "bcb". Auto link therefore fails.
It was done deliberately that way, because historically we've only had one Borland toolset, so the names were not versioned.
I have made the following local fix to auto_link.hpp, since to me the common-names toolset name computation seems to be self-consist across toolsets.
Whould it be possible to fix either auto_link.hpp or the boost build v1 common-names rule - whichever makes more sense.
What we really need to do before the next major release, is figure out how to get the compiler version into bjam so that the name mangling doesn't depend upon the toolset name, that way the bjam names and the auto_link names could always be in synch, Rene? John.
participants (4)
-
David Abrahams -
Hugo Duncan -
John Maddock -
Rene Rivera