From: AlisdairM (alisdair.meredith_at_[hidden])
Date: 2004-01-09 06:05:46
The question of how long Boost should support old compilers has been
raised a couple of times, and we are hitting a milestone in Boost 1.31
whether we know it or not!
As of release 1.8 Spirit will no longer support older compilers, such as
Borland or MSVC prior to 7.1. Boost 1.31 will include Spirit 1.8, so
Boosters using these compilers AND Spirit will face some interesting
i/ Upgrade compilers before upgrading to 1.31 (not always possible)
ii/ Upgrade to 1.31 and cut out Spirit
iii/Upgrade to 1.31 and separately download Spirit 1.62, replace Spirit
1.8 with Spirit 1.6.2
I believe the latter is the current recomendation from the Spirit team,
and 1.6.2 will be the maintenance release for these older compilers
(including support for new Boost Iterator Adaptors)
If you look at the MetaComm test results you will already see these
compilers fail all Spirit tests with a #error This Compiler Is Not
As a Borland user I am clearly less happy than most about this solution,
and therefore may not be entirely impartial in my own views <g>
Personally, I am don't like that code which compiled under Boost 1.30.2
will no longer be supported under 1.31. I can see the need for progress
(and this support was crippling Spirit development) but I don't like
losing the support that was present. I would like to see 1.6.2 bundled
as part of the Boost release.
There have been different views in Spirit on this, and I think given the
precedent being set it would be useful to get a wider Boost view on the
One solution is simply to bundle 1.6.2 in a separate folder as a further
part of the Boost release, and direct users to update their includes if
using an older compiler.
Another would be to do Loki-style redirection, where the compiler version
is tested in a forwarding header, and then include either the 1.8 or the
1.6.2 version. The forwarding logic could be as simple as detecting the
compiler version, or allow for other overrides such as forcing 1.8/1.6 on
some BOOST_ define.
The timing of this is also quite difficult given the current release. I
suspect there is no time to implement AND TEST forwarding if we are close
As one most likely affected by the change I am quite happy to implement
the forwarding, but only if it is the desire of Boost at large (and
endorsed by the Spirit team)
The related issue is how far Boost will support older compilers in the
future. If specific libraries are going to drop old compilers, it would
be nice to add a new feature to regression testing to simply say
'unsupported' rather than fail (eg: Borland on Lambda/Multi-array) Could
also speed up testing <g>
Do we have/need an official policy on this?
Do we want to follow some kind of 'deprecation' policy as has been used
on some libraries in the past?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk