Re: [boost] [clang] Using clang in Windows

Subject: Re: [boost] [clang] Using clang in Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-14 17:08:28

On 7/14/2014 1:35 PM, Paul A. Bristow wrote:
>
>
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Edward Diener
>> Sent: 14 July 2014 08:06
>> To: boost_at_[hidden]
>> Subject: [boost] [clang] Using clang in Windows
>>
>> Just a note to everybody about using clang in Windows. I upgraded the latest
> clang-
>> linux.jam file in Boost Build on the 'develop' branch so that clang in Windows
> using
>> gcc should now work for the purposes of testing Boost libraries.
>>
>> If you get the latest clang and build it on Windows using CMake with any of
> the
>> mingw generators or Ninja, you will have a clang executable which will default
> to a
>> target using gcc headers and libraries. If you add a line in user-config.jam
> such as:
>>
>> using clang : : yourpath/clang++.exe ;
>>
>> then you should be able to execute:
>>
>> b2 toolset=clang
>>
>> in order to run tests from withion a test directory for any Boost library
> using clang as
>> your compiler. The output looks very good without any of the problems I have
> seen
>> before when running clang in Windows.
>> Just make sure you switch to the Boost Build 'develop' branch and pull the
> latest
>> source.
>>
>> I have been successful so far when running tests of preprocessor, mpl,
> type_traits,
>> and tti with clang in Windows. I will test some more libraries but so far it
> looks to me
>> that the clang developers have finally created a version under Windows which
> can be
>> used to successfully test Boost libraries. This adds one more reliable testing
>> environment under Windows. Now I can use the latest clang, various flavors of
> gcc
>> under mingw, and various flavors of VC++.
>
> Good news - and thanks for all your work on this.
>
> Paul
>
> PS How close are we to being able to use clang with the VS IDE?

There are two problems with using clang with the VS IDE and VC++:

1) The lesser of the two problems is that we still have not worked out a 
way for using Boost Build with clang targeting either gcc or VC++, 
although we can do one or the other separately. Essentially a build of 
clang in Windows using gcc targets gcc by default, and a build of clang 
on Windows using the VS IDE targets VC++ by default. The final 
executables produced are essentially the same either way except for the 
default target. The target can also be specified via a command line 
-target or --target= parameter whose documentation is very poor to 
nonexistent, so the easiest way to use clang in Windows is to use the 
default target. Boost Build needs totally different .jam files depending 
on the clang target. For gcc as the clang target the clang-linux.jam 
file will now work correctly in Windows but for VC++ as the target a 
separate clang-win.jam is used, along with changes in clang.jam and 
common.jam. Vladimir Prus is aware of these issues and has mentioned 
that he will take a look at this when he has some time to address it.

2) The greater of the two problems is that in order to compile with the 
VC++ header files clang in Windows, targeting VC++, has had to emulate a 
certain amount of VC++ "bugs" just to digest the header files without 
compile errors. The most serious negative form of this emulation IMO is 
that clang has emulated some of the "bugs" in the very non-standard VC++ 
preprocessor. However the extent of the "bugs" in the VC++ preprocessor, 
even if the VC++ preprocessor "works" fine for the  majority of fairly 
simple macro processing, is large when it comes to the sort of 
preprocessor metaprogramming done in Boost PP and my own VMD library. 
These bugs all center around the fact that the VC++ preprocessor does 
not do macro expansion correctly, often seemingly not fully expanding 
macro input before the tokens are substituted in the invoking macros 
output. But there are a number of other things which the VC++ 
preprocessor gets wrong, which can only be illustrated by very 
complicated examples and rarely by easy cases. It is highly doubtful 
that clang targeting VC++ duplicates all the "bugs" and preprocessing 
weirdness of VC++ macro expansion, but just duplicating some of them 
creates another compiler with weird VC++ like problems which a library 
like Boost PP is asked to deal with. I know Paul Mensonides has no 
enthusiasm for such work and neither do I, dealing with VC++ itself has 
been hard enough. I made the suggestion in the clang developer's mailing 
list that clang targeting VC++ should act like the buggy VC++ 
preprocessor for macros in VC++'s header files but should be a C++ 
standard conforming preprocessor otherwise, possibly controlled by some 
pragmas, but it seems like nobody cares about this. There are just too 
many programmers who just want clang targeting VC++ to behave like VC++ 
so they can use it theirt VS IDE compiler and they don't care if doing 
so means that it cannot compile other C++ standard code correctly, in 
this particular case C++ macros.