From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-05-07 17:39:12
> Spirit dropped support for 'legacy' compilers a while back. However, a
> branch of the older version of the library is maintained (1.6, vs 1.8)
> and still tested against boost releases. Support is still available,
> but separately from the Spirit project, rather than through Boost
> itself. Robert Ramey shows how this support can be integrated as he
> relies on Spirit support in the Serialization library.
Note however that although it is not made available through the Boost
website, the 1.6 branch is actually maintained within the Boost CVS
repository. This is actually what got me started into thinking about
further bug fix/support enhancement only releases.
> uBlas made a similar choice to stop supporting inadequate compilers
> around 1.32 release. This is enforced with a #error, and there is no
> workaround. Generally, users of those platforms are left with a choice
> of dropping their use of the library, or no longer upgrading boost.
> And that problem gets worse when compiler vendors release upgrades that
> are still not supported! You are left with the choice where upgrading
> your compiler means losing Boost support.
That's the point. For us Borland users there's no way out: it's unlikely
that we can move on to 1.34 because many libraries don't support our
compilers anymore and we can only use older releases by applying local
patches, hoping we're not going to encounter any surprise. The worst of
it is that just about every Borland/Boost user is going through exactly
the same moves with few opportunities to share experiences and possibly
> Deprecating a platform boost-wide, rather than on a per-library basis,
> seems the best balance to me. I know which Boost version is stable and
> tested, I can rely on most libraries in that version, and library
> authors understand what is expected (but not required) of them. The
> all important recovery-action for the user is simple - install the
> version of Boost pointed at by the deprecation message.
I don't agree. This would work if all the library authors supported the
same set of compilers. As this is not the case there is no single
version of Boost that the deprecation message can reasonably refer to.
The real solution for this problem is something that Boost will have to
face sooner or later and that is breaking the distribution into a set of
more manageable elements.
> So far Boost has been a remarkably supportive community, especially the
> library maintainers who agreed to one more release to allow a
> deprecation warning. I think it is equally important we (legacy users)
> help them find ways to move on as well.
That's where a two phase evolution, with .0 releases providing the state
of the art and subsequent ones with more workarounds and possibly bug
fixes would prove effective. I am aware, however, that this would only
be realistic if someone actually volunteered to take on the necessary
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk