[Boost Test] - MSVC 6.0 issue in recent HEAD
In preparing to upload some changes to the serialization library I updated my local tree and re-ran my tests. I'm getting a new kind of error with MSVC 6.0 - here it is. It looks to me that something has been improved in the test library beyond the point of functionality - at leaset as msvc 6.0 is concerned. Robert Ramey logged_expectations.cpp C:\BoostHead\boost/test/utils/named_params.hpp(269) : error C2989: 'typed_keyword<bool,T,0>' : template class has already been defined as a non-template class C:\BoostHead\boost/test/utils/named_params.hpp(269) : error C2988: unrecognizable template declaration/definition C:\BoostHead\boost/test/utils/foreach.hpp(353) : fatal error C1506: unrecoverable block scoping error
"Robert Ramey" <ramey@rrsd.com> wrote in message news:drlphn$1ka$1@sea.gmane.org...
In preparing to upload some changes to the serialization library I updated my local tree and re-ran my tests.
I'm getting a new kind of error with MSVC 6.0 - here it is. It looks to me [...]
Didn't we decide to drop ancient compilers? Gennadiy
Gennadiy Rozental wrote:
Didn't we decide to drop ancient compilers?
Not yet, but we never officially defined what it means to support a compiler either. There is certainly a growing feeling their time has come, but no definitive list yet. I have proposed deprecating MSVC6 and GCC2.95.3 in this release (1.34) so that users at least get some notice they are vanishing. I would then hope the compiler config would still detect these compilers, and #error with a message saying Boost 1.34 was the last supported version, so anyone trying to use them at least knows which old version of Boost to retrieve (and likewise, I recommend this for any formal deprecation policy we finally adopt) I am still waiting for the bun-fight over Borland support - as my employer relies on this compiler still and I am hard at work in my evenings working on a setup of updated workarounds for the new compiler released last month. -- AlisdairM
AlisdairM wrote:
Gennadiy Rozental wrote:
Didn't we decide to drop ancient compilers?
Not yet, but we never officially defined what it means to support a compiler either.
There is certainly a growing feeling their time has come, but no definitive list yet.
Microsoft have dropped all support for VC6 for some time now. Several Boost libraries (such as Spirit) have dropped support for this compiler.
I have proposed deprecating MSVC6 and GCC2.95.3 in this release (1.34) so that users at least get some notice they are vanishing. I would then hope the compiler config would still detect these compilers, and #error with a message saying Boost 1.34 was the last supported version, so anyone trying to use them at least knows which old version of Boost to retrieve (and likewise, I recommend this for any formal deprecation policy we finally adopt)
It may be useful if Boost.Config still detects the functionality for the compiler(s), so you could use it with, say, VC6 in your own project. A message would be better than an #error as you could still use components that still work with the older compilers. - Reece
"AlisdairM" <alisdair.meredith@uk.renaultf1.com> wrote in message news:drm1ec$34l$1@sea.gmane.org...
Gennadiy Rozental wrote:
Didn't we decide to drop ancient compilers?
Not yet, but we never officially defined what it means to support a compiler either.
Well, lets consider this a first big step in this direction. If we dont make this step at some point we will be stack where we are forever.
There is certainly a growing feeling their time has come, but no definitive list yet.
I have this feeling for several releases now. 7.1 may soon become depricated. I do not see any reason to still support 6.5. And if I will have time before the end of release cycle I will remove 2.95 workarounds either. Gennadiy
Gennadiy, I am not sure I do understand the issue at hand completely so I would appreciate to be corrected if my assumptions are wrong. Gennadiy Rozental wrote:
"AlisdairM" <alisdair.meredith@uk.renaultf1.com> wrote in message news:drm1ec$34l$1@sea.gmane.org...
Gennadiy Rozental wrote:
Didn't we decide to drop ancient compilers? Not yet, but we never officially defined what it means to support a compiler either.
Well, lets consider this a first big step in this direction. If we dont make this step at some point we will be stack where we are forever.
I can feel your pain but Boost.Test is probably the least suitable library to make any steps in this direction. At least for those parts that involve the boost regression testing. AFAICS we need to be able to run regression tests on VC6 for the foreseeable future.
There is certainly a growing feeling their time has come, but no definitive list yet.
I have this feeling for several releases now. 7.1 may soon become depricated.
I strongly disagree with this.
I do not see any reason to still support 6.5.
Well, what about: It is widely used?
And if I will have time before the end of release cycle I will remove 2.95 workarounds either.
Again I'd like to ask you to not make any changes that impair our ability to do regression testing on 2.95 Thanks Thomas -- Thomas Witt witt@acm.org
Didn't we decide to drop ancient compilers? Not yet, but we never officially defined what it means to support a compiler either.
Well, lets consider this a first big step in this direction. If we dont make this step at some point we will be stack where we are forever.
I can feel your pain but Boost.Test is probably the least suitable library to make any steps in this direction. At least for those parts that involve the boost regression testing. AFAICS we need to be able to run regression tests on VC6 for the foreseeable future.
Do we? I do not see any regression runs for this compiler for about a year now ( I think)
There is certainly a growing feeling their time has come, but no definitive list yet.
I have this feeling for several releases now. 7.1 may soon become depricated.
I strongly disagree with this.
Not that I insist, but: why?
I do not see any reason to still support 6.5.
Well, what about: It is widely used?
Is it? And I believe it's secondary point here. Anyone stuck with old compiler could use 1.33. release
And if I will have time before the end of release cycle I will remove 2.95 workarounds either.
Again I'd like to ask you to not make any changes that impair our ability to do regression testing on 2.95
Pre 3.0 gcc is the source of huge amount of clumsy workarounds. We should get away from it ASAP. Gennadiy
Gennadiy Rozental wrote:
I can feel your pain but Boost.Test is probably the least suitable library to make any steps in this direction. At least for those parts that involve the boost regression testing. AFAICS we need to be able to run regression tests on VC6 for the foreseeable future.
Do we? I do not see any regression runs for this compiler for about a year now ( I think)
Just to clarify if I say vc6 I mean VC 6.0 SP5. We do have regression tests for 1.33.1 on this platform. We do not currently have them for HEAD.
There is certainly a growing feeling their time has come, but no definitive list yet. I have this feeling for several releases now. 7.1 may soon become depricated. I strongly disagree with this.
Not that I insist, but: why?
Because its successor is only available for roughly two month now.
Again I'd like to ask you to not make any changes that impair our ability to do regression testing on 2.95
Pre 3.0 gcc is the source of huge amount of clumsy workarounds. We should get away from it ASAP.
I do agree that phasing out 2.95.3 is the way to go. I just think that infrastructure like e.g. Boost.Test and Boost.Config should be the last to drop support. Thomas -- Thomas Witt witt@acm.org
Gennadiy Rozental writes:
I can feel your pain but Boost.Test is probably the least suitable library to make any steps in this direction. At least for those parts that involve the boost regression testing. AFAICS we need to be able to run regression tests on VC6 for the foreseeable future.
Do we? I do not see any regression runs for this compiler for about a year now ( I think)
Huh? From http://www.boost.org/: December 5, 2005 - Version 1.33.1 Supported Compilers ... - Microsoft Visual C++ 6.0 (sp5, with and without STLport) -- Aleksey Gurtovoy MetaCommunications Engineering
participants (6)
-
Aleksey Gurtovoy -
AlisdairM -
Gennadiy Rozental -
Reece Dunn -
Robert Ramey -
Thomas Witt