On 06/03/2017 22:50, Tom Kent via Boost wrote:
1) Convert all compatible clang builds to libc++, don't mess with libstdc++ & clang. 2) Duplicate all the clang builds to build each version with both (acknowledging that will add nearly 1/3 to the already large ~125 linux runs). 3) Change most of the runs, but keep a few token libstdc++ & clang runs, with the latest compiler version (what c++ standard c++14? c++1z?). 4) Just add a few token libc++ runs, with the latest compiler version (what c++ standard c++14? c++1z?). 5) Don't add libc++.
A data point no one else seems to have mentioned yet is that while libstdc++ is pretty much the default STL on Linux, it is increasingly libc++ which is the default STL on Android. So, longer run, the right and proper approach would be to test both STLs on Linux assuming that Android usage of Boost will continue to grow. Also, I don't know about anyone else, but I use Microsoft's C2 clang generating the MSVC ABI a LOT. I know it still can't compile all of Boost without ICEing, but it's getting close and if a regression runner were available for C2 clang I don't doubt the Microsoft folk would find that useful. Finally, LLVM clang targeting the MSVC ABI is also getting close to viable as a daily compiler on Windows. For me personally, the C2 clang is much more important because you can run Visual Studio debug sessions with its output unlike LLVM clang's output which works but is barely viable. LLVM clang also ICEs when facing Boost with the MSVC ABI, but it's in totally different places to the C2 clang :) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/