On 7/14/2014 1:35 PM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 14 July 2014 08:06 To: boost@lists.boost.org 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.