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

Subject: Re: [boost] [build] How to use with clang on windows?
From: degski (degski_at_[hidden])
Date: 2016-03-27 06:50:49

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, 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.

> 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.

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