Re: [boost] Release Candidate Time

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-11 00:35:15

----- Original Message -----
From: "Douglas Gregor" <gregod_at_[hidden]>

> > I think the biggest hurdle is that we need some way for library authors
to
> > specify which platforms they intend to support, and for suppliers of
> > support for other platforms (when they are not the author) to do
likewise.
> >
> > -Dave
>
> I completely agree. Any ideas? The best I've thought of would be to
> standardize the build names that describe the compiler/platform, e.g.,
>   linux-2.4.17-gcc-3.0.3
>   winnt-msvc-6.0
>   freebsd-3.4-gcc-2.95.3
>
> and stick the build name into $(PLATFORM).
>
> Then we add an "expected-failure" rule to the regression testing system,
so
> that the author can do something like:
>
> switch $(PLATFORM)
> {
>   case freebsd-3,*: expected-failure wregress ;
>   case winnt-msvc-*: expected-failure lambda_test ;
> }
>
> Doesn't quite scale to multiple build names in a single Jam invocation,
> though :(.

The biggest problem I have with the approach is that it appears to assume
success as the default. Most developers have at most a few
compilers/platforms available, and can only reasonably support those to
which they have access. It actually seems to me that an expectation of
success or failure is orthogonal to supported-ness. For example, we can say
that type_traits supports MSVC6, but has many expected failures on that
platform.

I think the requirement for release should be that tests give the expected
results (for both successes and failures) on all platform/compiler
combinations supported by the corresponding library. Of course we'll test on
other platform/compiler combinations. A library supported over a reasonable
spectrum is likely to work in many more contexts than the supported ones.

-Dave