Dear all, You may remember me saying these past six months that I was working on the tools necessary to fork Boost into a C++ 11 only distro which also lets you use Boost libraries individually standalone without the rest of Boost. I have got a first alpha version of my clang AST based local bindings generator working, and you can see it at https://github.com/ned14/local-bind-cpp-library. This tool lets you generate a set of local namespace bindings for some implementation of some library such that your library implementation code need not care what the underlying implementation of dependent library facilities is. This way your Boost library could be using either Boost or the C++ 11 STL and you don't need to care (most of the time). Now I have the first alpha version working and generating a reasonable set of C++ 11 STL bindings (https://github.com/ned14/local-bind-cpp-library/tree/master/include/s tl11), I'll start with porting over my own Boost libraries to it, so Spinlock, Expected, non-allocating future-promise and AFIO will be the first, and with those AFIO should become capable of being completely standalone from Boost whilst still also able to compile against Boost. After that I'll try porting the entire of Boost.Thread over such that Boost.Thread no longer needs Boost. I think that would be hugely useful for people wanting to use potential C++ 17 threading functionality without needing to draw in all of Boost as a dependency, and that might greatly widen the empirical experience new threading facilities might get before the 17 standard. Once I've succeeded with that, if the present situation with Boost has not improved by then, I'll press ahead with a new Boost distro website which score ranks Boost modules according to the scoring manifest I outlined on this list some months ago, and lets you download standalone Boost distros of your choice. Obviously only libraries ported to be standalone capable would be available, so I would hope that if I can demonstrate an easy port with Boost.Thread, others may follow with their libraries. All this work occurs in my free time of a few hours per week, so progress will be slow but steady. Comments on the local namespace binding tool are welcome. Comments on the proposed C++11/14 good practice idiom of binding dependent library APIs into the local namespace are also welcome, because as far as I can tell no one here has discussed a formal set of conventions to make best use of inline namespaces for new libraries. I'll put it another way - local namespace binds are a poor man's version of Herb's proposed C++ ABI facility. As much as they aren't quite as good, they are probably good enough (relative to Herb's most recent proposal). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/