Re: [boost] [test] VC6.5 no longer supported?

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2006-02-03 09:36:21

Hello Gennadiy,

Gennadiy Rozental ha escrito:

> "John Maddock" <john_at_[hidden]> wrote in message
> news:013901c6282d$4dd8a1c0$4feb0352_at_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