Nicola Musatti wrote:
One thing I do feel strongly about: no matter how broken a library is with a specific compiler, deprecation advertising should entail a warning and not an error.
This would make it more easy to un-deprecate a platform when it starts supporting the required constructs and enables library authors to accept platform specific patches on a discretionary basis. Moreover even if such patches were not submitted/accepted developers would be free to try and use those portions of a library that do work on their platform.
It would also make it possible to accept platform specific patches against previous releases of Boost and maybe even allow more bugfix releases, should anybody volunteer to perform the necessary tasks.
A concrete example: I'm using Borland's BCB6 at work and we're stuck with Boost 1.31 because we're using uBlas, which doesn't support my compiler in more recent releases. Now I happen to know that 1.32 "almost" works and that someone has the necessary patches. Accepting these to be committed against the 1.32 branch would enable all those in my situation to at least move forward one release (I happen to know that there are at least two of us - right, Russell? :-).
Further to the ublas patches, I'd also like to look at back-porting your bcbboost work to the 1.32 branch which would enable us to possibly move to BDS2006 with boost-1.32.x. But at the moment, like you, we are stuck on BCB6 and boost-1.32.0 with our ublas patches until Borland releases a compiler that can handle the later versions (which I don't see happening anytime soon given that BDS has only just been released). Unfortunately I'm not going to be able to look in to this for a while but it is certainly on my to do list as I'd actually like to be able to evaluate bds on a real project, not just little bits of test code which I'm limited to at the moment. Cheers Russell