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.