I don't really agree that the patches for the missing headers are fixes for STLport support. They are rather fixes to make boost less Standard library implementation dependant. There are of course not many available Standard library implementations on the market but it is not a reason to make this kind of shortcut :-)
Agreed, as a matter of fact I often wish there was a tool available for checking that all needed headers have actually been included (rather than included by accident as a hidden dependency).
Thanks for applying those, I hope I will have soon a final fix for the bjam STLport toolset as for the moment they are not correctly handling: 1. The fact STLport do not support the wrapper mode anymore 2. The modification in the library naming convention.
OK good, the msvc-stlport toolset is working with STLport-5 at present, but the others aren't I believe.
The last issue will then be the lexical_cast problem if you remember. lexical_cast used to not handle correctly configuration with no wchar_t intrinsic support but with wstring granted by the Standard lib. Have anything change lately ? If no shouldn't this kind of config be officially not supported anymore by boost ? I can do a fix to the stlport.hpp file for that if you need it.
Last time I looked I couldn't figure an easy way to make lexical_cast happy in that situation, I'll try and have another look, because we really should support this mode if we can (and the rest of Boost does I believe). John.