Re: [boost] [build] How to use with clang on windows?

Subject: Re: [boost] [build] How to use with clang on windows?
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-03-27 09:13:20

On 3/27/2016 6:50 AM, degski wrote:
> Hi Edward,
>
> I don't know what you mean by Clang/LLVM and Clang/C2.
>
>
> I wrote this earlier: "There are two usable versions of clang targetting
> VC, the (main) difference is in the back-ends, one has the LLVM back-end (
> http://llvm.org/builds/), the other the C2 back-end (
> https://blogs.msdn.microsoft.com/vcblog/2016/01/20/clang-with-microsoft-codegen-january-2016-released/).
> The Clang/LLVM compilers Clang-Cl.exe, Clang.exe and Clang++.exe are al
> just copies of the same file." If you read John top-post you'll see he also
> refers to those two different compilers.
>
> By "targeting" on Windows I mean that clang is built to use either the gcc
>> RTL or the VC++ RTL. The version which targets the VC++ RTL has a VC++
>> conforming non-standard C++ preprocessor while the one targeting the gcc
>> RTL has a C++ standard conforming preprocessor.
>
>
> Targeting Windows and GCC (RTL) are two mutually exclusive notions. I guess
> you are referring  to MinGW. although it works, one can hardly call it
> targeting windows

An executable built with mingw(-64)/gcc runs natively on Windows, so 
your comment above makes no sense.

>, it's a usefull workaround for things that won't work
> otherwise ((like compiling OpenBlas.lib f.e., as there is no free native
> Fortran compiler on Windows, but this has issues, like obligatory dll's
> instead of static libs).
>
> They are two distinctly different implementations.
>>
>
> Sure.
>
>
>> No !!! Why should Boost support a non-conforming C++ preprocessor when a
>> perfectly good conforming preprocessor is available from clang for anything
>> which does not target VC++.
>>
>
> Boost is already supporting the non-conforming C++ preprocessor.

It's hard enough supporting the non-conforming VC++ preprocessor. I 
personally have no intention of supporting another non-conforming 
implementation of the C++ preprocessor in clang's 'emulation' of VC++ in 
Boost PP or Boost VMD. If you or someone else wants to do it, go ahead.

>
>
>> Try running Boost PP with a VC++ conformant preprocessor without the VC++
>> workarounds in Boost PP and you will find more issues than you can imagine.
>>
>
> Sure, but there's no compelling reason to try and do that.
>
> Your logic does not follow.
>>
>
> What I'm trying to get across is that Clang/LLVM treats the VC14-STL as
> bog-standard C++ (and it works, so it must be conforming). I know this,
> because it also assumes my own code is standard conforming and protests if
> it doesn't. It flags issues in Intel's Thread Building Blocks as well f.e..
>
> Clang is used on Linux, Mac, and Windows and maybe a few other OSs I don't
>> know about. It only emulates VC++ when it is built for Windows targeting
>> VC++. You still don't seem to understand that in the vast majority of its
>> uses clang has a C++ standard conforming preprocessor while in a single one
>> of its uses clang has a VC++ emulated non-standard C++ preprocessor.
>
>
> Yes, I do understand that it's different. But boost is already supporting
> this different PP, as it is already supporting VC. The Clang team is doing
> the work here. I get your frustration, but in practice I don't see an issue.

The issue is the huge amount of work involved in supporting a 
non-conforming C++ preprocessor such as VC++ in Boost PP and Boost VMD. 
The answer to that is not to create another different non-conforming C++ 
preprocessor, which you then want to be supported in Boost PP and Boost 
VMD, but to have organizations like Microsoft and clang adhere to the 
C++ rules for preprocessing code. Clang actually does follow the C++ 
rules for preprocessing code in all respects except when it 'emulates' 
VC++. Microsoft has never conformed to the C++ rules for preprocessing code.

>
> Feel free to offer "workarounds" in Boost PP and Boost VMD to deal with the
>> clang targeting VC++ 'emulation' because I know I will not be doing
>> anything to get that 'emulation' working in those libraries. I have already
>> been down that path with VC++ itself and will not be repeating that
>> experience with another broken C++ preprocessor.
>
>
> I've been looking at the approach John takes in the top-post and got a bit
> futher than he did. I'll answer to his post with my findings.
>
> Have a good day,
>
> degski