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 19:01:32

On 3/7/2017 12:12 PM, Niall Douglas via Boost wrote:
> On 07/03/2017 16:48, Edward Diener via Boost wrote:
>> On 3/7/2017 9:47 AM, Niall Douglas via Boost wrote:
>>>> 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.
>>>
>>> You can tell C2 clang to not use MSVC compatibility and VS2015 Update 2
>>> and later's headers will now compile cleanly. I would assume VS2017 is
>>> the same.
>>
>> Where is C2/clang available for download ? It seems the only thing that
>> is not mentioned in the C2/clang blogs. Nice going Microsoft !
>
> In the VS2017 installer, you just choose C2 clang just as you would any
> other component.

Your mention of VS2015 Update 2 above led me to think it was some 
downloadable software available for that product. Now I realize that it 
is available for VS2017 currently being launched. So much hubbub for a 
product which is just now being officially made available has confused 
me. I have this bad habit of waiting until some software actually 
officially exists and can be used before I become interested in it. 
Excuse me <g> !

>
> I can't remember if Visual Studio's default project settings turn on
> MSVC compatibility, but if they do, turn it off. Bar newly introduced
> bugs in the headers (ping Stephan on those), C2 clang is compiling the
> Windows SDK headers fairly well without MSVC emulation. There are some
> warnings at -Wall though.
>
> Note cmake et al don't understand the new path locations in VS2017 yet
> and it's a pain. HOWEVER you can now load cmake projects straight into
> VS2017 whereupon they find the new toolset because VS2017 ships a custom
> cmake internally. It's incredibly slow though, almost unusably slow. And
> VS2017 in cmake mode gets very badly confused frequently i.e. it's buggy.
>
> (Before someone from Microsoft asks for me to report the bug, let me
> suggest to you to go install WSL and try running cmake-within-WSL on the
> same project as VS2017 has loaded via cmake. It's a disaster, and a real
> impediment to the whole point of cmake project loading, you need to add
> some logic to account for concurrent cmake-outside-of-VS2017 especially
> when that is Linux cmake not Windows cmake)

Thanks for all the info !

>
> Niall
>