Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at