From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-12-06 12:55:56
David Abrahams wrote:
>Brian Allison <brian_at_[hidden]> writes:
>
> > But how would it change anything? We don't "guarantee" anything
> > today, and I'm pretty sure we won't guarantee anything a year from now
> > either.
>
>The problem is that as you make it more precise, you also make it
>clear that it's not very meaningful. Even most compilers we'd
>consider to be "quite conformant" are not without their issues. So,
>I'd like to see some way of formulating this so that we can all
>understand what it really means for:
>
> users
> library developers
> testers
> (anyone I left out?)
Ok. Here goes...
== Users ==
There are two categories of users: (1) those who are supporting legacy code
bases that rely on or use old compilers (e.g. VC6); (2) those who are
flexible about what compiler they use and move to either the latest or
previous release of a compiler (e.g. VC7.1 and VC8).
The main compilers in question here (disregarding Borland for the moment)
are VC6 and GCC2.95.x. Now that MS have dropped support for VC6, should
Boost do the same? GCC2.95 is 2 generations old (GCC3 and GCC4 have been
released, with GCC3.0 being in the field for some time now). Given that, are
there any users that still require GCC2 support?
==> Therfore, it would be reasonable to officially support the most recent
version and the one previous.
The next question is what compiler vendors should be supported...
I think the most popular/used compilers for a platform should be supported:
1. GCC on Linux;
2. GCC and CodeWarrior on Mac;
3. GCC and VC on Windows.
I know that this is not a complete picture. Other compilers can be added
that are viewed as critical for a given platform. This then gives the core
set of compilers that need to be supported.
== Library Developers ==
Other compilers that are not on this list, but are reasonably conformant
(i.e. above 90%) should also be supported. Boost doesn't require a library
to support broken compilers, so motivation for support here would come from
users that target those compilers. The question then becomes how broken
should a compiler be before it is not supported. This is blurry and is
mainly up to the library developer and how much effort they are willing to
spend supporting those compilers [*].
[*] This effort is in terms of finding a workaround, testing that on the
target compiler and on other compilers to see if there aren't any
regressions. This can be difficult if you don't have access to the
compiler/version in question. This may mean cooperating with others in the
group who do have access to those compilers, although this can be difficult
if the library is in a state of flux and is changing from day-to-day
(synchronising effort between you and the Booster who is helping you).
== Testers ==
This is down to how many resources a tester can put into running the tests.
It takes a reasonable amount of time and hard drive space to run the
regression tests *per compiler, version and platform*. I know that this is
distributed across several testers, but there are only a few core testers
that run the tests frequently. It also costs money and effort to set up a
new compiler/version.
- Reece