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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk