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