From: Jeff Garland (jeff_at_[hidden])
Date: 2006-01-31 01:12:27
On Mon, 30 Jan 2006 21:45:42 -0800, Thomas Witt wrote
> Jeff,
>
> Jeff Garland wrote:
> >
> > I like your breakdown although we might need another category like
> > 'experimental' to describe newer compilers that are partially supported or
> > might be supported in the future -- although maybe it's the same as
> unsupported.
>
> See below.
>
> >
> > Anyway, here's how I'd categorize the current set of compilers on the
> > regression page:
> >
> > Supported;
> > vc7.1
> > vc8.x
> > intel9_x
> > cw9_4
> > gcc3.x
> > gcc4.x
> > tru64cxx71-xx
>
> FWIW we just added QNX to this list.
QNX is a platform not a compiler. From what I understand the QNX 'qcc' is
essentially another form of gcc so that's included.
> >
> > Deprecated:
> > intel8_x
> > tru64cxx65-xx
> >
> > Unsupported:
> > borland 5_6_x
> > cw8_x
> > dmc
> > gcc2.95.x
> > sunpro
> > vc6
> > vc7
> >
> > I know -- that's a pretty aggressive cut in supported compilers, but I think
> > it's time to let boost developers focus on new libraries instead of porting.
>
> [WINDOWS-1252?]Hmm… our disagreement might be mostly about terminology.
First of
> all I was never really happy with the category names but I failed to
> find better ones.
>
> Thinking about it again. The reason might be that we have to deal
> with two different issues when we talk about compiler support. The
> easy part are outdated compilers. For those it's easy to say we
> don't care (that's basically the meaning of unsupported and also
> in some way for deprecated). The hard part are compilers that just
> aren't compliant enough to support all of boost without heroic
> efforts by library writers. This category of compilers is the reason
> for the weasel wording used to describe the fully supported
> category. The intend is to say we make a reasonable effort, document
> the limitations and provide regression tests until these compilers
> reach the unsupported stage due to obsoleteness.
Well sure, but I'm not sure what to do with a new compiler that just doesn't
cut it. Anyway, I think if we agree on the unsupported list the rest will
fall into place.
> As far as your list of unsupported compilers goes. I do feel
> uncomfortable with just dropping most of them without first
> deprecating them. This does not mean we should put effort into
> improving support for them 1.34 we just should not break them
> incidentally.
I understand, but that just means 1.34 will be delayed for fixes to these
outdated relics and new lousy compilers. We would be better making a clean
break now and letting folks with old compilers stick with 1.33.1.
> As far as sunpro goes I'd like to see that one in
> fully/partially supported.
Me too, and there was a message last week in the Sun forums that gives hope
that one day this may happen. But for now, the OSL4 sunpro cannot compile a
single boost lib. So until we see some sort of upgrade it's not reasonable to
expect us to even bother...
Jeff