[boost] Support for old compilers

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 
choices.

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 
Supported.

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 
issue.

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 
to releaase.  

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?

AlisdairM