Subject: Re: [boost] [build] How to use with clang on windows?
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-03-26 12:26:06
On 3/26/2016 10:38 AM, degski wrote:
> Hi Edward,
> First of, thanks for your elaborate answer, explaining the extent of the
> The clang build which targets VC++ on Windows, as opposed to the clang
>> build which targets mingw(-64)/gcc on Windows, 'emulates' the non-standard
>> VC++ preprocessor so it can compile Windows API headers and VC++ header
> Do you imply here that the preprocessors of both Clang/LLVM and Clang/C2
> work exactly the same way?
I don't know what you mean by Clang/LLVM and Clang/C2. But the normal
clang preprocessor and the clang preprocessor which works when clang is
built for Windows targeting VC++ are two different things. 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. They are two distinctly
> For all I know clang targeting VC++ may indeed work with those libraries if
>> the libraries pretend that clang targeting VC++ is VC++ for the intention
>> of those libraries.
> Isn't that the way to go then, to make boost act as if Clang/LLVM is VC14.
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++.
> When using Clang/LLVM with the M$-STL there are no issues, so it must do a
> reasonable job AFAICS.
What makes you think there are no issues ? 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.
> Clang/LLVM definitely flags quite a few of the
> non-confirming issues your own code might have, which implies that the
> VC14-STL does not have those kind of issues anymore.
Your logic does not follow.
> Getting some of my
> older projects to compile (with Clang) at all is quite a hassle (looks like
> a different C++).
>> I made a suggestion to the clang developers that there 'emulation' of the
>> non-standard VC++ preprocessor in their clang targeting VC++ implementation
>> should be configurable so that when the compiler is not dealing with
>> Windows API and VC++ header files it can be turned off and clang would then
>> be the same C++ standard conforming preprocessor as it is with clang
>> targeting mingw(-64)/gcc and clang on Linux and on the Mac. The suggestion
>> was rejected. After that my interest in running clang targeting VC++ on
>> Windows ended.
> Again, why fight the Clang developers, go with the flow, Clang/LLVM wants
> to emulate VC++ perfectly, fine, should make your life easier no?
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. There is a big difference between these
implementations. How would you propose supporting clang in preprocessor
code considering these differences ?
>> ...which 'emulates' the VC++ preprocessor in various unknown ways...
> With the above position taken, those unknown ways would then hopefully be
> identified and emulated by the Clang team... M$ is in the loop as well, as
> far I understand, so it's not exactly reverse-engineering.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk