Re: [boost] [Release 1.34] Supported Compilers

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