On Tue, Mar 7, 2017 at 1:50 AM, Tom Kent via Boost
I have a bunch of linux regression runners that are executing clang runs of the boost regression suite (clang 3.0 - 4.0), currently these are all using the default, GCC libstdc++. Is there an interest from developers to see these runs with libc++?
The basic options:
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++.
I think, on Linux libstdc++ is the major standard library, even with clang. So I'd prefer #4 with one or two latest clang versions, c++14 and c++1z.
You can see more details about all of this on the github page where I keep my regression build scripts: https://github.com/teeks99/boost-build/tree/master/Regression
The actual confgs run by the "full": https://github.com/teeks99/boost-build/blob/master/ Regression/teeks99-02/machine_vars.json
The docker builds for all these machine configurations are kept at: https://github.com/teeks99/boost-build/tree/master/Docker And can be pulled from the docker hub with e.g. `docker pull teeks99/boost-build:clang-3.9`
If you've read this far, I'd be happy for any other opinions from developers who use the test matrix. Is it worth keeping all those compilers in the middle? Do we need to test the latest compilers with all the different standard configs (03, 11, 14, 1z + gnu equivalents)?
I don't think there's need to do separate runs for warnings (i.e. with -Wall -Wextra flags). Those can be combined with debug or release runs. Regarding gnu++, personally, I almost always build my projects and test my libraries with GNU extensions (because why not). I'm not sure exactly what extensions are enabled in that mode compared to c++ modes. AFAIR, the extensions were essential with C++03 (if I'm not mistaken, the long long/int64_t/etc. type was considered a GNU extension back then and this type is used in quite a few places). Not sure how much needed those are with C++11 and later.