Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-03-25 14:39:27

On 3/25/2017 4:17 AM, Peter Dimov via Boost wrote:
> Paul A. Bristow wrote:
>> With adding <cxxflags>-fno-ms-compatibility to user_config.jam and a
>> command line...
>
>
>> I still get
>>
>> In file included from ..\..\..\boost/config.hpp:44:
>> ..\..\..\boost/config/select_stdlib_config.hpp:18:12: fatal error:
>> 'cstddef' file not found
>> #  include <cstddef>
>
> You never mentioned how you got rid of that error.
>
> Would not adding the MSVC include directory manually with -isystem work?
>
>> But I note that the line above mentions to object file location is
>>
>> clang-linux-4.0.0\debug\hello_boost.obj
>>
>> but default target x86_64-pc-windows-msvc
>>
>> should I expect Clang-msvc here?
>
> I have no idea why we have two clang toolsets, or which would be the
> correct one to use here.

Disclaimer: I contributed clang-win.jam to Boost Build but did not write 
it and do not know how it works. Nobody else who knows how Boost build 
works internally has ever taken an interest in it and I am not qualified 
to fix any of its problems.

The two clang toolsets are clang, which normally translates to 
clang-linux, and clang-win. The former is used on Linux, Mac, and on 
Windows when targeting mingw(-64)/gcc. Using VC++ as the backend you 
normally use clang-win. However clang targeting VC++ is broken in Boost 
PP because the clang developers incorrectly emulated the already 
non-standard VC++ preprocessor.

Whether -fno-ms-compatibility fixes anything or does anything I do not 
know. I have never been able to find the slightest documentation from 
clang about it, but then again clang's documentation has always taken a 
distinct backseat to clang's development ( I am being nice here ). I 
suspect that even when using -fno-ms-compatibility you still need to use 
the clang-win toolset since you are still using the VC++ backend. If I 
knew what -fno-ms-compatibility actually does vis-a-vis predefined 
macros I would try to update the BoostPP config.hpp accordingly. I was 
hoping to find out more about it in the VS2017 documentation, but since 
Microsoft put out VS2017 without any documentation ( nice going 
Microsoft ! ) that is currently impossible.

I explained to Paul via e-mail my rather elaborate setup for testing 
clang on Windows, both for targeting mingw(-64)/gcc and VC++. It is 
elaborate since it involves setting the PATH variable without which, 
AFAIK, clang and its gcc/VC++ backends do not work.