Re: [boost] Boost and clang under Windows

Subject: Re: [boost] Boost and clang under Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-09-29 15:25:31

On 9/29/2013 2:52 PM, Beman Dawes wrote:
> On Sun, Sep 29, 2013 at 1:40 PM, Edward Diener <eldiener_at_[hidden]>wrote:
>
>> On 9/29/2013 1:21 PM, Andrey Semashev wrote:
>>
>>> On Sunday 29 September 2013 12:59:27 Edward Diener wrote:
>>>
>>>> First off I am not of course proposing any changes to the upcoming
>>>> release build of Boost 1.55 for clang under Windows.
>>>>
>>>> It turns out that clang under Windows, possibly to support the ability
>>>> to use Windows header file, becomes another compiler which defines
>>>> _MSC_VER. I believe the Intel compiler also does this but there may be
>>>> some others.
>>>>
>>>> However clang is a much more strictly conforming to the C++ standard
>>>> compiler than VC++ and does not have VC++'s quirks. This presents a
>>>> problem in Boost.
>>>>
>>>> The Boost header files have numerous places where testing the macro
>>>> _MSC_VER produces slightly different behavior based on the fact that the
>>>> code is being used by VC++ or a compiler with the same behavior as VC++.
>>>> But clang does not have the same behavior as VC++ despite defining
>>>> _MSC_VER.
>>>>
>>>> Can I go ahead and change some of these situations as necessary to get
>>>> clang under Windows to work properly with Boost code ?
>>>>
>>>
> Please do not do that. I had face-to-face meetings this week with Chandler
> Carruth
> and others working on Clang for Windows. They are depending on Boost's
> tests to find bugs in Clang's emulation of Visual C++, and if you work
> around their bugs it will deprive them of a valuable testing tool.

OK.

>
>
>>
>>>> The usual change will be to test not only _MSC_VER but also that
>>>> __clang__ is not defined for keeping the current implementation which
>>>> assumes a VC++ compatible compiler with VC++ behavior. I am willing to
>>>> make those changes in 'trunk' and keep an eye out for any significant
>>>> failures in unit tests for our current regression tests.
>>>>
>>>
> Please do not do that.

OK.

>
>
>>
>>>> I have already made a slight change to Boost PP config.hpp on 'trunk' so
>>>> that clang for Windows will pass the preprocessor tests.
>>>
>>>
> Please revert that change. That preprocessor problem was one of the
> specific examples they cited where they are hoping to achieve VC++
> compatibility. They really want boost tests to fail until compatibility is
> achieved, and then to detect any regressions if compatibility is lost.

OK. I have reverted the change.

But... does clang really want to emulate VC++'s highly broken 
preprocessor when building under Windows ? I have a really hard time 
believing that.

Essentially the change I made in Boost PP config.hpp ( you can check it 
) makes clang under Windows behave as a strictly conforming C++ 
preprocessor on the order of gcc and Wave rather than as the VC++ 
preprocessor. You have to know how bad the VC++ preprocessor is, as Paul 
Mensonides knows in full, and as I know somewhat, to realize what that 
means. I also doubt whether clang can even emulate the brokeness of the 
VC++ preprocessor in every respect, but I certainly cannot believe it 
would even want to.

I just want to make the point that while I understand that clang under 
Windows wants to emulate VC++ in some respects in order to compile 
Windows header code, I don't see the point of emulating VC++ completely. 
In that latter case there would be no reason even to use it as a highly 
conformant C++ compiler on Windows since it would essentially be "the 
same as VC++".

There is no sour grapes involved but I will not be the one to report 
preprocessor problems with clang under Windows if clang really wants to 
emulate the broken VC++ preprocessor. And since nearly every library to 
some greater or lesser extent depends on Boost PP for some macro 
preprocessing they will exhibit preprocessing errors using current clang 
under Windows and failed to pass their tests.

>
> I don't think it occurred to them or to me during the discussions that
> anyone would try to workaround failures before the clang folks had a chance
> to introduce Microsoft compatibility fixes. I'll get back to Chandler with
> a request for a public statement of their plan.
>
> He asked me to post a request for help on the Boost list, but it may take
> several days. It takes quite a while to work through do lists after a C++
> committee meeting.