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
way for using Boost Build with clang targeting either gcc or VC++, although we can do one or the other separately.
<snip> detailed problem description...
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.
<snip> detailed problem description...
May I suggest something?
Sometimes an idea from an idiot such as me can provide an
alternate way of thinking --- or not, or whatever.
To me it seems very difficult to force clang to comprehend
specialized VS headers and effectively deal with the VS
preprocessor? VS is hand-crafted for the VC++ compiler
and not designed to interact natively with a foreign compiler.
Have you considered simply side-stepping the VS compiler
for the clang compilation stage and finding the appropriate
juncture point to re-connect object files with VS?
This is the object file level.
If the object file format can be brought into a compatible form for VS,
then you do not even need to force the clang compilation stage
to interoperate with the VC++ preprocessor or the VC++ headers.
A big problem might be the language of the binary object files:
VS = COFF / clang = ELF. If you can work around this, perhaps
you can compile with clang as an external compiler and hook
up to the linker and debugger after compilation at the object
file level--- assuming of course that the object file binary format
can somehow be made compatible with Visual Studio's COFF format.
What I am saying is perhaps to simply side-step the VC++ compiler,
do not use its preprocessor, and do not use its headers. Simply use
clang in its entirety for compiling. You then only need to find a way
to hook up to the object file binary format on the object file level.
I hope I did not get something drastically wrong here, but it
sounds like a problem that I dealt with previously.
Cheers
Chris
On Monday, July 14, 2014 11:08 PM, Edward Diener
-----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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost