On 26 March 2017 at 09:39, Peter Dimov via Boost
LLVM Clang finds and uses the 14.1 headers for me when using the clang-linux toolset. I could tell because it gave me errors in these headers when I wasn't supplying -fms-version=1910.
It seeems to me that that was not was intended. But having said that, if clang-linux works (with the Dinkumware STL), then progress is definitely being made and we're moving towards having just clang-any (on the 3 major platforms). I (and I guess I'm not alone) really appreciate the work (by yourself and others) that is being put into this!
clang-win is outdated.
Yes, it's lagging, but I would say the only benefit is the better debugging.
Clang under Windows is more or less the same as Clang under Linux now, except that it targets the Microsoft ABI (and fails to link).
Don't know about linking, must be a path problem or something to do with the clang-*linux* bit (ELF?). I'm using Clang/LLVM (from the VS2015 IDE) on a daily basis, no issues.
Visual Studio 2017 doesn't use clang-cl.exe, it understands Clang's options natively and uses clang.exe.
Great, cannot wait getting back home from Central-America to Central -Europe, so I can give it a try, as hotel WIFI is flaky here. Are you talking about Clang/C2 or Clang/LLVM?
A proper clang-win toolset today would treat Clang as Clang, not as cl.exe, only it would replace the link phase with a working one.
+1
And a proper clang-c2 toolset would do the same except it would use 14.0/14.1 as the version and look for clang.exe at the appropriate locations.
If Clang/LLVM works as any Clang, the only difference should be the backend. Obviously, one can only hope for this to work with VC14.1(0) or higher... degski