Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
From: degski (degski_at_[hidden])
Date: 2017-03-27 00:11:44
On 26 March 2017 at 09:39, Peter Dimov via Boost <boost_at_[hidden]>
wrote:
> 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