Re: [boost] [clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows

Subject: Re: [boost] [clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-04-05 20:12:16

On 4/5/2016 11:38 AM, degski wrote:
> Hi Andrey,
>
> Someone interested in clang on Windows has to get his hands dirty and make
>> that happen.
>
>
> Anybody interested in developping C/C++/Obj C on windows should be
> interested, it seems nobody is aware of Clang/LLVM on windows.

Clang on Windows is two different implementations. There is clang on 
Windows targeting mingw(-64)/gcc and there is clang on Windows targeting 
VC++.

I have filed bugs in clang's bug tracker for clang on Windows targeting 
mingw(-64)/gcc but I have not had time to investigate and file bug 
reports for linking problems in this environment, which exist and can be 
seen when building some Boost non-header only libraries as well as some 
Boost executables for testing. I know what the basic problem is, which 
is that clang is not providing the same object names and visibility as 
gcc despite the fact that it uses the gcc linker. So linking sometimes 
fails. But I have not had time to track down and report specific linking 
problems.

As far as clang on Windows targeting VC++ a major problem is clearly 
that clang's emulation of the VC++ preprocessor is failing. What you 
expect Boost to do about this I do not know, but one thing this Boost 
developer will not do is try to find workarounds for these failures. I 
did ask on the clang mailing list how I can get clang targeting VC++ to 
show the emulated expansion of macros that it was doing so I ( and 
possibly others ) could at least report to clang the exact situations 
where clang's emulation of the VC++ preprocessor was giving an error 
whereas the VC++ preprocessor was working. The reaction I got for my 
query was complete silence. In other words clang targeting VC++ appears 
to be following the VC++ path of not only producing a non-standard 
preprocessor but also making sure that no one can actually find out what 
this non-standard preprocessor is actually doing when it erroneously 
performs macro expansion. Therefore to me there is absolutely no point 
of following clang down this path no matter how popular clang's 
emulation of VC++ may turn out to be until the nonsense involving the 
preprocessor is resolved. Many Boost libraries use the Boost PP for 
preprocessor code so expecting these Boost libraries to work with clang 
targeting VC++ is a waste of time.