From: David Abrahams (dave_at_[hidden])
Date: 2003-08-23 06:51:01
Daryle Walker <dwalker07_at_[hidden]> writes:
>> That's a very nice way to avoid extra work for Boost library
>> developers which they shouldn't have to do in the first place, but
>> since RedHat isn't actually going to do anything for users, leaves
>> them in the cold.
> I don't think we support beta versions of compilers, so why should we
> support a version of a compiler that its creators (AFAIK) don't even
I'm not saying that we should. I'm saying that some of us will
anyway, and we shouldn't automatically tell 2.96 users with problems
to go away until the library maintainers have had a chance to decide
if they're going to try to fix the problem.
> For example, if a Boost incompatibility is the fault of the GCC 2.96
> complier, are we supposed to figure out the internal difficulties
> and corrections/workarounds that even GCC.org won't bother with?
We do that stuff all the time with vc6/7, Borland, gcc 2.95.x,
SunPro, HP, Intel 5/6...
The list goes on. Even when the compiler is current, the vendor is
often of no help finding a workaround.
> Anyway, support for certain compiler versions seem to fade as new
> versions are released (e.g. we don't really support CodeWarrior Pro
> 5.x or MSVC++ 5.x). Do we even support GCC 2.95 that much? The user
> can resolve the problem by downloading the 2.95 or 3.x versions, which
> gains the user a lot more support, especially if the resolution to a
> Boost incompatibility is beyond our ability to fix (like a compiler
Downloading and installing a new compiler for a linux system is beyond
the capacities, and sometimes the permissions, of many users.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk