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

Subject: Re: [boost] [regression runner] Preference libstdc++ vs. libc++
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-03-07 13:44:10

On 3/7/2017 6:03 AM, Niall Douglas via Boost wrote:
> 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 :)

The problem with clang targeting the MSVC ABI, as far as Boost is 
concerned, is that it erroneously implements the non-standard VC++ 
preprocessor. This makes it all but useless for using with Boost. That 
it should have even been designed to do this for all macros, rather than 
just for the macros it needed when processing VC++ and Windows headers, 
is its major downfall. When you have to emulate something that is 
already non-standard, and for which no internal knowledge is available, 
you are already on the wrong path.