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 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
> 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.
> 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
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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk