On 23/09/13 09:35, Edward Diener wrote:

On 9/22/2013 9:26 PM, Daryle Walker wrote:

...

There was a recent conference where the Clang team announced a version of Clang that's supposed to work on Windows (as opposed to kind-of working if you try real hard). It's accessible from the command line if you put Clang in the PATH. I just found out it's supposed to be used from Visual Studio ('10 or '12) after tweaking a project's settings. Can it be used from out BJam system? How will it find right header files to use? (Does it automatically use the ones from MSVC?)

is there more information about this anywhere ?

The announcement at Going Native: http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s... Blog Entry: http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html Builds: http://llvm.org/builds/ Ben

From: benpope81@gmail.com Date: Mon, 23 Sep 2013 10:49:54 +0800

On 23/09/13 09:35, Edward Diener wrote:

...

is there more information about this anywhere ?

The announcement at Going Native: http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s...

Blog Entry: http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html

So, can it be used on the command-line? Or is it just for MSVC (IDE)?

Builds: http://llvm.org/builds/

Daryle W.

24.09.2013 2:00, Niall Douglas пишет:

I think they meant http://www.ishani.org/web/articles/code/clangvsx/. It's simply a plugin for Visual Studio, no more. No, they've done something different. They integrated the clang compiler with msbuild system. They are also trying to use the Dinkumware STL.

If you are happy to use clang as you would mingw, I've found it pretty good on Windows. Forget about substituting MSVC with clang though, they're not equivalent. As I understand, they are trying to make substituting MSVC with clang possible.

-- Best regards, Sergey Cheban

On Mon, Sep 23, 2013 at 5:57 PM, Sergey Cheban wrote:

23.09.2013 5:26, Daryle Walker wrote:

There was a recent conference where the Clang team announced a version of

...

Clang

that's supposed to work on Windows (as opposed to kind-of working if you try real hard). Currently, it fails to process <iostream> with the following error messages:

1>CL : error : cannot mangle RTTI descriptors for type 'codecvt' yet 1>CL : error : cannot mangle the name of type 'codecvt' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type 'codecvt_base' yet 1>CL : error : cannot mangle the name of type 'codecvt_base' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type 'facet' yet 1>CL : error : cannot mangle the name of type 'facet' into RTTI descriptors yet 1>CL : error : cannot mangle RTTI descriptors for type '_Facet_base' yet 1>CL : error : cannot mangle the name of type '_Facet_base' into RTTI descriptors yet

OTOH, it can process <memory> and (haven't tried other headers yet), use some modern c++ features and produce working executables.

FWIW, I'm spoken to several of the Clang developers yesterday and today at the C++ standards committee meeting, and they emphasize their interest in improving support under Windows and would like help in the form of bug reports as they work out the kinks. They know they have a long way to go, but seem very interested in doing whatever is needed to make clang work really well on Windows. --Beman

On 24 September 2013 13:00, Edward Diener wrote:

On 9/23/2013 11:39 PM, Beman Dawes wrote:

...

FWIW, I'm spoken to several of the Clang developers yesterday and today at the C++ standards committee meeting, and they emphasize their interest in improving support under Windows and would like help in the form of bug reports as they work out the kinks. They know they have a long way to go, but seem very interested in doing whatever is needed to make clang work really well on Windows.

That's nice but my experience in the past has been that no one on the clang mailing list responded when the inability to even build clang for Windows was made known to them.

Furthermore Boost.Build did not support clang for Windows when I last tried it.

So if I try to build and use clang for Windows to whom do I report problems about clang ?

Beman said they want bug reports, so http://llvm.org/bugs/ seem the obvious choice. Mailing lists are a poor way to report bugs. If noone happens to be interested in looking into it that day then the mail goes unreplied and gets forgotten. Bug reports hang around until someone addresses them.

On Tue, Sep 24, 2013 at 10:36 AM, Sergey Cheban wrote:

On 24.09.2013 16:41, Jonathan Wakely wrote:

Beman said they want bug reports, so http://llvm.org/bugs/ seem the

...

obvious choice.

I think that it is too early to fill any external bug reports for the compiler that is unable to compile the first "hello world" example from the Stroustrup's book.

I've confirmed in face-to-face discussion with several key Clang folks that they do indeed to want bug reports against the Windows port. In other words, just what Jonathan said. --Beman

On 28 September 2013 21:50, Edward Diener wrote:

I still do not see a roadmap for using clang with Boost Build under Windows to build/test Boost libraries.

Am I supposed to download a Windows snapshot from http://llvm.org/builds/ ?

Am I supposed to get the latest llvm/clang from http://clang.llvm.org/get_started.html and build it for Visual Studio ( this never worked properly in the past and there is no mention of VS2012 on that page ).

Am I supposed to use a 'clang' toolset on Windows with Boost Build ?

As usual, with no doubt all the "good" intentions in the world to allow clang to be used under Windows, the documentation, explanation, and support for clnag under Windows is lacking/minimal.

Sounds like you're expecting someone to have already made this work. That's not how the bleeding edge of open source works, *especially* when combining things from different projects on a new platform! Someone has to figure all that stuff out bit by bit and fix the things that don't work. If you just expect to download a complete, working environment then you should wait until someone else has done the hard work.

On Sun, Sep 29, 2013 at 11:13 AM, Jonathan Wakely wrote:

On 28 September 2013 21:50, Edward Diener wrote:

...

I still do not see a roadmap for using clang with Boost Build under

...

to build/test Boost libraries.

Am I supposed to download a Windows snapshot from http://llvm.org/builds/ ?

Am I supposed to get the latest llvm/clang from http://clang.llvm.org/get_started.html and build it for Visual Studio (

...

never worked properly in the past and there is no mention of VS2012 on

Windows this that

...

page ).

Am I supposed to use a 'clang' toolset on Windows with Boost Build ?

As usual, with no doubt all the "good" intentions in the world to allow clang to be used under Windows, the documentation, explanation, and support for clnag under Windows is lacking/minimal.

Sounds like you're expecting someone to have already made this work. That's not how the bleeding edge of open source works, *especially* when combining things from different projects on a new platform!

Someone has to figure all that stuff out bit by bit and fix the things that don't work. If you just expect to download a complete, working environment then you should wait until someone else has done the hard work.

+1 Edward, Jonathan is exactly right about this. If you want to help, at the very least start grinding out bug reports for Clang on Windows. If you want to do even more, ask the Clang on Windows team what more you can do. For example, running tests for them. See their request for a test runner (hard to do cause I haven't posted it yet, but wait a few minutes...). --Beman

On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener wrote:

With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would have allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.

IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.

I will wish the clang people best of luck on their Windows implementation but if it means emulating VC++ in every respect I do not see the purpose of it, as I can just as well use VC++.

VC++ is not planning to support all of C++11/14 until roughly the end of 2014. Clang under Visual Studio will support all known C++11/14 features out of the chute. Surely that is a huge win for Visual Studio users, whether boost developers or otherwise. Even once VC++ catches up, there is a great advantage in having two compilers running under the same IDE since errors resulting in hard to diagnose error messages from one compiler often produce easy to understand error messages from a different compiler. It also makes it faster to tell if an error is a compiler error or a user error. --Beman

On 9/29/2013 6:17 PM, Chandler Carruth wrote:

On Sun, Sep 29, 2013 at 4:43 PM, Beman Dawes wrote:

...

On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener

...

wrote:

...

With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would

have

...

allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.

IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.

Indeed. Boost.PP I think would likely be a prime candidate for explicitly detecting Clang (even on Windows) and just doing the right thing.

The fix that I had made to Boost PP config.h, which I was asked to remove by Beman Dawes, explicitly detects that when _MSC_VER is defined and __clang__ is defined Boost PP should not treat the compiler as VC++. In the Boost PP config.h file prior to my fix if _MSC_VER is defined then the compiler is treated as VC++. There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++. I had proposed in the aforementioned thread that I was willing to work on changing such code in other Boost libraries so that it did the correct thing when both _MSC_VER and __clang__ were defined, but the reaction of not only Mr. Dawes and others was that I should not do that so I desisted.

On 9/29/2013 9:13 PM, Beman Dawes wrote:

On Sun, Sep 29, 2013 at 8:36 PM, Edward Diener wrote:

...

There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++.

But that is a mistake. BOOST_MSVC has been the preferred macro to check for VC++ since September of 2001. Since even before then there have been non-Microsoft compilers that define _MSC_VER.

The Boost PP config.h file was created by Paul Mensonides. Boost PP does not use the Boost.Config library or any other Boost library, so using BOOST_MSVC is not possible. You need to talk to Paul about his reasons and design. I am just trying to "fix" the Boost PP library so that clang on Windows works there. The reality is that a number of other Boost libraries use _MSC_VER instead of BOOST_MSVC in order to check for VC++ emulation. In some of those other libraries further checks are done to detect which actual compiler is using _MSC_VER and different code is often invoked in that case. But naturally there are no further checks for clang, since clang under Windows with _MSC_VER defined is "new".

On 9/29/2013 10:15 PM, Chandler Carruth wrote:

On Sun, Sep 29, 2013 at 7:36 PM, Edward Diener wrote:

...

The fix that I had made to Boost PP config.h, which I was asked to remove by Beman Dawes, explicitly detects that when _MSC_VER is defined and __clang__ is defined Boost PP should not treat the compiler as VC++. In the Boost PP config.h file prior to my fix if _MSC_VER is defined then the compiler is treated as VC++.

There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++. I had proposed in the aforementioned thread that I was willing to work on changing such code in other Boost libraries so that it did the correct thing when both _MSC_VER and __clang__ were defined, but the reaction of not only Mr. Dawes and others was that I should not do that so I desisted.

Our hope is that generally speaking, you shouldn't need to special case Clang -- it should be compatible. When it isn't compatible, ideally we'd like to fix the bugs so that it is compatible.

There may be a few cases where the code that Boost is using for VC++ is working around (and in the process relying on) really excessive quirks or bugs, and there it may be more pragmatic to just switch to more standards-based code path by checking for Clang explicitly. In other cases, VC++ may not have access to features that it makes sense to enable by detecting Clang.

If there are questions about a specific case, feel free to reach out to the Clang developers with either a bug report or email, and they can likely help.

There is a clang user mailing list but the clang developers never seem to bother with it. Am I supposed to use the clang developers mailing list instead ? Am I supposed to email some developer in particular ?

On 9/29/2013 5:43 PM, Beman Dawes wrote:

On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener wrote:

...

With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would have allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.

IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.

If they don't intend to "mimic bugs not required for that purpose" then the fix I put in Boost PP config.h is absolutely necessary. Please try "bjam toolset=clang" in the Boost PP test directory under Windows after building or installing clang under Windows. You will soon understand why I made the change I did. After the slew of failures that you see because clang, a highly comformant C++ preprocessor pretends to be VC++ for the purposes of the Boost PP code because it defines _MSC_VER, you can make the change I originally did and try "bjam toolset=clang" again in the Boost PP test directory. Then you will see the difference. I do understand and applaud clang's purpose to compile code properly under Windows, even using the Windows header files. But I do not see the purpose of emulating VC++ when it is broken in regards to the C++ standard if it is not necessary. My Boost PP change made emulation of the broken VC++ preprocessor unnecessary for Boost PP. Please remember that very little other, if any at all, preprocessor code written for Windows is going to require clang to emulate the broken VC++ preprocessor in order to compile Windows code. Boost PP pushes the boundary of what can be done with the C++ preprocessor in a cross-platform way. Can it really be that clang in Windows wants to go from a C++ standard compliant preprocessor to the rather horrible VC++ preprocessor just to accomplish its goal of compiling C++ under Windows ? Each case is distinct and there may be some other cases where clang will attempt to emulate VC++ but trying to duplicate the VC++ preprocessor should not be one of them. I cannot emphasize this more. There's no point in producing a first-rate product and then crippling it in some large respect because of emulation on a particular OS. I don't particularly care what else it brings to the table. I know it is a fine line to decide what compromises might have to be made in pure C++ standard code to emulate VC++ and therefore compile Windows code. There may be other cases where clang will emulate VC++ even if it does not strictly follow the C++ standard. But the preprocessor is not one of them if you know anything at all about how badly VC++'s preprocessor is broken for all but the most basic macro expansions.

...

I will wish the clang people best of luck on their Windows implementation but if it means emulating VC++ in every respect I do not see the purpose of it, as I can just as well use VC++.

VC++ is not planning to support all of C++11/14 until roughly the end of 2014. Clang under Visual Studio will support all known C++11/14 features out of the chute. Surely that is a huge win for Visual Studio users, whether boost developers or otherwise. Even once VC++ catches up, there is a great advantage in having two compilers running under the same IDE since errors resulting in hard to diagnose error messages from one compiler often produce easy to understand error messages from a different compiler. It also makes it faster to tell if an error is a compiler error or a user error.

On 9/29/2013 8:37 PM, Beman Dawes wrote:

On Sun, Sep 29, 2013 at 7:26 PM, Edward Diener wrote:

...

On 9/29/2013 5:43 PM, Beman Dawes wrote:

...

On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener * *wrote:

...

With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would have allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.

IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.

If they don't intend to "mimic bugs not required for that purpose" then the fix I put in Boost PP config.h is absolutely necessary. Please try "bjam toolset=clang" in the Boost PP test directory under Windows after building or installing clang under Windows. You will soon understand why I made the change I did. After the slew of failures that you see because clang, a highly comformant C++ preprocessor pretends to be VC++ for the purposes of the Boost PP code because it defines _MSC_VER, you can make the change I originally did and try "bjam toolset=clang" again in the Boost PP test directory. Then you will see the difference.

I do understand and applaud clang's purpose to compile code properly under Windows, even using the Windows header files. But I do not see the purpose of emulating VC++ when it is broken in regards to the C++ standard if it is not necessary. My Boost PP change made emulation of the broken VC++ preprocessor unnecessary for Boost PP. Please remember that very little other, if any at all, preprocessor code written for Windows is going to require clang to emulate the broken VC++ preprocessor in order to compile Windows code. Boost PP pushes the boundary of what can be done with the C++ preprocessor in a cross-platform way. Can it really be that clang in Windows wants to go from a C++ standard compliant preprocessor to the rather horrible VC++ preprocessor just to accomplish its goal of compiling C++ under Windows ?

Each case is distinct and there may be some other cases where clang will attempt to emulate VC++ but trying to duplicate the VC++ preprocessor should not be one of them. I cannot emphasize this more. There's no point in producing a first-rate product and then crippling it in some large respect because of emulation on a particular OS. I don't particularly care what else it brings to the table.

I know it is a fine line to decide what compromises might have to be made in pure C++ standard code to emulate VC++ and therefore compile Windows code. There may be other cases where clang will emulate VC++ even if it does not strictly follow the C++ standard. But the preprocessor is not one of them if you know anything at all about how badly VC++'s preprocessor is broken for all but the most basic macro expansions.

OK, put your patch back in, and see if it helps.

Patch has been reinstated and there are now, as I had expected, no errors when running the Boost PP tests or when using the Boost PP macros in other libraries. But there are still errors in other libraries with clang on Windows which have nothing to do with Boost PP. I can do my best to fix those problems, always telling others what I would like to do before I do it to get approval.

Chandler has signed up for the developers list, so he can answer future questions himself.

Sounds great. As I originally said I would like to work to get clang working for Boost libraries.

On 9/29/2013 10:16 PM, Chandler Carruth wrote:

On Sun, Sep 29, 2013 at 9:14 PM, Edward Diener wrote:

...

Chandler has signed up for the developers list, so he can answer future

...

questions himself.

Sounds great.

As I originally said I would like to work to get clang working for Boost libraries.

I'm happy to help as much as I can. It may be useful to CC me directly on emails you want me to look at. I scan the list, but might miss a message otherwise.

OK, thanks ! I will probably post on this mailing list and only bother you if I don't hear anything otherwise.

On 9/28/2013 10:31 PM, Edward Diener wrote:

On 9/28/2013 1:26 PM, Beman Dawes wrote:

...

On Tue, Sep 24, 2013 at 10:36 AM, Sergey Cheban wrote:

...

On 24.09.2013 16:41, Jonathan Wakely wrote:

Beman said they want bug reports, so http://llvm.org/bugs/ seem the

...

obvious choice.

I think that it is too early to fill any external bug reports for the compiler that is unable to compile the first "hello world" example from the Stroustrup's book.

I've confirmed in face-to-face discussion with several key Clang folks that they do indeed to want bug reports against the Windows port. In other words, just what Jonathan said.

Unfortunately there is still no workable Boost Build implementation of clang for Windows, so it is impossible to test clang with Boost Build. I built the latest clang from llvm/clang and then ran the tests of the central Boost library for all template metaprogramming, Boost.MPL, with clang on Windows. The results were many errors almost certainly because of some setup problem with clang and Boost Build:

------------------------------------------------------------

clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\mpl\test\largest_int.test\clang-linux-3.4\debug\largest_int.obj

"C:/Programming/VersionControl/bclang/bin/Release/clang.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -o "..\..\..\bin.v2\libs\mpl\test\largest_int.test\clang-linux-3.4\debug\largest_int.obj" "aux_\largest_int.cpp"

In file included from aux_\largest_int.cpp:14: In file included from ..\..\..\boost/mpl/aux_/largest_int.hpp:17: ..\..\..\boost/mpl/if.hpp:131:1: error: pasting formed 'BOOST_PP_TUPLE_ELEM_E_2(', an invalid preprocessing token [-Winvalid-token-paste] BOOST_MPL_AUX_NA_SPEC(3, if_) ^ ..\..\..\boost/mpl/aux_/na_spec.hpp:149:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC' #define BOOST_MPL_AUX_NA_SPEC(i, name) \ ^ ..\..\..\boost/mpl/aux_/na_spec.hpp:142:47: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_NO_ETI' #define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \ ^ ..\..\..\boost/mpl/aux_/na_spec.hpp:63:9: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_MAIN' BOOST_MPL_PP_NESTED_DEF_PARAMS_TAIL(i, typename T, na) \ ^ note: (skipping 5 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) ..\..\..\boost/preprocessor/tuple/elem.hpp:36:114: note: expanded from macro 'BOOST_PP_TUPLE_ELEM' # define BOOST_PP_TUPLE_ELEM(size, n, tuple) BOOST_PP_TUPLE_ELEM_I(BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM_, n), BOOST_PP_CAT(BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM_E_, size), tuple))

^ ..\..\..\boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT' # define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b) ^ ..\..\..\boost/preprocessor/cat.hpp:31:55: note: expanded from macro 'BOOST_PP_CAT_I' # define BOOST_PP_CAT_I(a, b) BOOST_PP_CAT_II(~, a ## b)

I believe part of the error is in the preprocessor config.hpp file where clang is treated as VC++ because _MSC_VER is defined for the Windows version of clang. I am looking to correct this now as soon as I can find what macro define clang uses to identify itself. It does also look as if clang complaining that '##' is an invalid preprocessing token is an error in the Windows implementation of clang and I will report this to clang as a bug as soon as I can create a simple test case for it.

------------------------------------------------------------

I doubt this is a clang problem per se since clang on Linux handles Boost.MPL quite easily. No doubt the default setup for clang in Windows under Boost Build does not work and I don't really know how to make it work.

If we ever have a build of clang for Windows that works with Boost Build in Windows it will be a boon for testing Boost under Windows. But it is not yet a reality.

On 24 September 2013 18:12, Niall Douglas wrote:

On 24 Sep 2013 at 13:41, Jonathan Wakely wrote:

...

Beman said they want bug reports, so http://llvm.org/bugs/ seem the obvious choice.

Mailing lists are a poor way to report bugs. If noone happens to be interested in looking into it that day then the mail goes unreplied and gets forgotten. Bug reports hang around until someone addresses them.

+1 on that. I've had a very good experience so far with the LLVM bug tracker as compared to the GCC bug tracker. Where on GCC's tracker you really need to prove a bug is incontravertibly true for it to not get autoclosed,

That's clearly not true, based just on the number of open UNCONFIRMED bugs in GCC's bugzilla! We can be pretty militant about seting bugs to WAITING if the report doesn't provide enough information, but I dispute that bugs are "autoclosed" without good reason.

On 24 Sep 2013 at 8:00, Edward Diener wrote:

That's nice but my experience in the past has been that no one on the clang mailing list responded when the inability to even build clang for Windows was made known to them.

I don't think it's a huge priority - yet - for the two big developers of clang because MSVC is the de facto compiler on Windows. However clang's AST library is certainly of *great* interest to Windows developers, and that part appears to be very well maintained for Windows. I even found some website providing regular prebuilt Windows binaries for clang's AST library.

Furthermore Boost.Build did not support clang for Windows when I last tried it.

Yeah I misspoke earlier; I was building Boost using scons, not Boost.Build, and therefore my earlier comment about simply asking b2 for clang was wrong. Sorry. My memory is ailing with age sadly :(

Clang is a great compiler under Linux. And I am willing to try to get it to work under Windows using Boost.Build to test Boost libraries, my own and others, under Windows, reporting problems to the appropriate places. But not if I am once again met by indifference when problems occur.

If you were to marry clang with the libstdc++ 4.8 headers in mingw-w64 (it's a simple enough recompile to swap the hardcoded header locations), I think you'd see great success as a mingw substitute. But then mingw has just moved to 4.8, both in traditional mingw and mingw-w64, and combined with the much improved VS2013 that eliminates a good chunk of the need for clang on Windows. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/