Re: [boost] Support for old compilers

From: Martin Wille (mw8329_at_[hidden])
Date: 2004-01-09 10:00:09

AlisdairM wrote:

> 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

"replacing" is as simple as specifying a different #include search
path. Just put Spirit 1.6 before Boost 1.31.

> 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)

Yes, that is the plan.

[...]
> 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.

This would also make sense to me. However, when this was discussed the
last time, the majority of the participants in the thread thought
it wouldn't be a good idea to ship Spirit 1.6 as additional part
of Boost 1.31.

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

I agree.

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

Yes, that is what I would suggest to do, at least for a transitional
phase (i.e. we probably shouldn't ship Spirit 1.6 with Boost 1.32.
But what would be the rule to use to decide when to ship an old
version or not?).

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

I have objections to this approach. If you have a code base that will
be used with old compilers then you'll have to use Spirit 1.6.
Obviously, you then can only used 1.6 features in your code, i.e. your
code will depend on 1.6. Diverting to a newer version of Spirit when a
newer compiler is detected won't help you, since you're still bound to
the 1.6. feature set. So why not simply use Spirit 1.6 without
diversion (this is independent from whether Spirit 1.6 is shipped with
Boost 1.31 or not)?

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

Testing would indeed become an issue. There would be 3 times
as much to test: Spirit 1.6, Spirit 1.8 and the diversion code.
(for me this would mean to wait at least another two hours
until a test-run is completed.)

Another issue is documentation. It would also have to be doubled
or even tripled or completely reorganized.

[...]
> 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>

We actually have that in the XSL-based reports (e.g.
http://tinyurl.com/36peo ). It would be helpful to have it
in Boost.Build, too.

Regards,
m