Re: [boost] [regression runner] Preference libstdc++ vs. libc++

Subject: Re: [boost] [regression runner] Preference libstdc++ vs. libc++
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-03-07 01:39:26

On Tue, Mar 7, 2017 at 1:50 AM, Tom Kent via Boost
<boost_at_[hidden]> wrote:
> 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.