[test] VC6.5 no longer supported?
Hello, As of Jan 28, the CVS version of Boost.Test has some commits labeled "VC6.0 workaround removed", which, expectedly enough, cause some of Boost.Test facilities to fail for that compiler-- for instance, including <boost/test/included/test_exec_monitor.hpp> no longer works in VC 6.5. Let me say in advance that I fully respect Gennadiy's decisions on which compilers he chooses Boost.Test should have support for, but I'd like to make sure before deciding on switching my current test framework, so my question is: is this a conscious decision and VC6.5 won't be supported by Boost.Test from now on, or, on the contrary, is this a transient state and VC 6.0 will be finally supported by Boost.Test 1.34? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Let me say in advance that I fully respect Gennadiy's decisions on which
compilers he chooses Boost.Test should have support for, but I'd like to
make sure before deciding on switching my current test framework, so my question is: is this a conscious decision and VC6.5 won't be supported by Boost.Test from now on, or, on the contrary, is this a transient state and VC 6.0 will be finally supported by Boost.Test 1.34?
This was the plan. It's still unclear at the moment. Depending what the community decide. I personally prefer to get rid of ancient compilers support and anyone interested in msvc 6.5 could use boost 1.33.1. But we may decide to just deprecate it in this release and get rid of it later. Or may keep it forever. Check "supported compilers" discussion. Let us know your opinion on this top in general. Gennadiy
On Feb 2, 2006, at 11:03 AM, Joaquín Mª López Muñoz wrote:
Let me say in advance that I fully respect Gennadiy's decisions on which
compilers he chooses Boost.Test should have support for, but I'd like to
make sure before deciding on switching my current test framework, so my question is: is this a conscious decision and VC6.5 won't be supported by Boost.Test from now on, or, on the contrary, is this a transient state and VC 6.0 will be finally supported by Boost.Test 1.34?
We definitely need to know what's happening here. If Boost.Test is going to drop VC6 support, that's fine, but we need to know sooner rather than later. I have several libraries that will need to move to another testing infrastructure if Boost.Test drops support for older compilers. Doug
On Thu, 2 Feb 2006 12:29:43 -0500 Douglas Gregor <doug.gregor@gmail.com> wrote:
We definitely need to know what's happening here. If Boost.Test is going to drop VC6 support, that's fine, but we need to know sooner rather than later. I have several libraries that will need to move to
another testing infrastructure if Boost.Test drops support for older compilers.
I've been advocating for dropping ancient compilers for a while. However, I think we should NOT just drop a compiler without notification for at least one release cycle. If we are sure we want to drop a compiler, decide on it now and deprecate it for 1.34, then you can drop it in a subsequent release.
Jody Hagins wrote:
On Thu, 2 Feb 2006 12:29:43 -0500 Douglas Gregor <doug.gregor@gmail.com> wrote:
We definitely need to know what's happening here. If Boost.Test is going to drop VC6 support, that's fine, but we need to know sooner rather than later. I have several libraries that will need to move to
another testing infrastructure if Boost.Test drops support for older compilers.
I've been advocating for dropping ancient compilers for a while. However, I think we should NOT just drop a compiler without notification for at least one release cycle.
If we are sure we want to drop a compiler, decide on it now and deprecate it for 1.34, then you can drop it in a subsequent release.
Please do not drop msvc6sp5 yet. I need it still. Upgrading my compiler is not an option at this time as I have applications I need to continue supporting which would break with visual studio.net and cause me a lot of grief and headaches not to mention lots of work.
If we are sure we want to drop a compiler, decide on it now and deprecate it for 1.34, then you can drop it in a subsequent release.
Please do not drop msvc6sp5 yet. I need it still. Upgrading my compiler is not an option at this time as I have applications I need to continue supporting which would break with visual studio.net and cause me a lot of grief and headaches not to mention lots of work.
You could continue supporting msvc 6.5 for existent application without upgrading boost. 1.33.1 version of Boost.Test supports msvc6.5. Gennadiy
We definitely need to know what's happening here. If Boost.Test is going to drop VC6 support, that's fine, but we need to know sooner rather than later. I have several libraries that will need to move to another testing infrastructure if Boost.Test drops support for older compilers.
You need support for msvc 6.5? Could you please clarify in more details please. Gennadiy
We definitely need to know what's happening here. If Boost.Test is going to drop VC6 support, that's fine, but we need to know sooner rather than later. I have several libraries that will need to move to another testing infrastructure if Boost.Test drops support for older compilers.
That's the crux of things isn't it? If Boost.Test drops support for older compilers then none of us can test our libraries with those compilers unless we reinvent Boost.Test like functionality. Again I'd like add that I'd like this support retained, even if it's just minimal legacy support (forwarding to a bunch of VC6 specific headers that don't get any new functionality or bug fixes). John.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:013901c6282d$4dd8a1c0$4feb0352@fuji...
We definitely need to know what's happening here. If Boost.Test is going to drop VC6 support, that's fine, but we need to know sooner rather than later. I have several libraries that will need to move to another testing infrastructure if Boost.Test drops support for older compilers.
That's the crux of things isn't it? If Boost.Test drops support for older compilers then none of us can test our libraries with those compilers unless we reinvent Boost.Test like functionality. Again I'd like add that I'd like this support retained, even if it's just
Ok Lets spell it out. 1. Which compiler should be considerred old/depricated/half supported? 2. What kind of minimal support is assumed? 3. Is there a timeframe where this situation will stay like this: essencially how longer there will be at least one Boost developer interestd in running test on one of the compilers mentioned in 1. 4. Until compiler is completely dropped it's required that somebody will run regression tests for this compiler. Otherwise how would I know this configuration still works. So who is gonna run regression tests for compilers specified in 1? Once these point cleared I a mhfully ready to comply with the plan.
minimal legacy support (forwarding to a bunch of VC6 specific headers that don't get any new functionality or bug fixes).
Why dont you do it yourself? Just point onto installed 1.33.1 Location when you want to test against dropped compiler?
John.
Gennadiy
Hello Gennadiy, Gennadiy Rozental ha escrito:
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:013901c6282d$4dd8a1c0$4feb0352@fuji...
We definitely need to know what's happening here. If Boost.Test is going to drop VC6 support, that's fine, but we need to know sooner rather than later. I have several libraries that will need to move to another testing infrastructure if Boost.Test drops support for older compilers.
That's the crux of things isn't it? If Boost.Test drops support for older compilers then none of us can test our libraries with those compilers unless we reinvent Boost.Test like functionality. Again I'd like add that I'd like this support retained, even if it's just
Ok Lets spell it out.
1. Which compiler should be considerred old/depricated/half supported?
Discussion has centered around VC6.5, BCB and GCC2.95. Your recent workaround removals seem to only affect VC6.5, so this is probably the only compiler relevant wrt to Boost.Test support-dropping policy.
2. What kind of minimal support is assumed?
I'd say, enough not to break any current tests in the regression engines that rely on Boost.Test (except, possibly, those of Boost.Test itself.) A stronger requirement is: support at least every feature available in Boost 1.33 (so, this does not include new features to be introduced in Boost 1.34.)
3. Is there a timeframe where this situation will stay like this: essencially how longer there will be at least one Boost developer interestd in running test on one of the compilers mentioned in 1.
I will be in the foreseeable future, but then again the decision of how Boost.Test should evolve is yours. I don't want to interfere with your planned roadmap, but I must know if I can rely on Boost.Test/VC6.5 right now, because feature freeze is approaching and if you drop support several libs (not only mine) will have to switch their test framework immediately. Let's say: What about restoring VC6.5 support for Boost 1.34, and dropping it, if this is your wish, right after the release (properly announcing the event, etc.)? This will give people several months to adapt, not several days like it is currently the case.
4. Until compiler is completely dropped it's required that somebody will run regression tests for this compiler. Otherwise how would I know this configuration still works. So who is gonna run regression tests for compilers specified in 1?
Hopefully, Aleksey is going to restore support for VC (and possibly BCB), see http://lists.boost.org/Archives/boost/2006/01/99844.php GCC 2.95 us currently being tested.
Once these point cleared I a mhfully ready to comply with the plan.
minimal legacy support (forwarding to a bunch of VC6 specific headers that don't get any new functionality or bug fixes).
Why dont you do it yourself? Just point onto installed 1.33.1 Location when you want to test against dropped compiler?
Unfortunately, this is not possible for the scenario John and others face, namely regression testing their Boost libs: We cannot possibly mandate that regression testers keep a 1.33.1 package installed and properly forwarded to run some of the 1.34 tests. My personal opinion on the issue of Boost.Test quitting supporting older compilers is the following: Currently, many (possibly most) Boost libs are using Boost.Test for regression testing purposes. This is admittedly a very primitive usage scenario, considering the amount of functionality the lib provides (reporting, unit testing, fixtures, etc.), but it is a good advertising window for Boost.Test, and looks like the "natural" thing to do: after all, people peek test code and are likely to learn by example from it, so it's good that they see Boost.Test in action. Now, if you drop support for VC6.5 and other oldies, and are *not* the last in abandon that ship (and right now you aren't the last), more and more Boost libs will change to something other than Boost.Test, most likely to boost/detail/lightweight_test.hpp, which wasn't designed for public consumption in the first place. Users could be drawn then to think: "what's the deal about Boost.Test if Boost authors themselves don't use it?". And this is in direct contrast with your own words in Boost.Test docs (quote follows): "Because the Boost Test Library is critical for porting and testing Boost libraries, it has been written to be extremely conservative in its use of C++ features, and to keep dependencies to a bare minimum." But of course, one must evolve and you don't want to be tied up by the restrictions these old compilers impose. How to resolve the dilemma? I'd say: after 1.34, review the usage of Boost.Test by Boost regression tests (or make a poll about it), try to isolate this functionality into a maximally portable component, ask Boost authors to move to that in time for Boost 1.35 and strive to keep that minimal part as untouched as possible in the future. This way Boost.Test would deliver: 1. Maximal portability for basic testing. AND 2. Advanced testing functionality for compliant compilers. So, you can have your cake and eat it :)
John.
Gennadiy
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
1. Which compiler should be considerred old/depricated/half supported?
Discussion has centered around VC6.5, BCB and GCC2.95. Your recent workaround removals seem to only affect VC6.5, so this is probably the only compiler relevant wrt to Boost.Test support-dropping policy.
Actually all of them are subject to be deprecated/non supported.
Now, if you drop support for VC6.5 and other oldies, and are *not* the last in abandon that ship (and right now you aren't the last),
I sitll couldn't understand what you all doing there.
"Because the Boost Test Library is critical for porting and testing Boost libraries, it has been written to be extremely conservative in its use of C++ features, and to keep dependencies to a bare minimum."
It's still true, comparatively speaking. Ok. Here is what I think I will do. Starting release 1.34 Boost.Test *officially* stop supporting VC 6.5, GCC2.95 and old Borland. Unofficially Boost.Test is required to make sure that none of the test that are included in Boost regression testing are not failing due to failure in Boost.Test. If regression testing is dropped for any of above compilers it means that Boost.Test is not bound by any requirements anymore. How does this sound? Gennadiy
Gennadiy Rozental wrote:
1. Which compiler should be considerred old/depricated/half supported?
Discussion has centered around VC6.5, BCB and GCC2.95. Your recent workaround removals seem to only affect VC6.5, so this is probably the only compiler relevant wrt to Boost.Test support-dropping policy.
Actually all of them are subject to be deprecated/non supported.
Now, if you drop support for VC6.5 and other oldies, and are *not* the last in abandon that ship (and right now you aren't the last),
I sitll couldn't understand what you all doing there.
"Because the Boost Test Library is critical for porting and testing Boost libraries, it has been written to be extremely conservative in its use of C++ features, and to keep dependencies to a bare minimum."
It's still true, comparatively speaking.
Ok. Here is what I think I will do.
Starting release 1.34 Boost.Test *officially* stop supporting VC 6.5, GCC2.95 and old Borland. Unofficially Boost.Test is required to make sure that none of the test that are included in Boost regression testing are not failing due to failure in Boost.Test. If regression testing is dropped for any of above compilers it means that Boost.Test is not bound by any requirements anymore.
How does this sound?
Gennadiy
It sounds like I and many other people are going to have to stop using boost as many of us are still tied to this compiler whether we like it or not. We do not all have a choice as to what compiler we can use. We must make do with what we have.
Richard V. Day wrote:
It sounds like I and many other people are going to have to stop using boost as many of us are still tied to this compiler whether we like it or not. We do not all have a choice as to what compiler we can use. We must make do with what we have.
You can still use Boost 1.33.1. The older versions won't suddenly stop supporting the older compilers. - Reece
It sounds like I and many other people are going to have to stop using boost as many of us are still tied to this compiler whether we like it or not. We do not all have a choice as to what compiler we can use. We must make do with what we have.
It looks like you safe. At least until boost doesn't stop running regression test got these compilers. Don't expect though any new features to work. Gennadiy
"Richard V. Day" <richardvday@verizon.net> writes:
It sounds like I and many other people are going to have to stop using boost as many of us are still tied to this compiler whether we like it or not. We do not all have a choice as to what compiler we can use. We must make do with what we have.
It is true that programmers targeting embedded platforms (such as the SH4) don't have a choice about upgrading. I can think of at least one company that might accept support contracts to keep Boost viable with vc6.5. The only question in my mind is whether library maintainers would accept the patches or the company would have to maintain a fork. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
I can think of at least one company that might accept support contracts to keep Boost viable with vc6.5. The only question in my mind is whether library maintainers would accept the patches or the company would have to maintain a fork.
Patches are not always practical. For example if you want to support a compiler that does not provide namespaces. The workarounds impact the interface. ACE/TAO, for example, have forked open source versions supported commercially. Enhancements and bug fixes are rolled forward into the cutting edge 'head' versions. This arrangement has worked successfully for many years. And yes I know a commercial company that is willing to accept support contracts to keep Boost viable with vc6.5. The commercial companies provide support for those that need to stay put on old compilers while allowing the community to move forward more rapidly. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
On Sat, 04 Feb 2006 23:51:53 -0500, David Abrahams wrote
"Richard V. Day" <richardvday@verizon.net> writes:
It sounds like I and many other people are going to have to stop using boost as many of us are still tied to this compiler whether we like it or not. We do not all have a choice as to what compiler we can use. We must make do with what we have.
As has been pointed out you can use everything in boost up to 1.33.1 -- it's just that you won't have access to the very latest boost versions. One part of the dynamic here is that many of the VC6 projects using boost now won't upgrade boost anyway because of the fear of breaking something -- it's the same argument that keeps them using VC6. If there's really some new library that is critical for their future, then these projects can work with developer or try to back-port for their own use.
It is true that programmers targeting embedded platforms (such as the SH4) don't have a choice about upgrading.
I can think of at least one company that might accept support contracts to keep Boost viable with vc6.5. The only question in my mind is whether library maintainers would accept the patches or the company would have to maintain a fork.
I think a fork or perhaps an 'official' branch with commercial support is good solution. I don't think alot of open source projects will be impacted by dropping vc6 support. If commercial enterprises want to band together to extend support then that's their right and choice. Sharing back with the community is to their advantage, so we should support it -- as long as it doesn't detract from pushing boost forward into the future. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
I think a fork or perhaps an 'official' branch with commercial support
Are those distinct things?
is good solution.
It sounds really confusing to me. Users will wonder if the "official" boost release is... the "official" branch that has the backing of commercial support, or... the one that's on the main trunk and is "supported" by boost.org
I don't think alot of open source projects will be impacted by dropping vc6 support. If commercial enterprises want to band together to extend support then that's their right and choice. Sharing back with the community is to their advantage, so we should support it -- as long as it doesn't detract from pushing boost forward into the future.
I guess allowing it to sit in the CVS on a branch would be nice, but I don't think it really amounts to "support..." unless you had something else in mind (?) -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sun, 05 Feb 2006 12:58:29 -0500, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
I think a fork or perhaps an 'official' branch with commercial support
Are those distinct things?
Yes. A fork would be an externally maintained distribution -- ala the Debian verions of boost -- a branch would be in the main Boost repository. Either/both can be done.
is good solution.
It sounds really confusing to me. Users will wonder if the "official" boost release is... the "official" branch that has the backing of commercial support, or... the one that's on the main trunk and is "supported" by boost.org
Sorry to confuse -- hopefully the above clears it up.
I don't think alot of open source projects will be impacted by dropping vc6 support. If commercial enterprises want to band together to extend support then that's their right and choice. Sharing back with the community is to their advantage, so we should support it -- as long as it doesn't detract from pushing boost forward into the future.
I guess allowing it to sit in the CVS on a branch would be nice, but I don't think it really amounts to "support..." unless you had something else in mind (?)
Not by itself, but it would be of some value to some members of the community. The 'support' would be answering questions and making fixes and releases on that branch. Jeff
participants (10)
-
David Abrahams -
Douglas Gregor -
Gennadiy Rozental -
Jeff Garland -
Joaquín Mª López Muñoz -
Jody Hagins -
John Maddock -
Kevin Heifner -
Reece Dunn -
Richard V. Day