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-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
> issues.
>
> 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
>> files.
>
>
> 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 
different implementations.

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