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 23:34:12

On 3/27/2016 6:15 PM, Niall Douglas wrote:
> On 26 Mar 2016 at 6:52, Edward Diener wrote:
>
>> 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. Exactly what VC++ preprocessor 'bugs' it emulates and
>> how successful this emulation is I do not know, but I know it is done
>> because I was told of it in the clang developer forum and I encountered
>> a clang targeting VC++ preprocessor 'bug' which was explained to me as
>> an emulation of VC++.
>
> As of VS2015 Update 2 RC, the MSVCRT, STL and Windows SDK headers
> supplied no longer require clang to act in MSVC compatibility mode to
> compile. I am compiling AFIO v2 for windows using LLVM clang with
> these options:
>
> clang.exe -fpic "stdafx.h" -fmsc-version="1900" -std=c++1y "x64\Debug
> clang\" -Wall -fstrict-aliasing -I "../include" -g2 -gdwarf-2 -O0 -x
> c++-header -U "__STDC__" -D "WIN32" -D "_DEBUG" -D "_WINDOWS" -D
> "_USRDLL" -D "BOOST_AFIO_EXPORTS" -D "_UNICODE" -D "UNICODE" -D
> "UNICODE=1" -D "_UNICODE=1" -D "AFIO_STANDALONE=1" -frtti
> -fno-omit-frame-pointer -fno-ms-compatibility -fexceptions -o
> "x64\Debug clang\%(filename).obj" -fms-extensions -fno-short-enums
>
> The key improvement with VS2015 Update 2 is the -fno-ms-compatibility
> is now possible even when using the Dinkumware STL, the Parallel
> Patterns Library or the Windows SDK. This means that clang treats
> your code as strictly as normal, and it is *very* useful for linting
> your code (the complete C++ 14 language support is also very handy).
>
> Note that I cannot get MSVCRT-as-a-dll working with this
> configuration, for that you still need -fms-compatibility.
> MSVCRT-as-a-static-library is working. I assuming this is a RC
> related problem which will be fixed soon, the cause is the char16_t
> and char32_t support misdetection.
>
> I am not using any preprocessor tricks which are incompatible with
> MSVC, so I cannot say if the broken preprocessor emulation is still
> present with -fno-ms-compatibility. I would suspect not.
> -fms-extensions are things like declspec markup support, I am not
> aware of it changing any parsing behaviour.

I do not have any idea any longer which versions/implementations of 
clang 'emulate' the VC++ preprocessor currently. There now appear to be 
standalone versions of llvm/clang as always and versions of clang which 
are part of a VC++ release, whic allow clang to be used as the backend 
compiler. I haven't kept up with the different manifestations of clang 
on Windows lately.

My point is simply that a version of clang for Windows has existed 
targeting VC++ which specifically 'emulates' the non-standard VC++ 
preprocessor. The non-standard VC++ preprocessor gets special treatment 
in quite a few cases in Boost PP and Boost VMD or else it will simply 
fail using much of those libraries. Therefore if versions of clang which 
'emulate' the VC++ preprocessor attempt to use Boost PP and Boost VMD it 
too will fail in a large number of cases.

I have no idea whether AFIO v2 uses Boost PP.

I am perfectly willing to set clang targeting VC++ on Windows which 
'emulates' the VC++ preprocessor to essentially act like the VC++ 
preprocessor in Boost PP and Boost VMD if I can unequivocally identify 
this version at preprocessor time. Then if it fails to compile parts of 
Boost PP and Boost VMD it will be a problem for the clang developers to 
solve, because I have no interest in trying to workaround such problems 
in Boost PP and Boost VMD for yet another non-conformant C++ preprocessor.

I also want to point out that the normal standard conformant clang 
preprocessor is different enough from the clang 'emulation' of VC++ 
preprocessor that it is imperative to identify each one or else Boost PP 
and Boost VMD will not work in large parts of their implementation. Of 
course if a Boost library does not use Boost PP ( or Boost VMD which no 
Boost libraries of which I am aware currently use ), or uses a very 
small part of Boost PP not affected by the many VC++ workarounds in 
Boost PP, it is possible it will not run into problems with clang 
'emulating' VC++. But I would not count on such lucky behavior.