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