On 2013-09-30 5:56 AM, Edward Diener wrote:
On 9/30/2013 1:59 AM, Joshua Boyce wrote:
On Mon, Sep 30, 2013 at 8:54 AM, Edward Diener
wrote: On 9/29/2013 4:09 PM, Jim Bell wrote:
On 2013-09-29 2:54 PM, Beman Dawes wrote:
Chandler Carruth has asked for a volunteer to start running boost regression tests for the Clang on Windows project.
...
FWIW, I started on a Clang regression (using some mgw-w64 version), but quit when I found that it would only build static libraries, which caused a huge swath of tests to fail for that reason alone.
I don't recall it misbehaving badly in other cases, though I may not have looked too closely.
Really ? Try 'bjam toolset=clang" under Windows in the Boost preprocessor test directory. ...
Using toolset=clang on Windows still gives "clang-linux" for me, which needs to be fixed. We also need to distinguish between 'native' Clang and 'mingw-w64' Clang (see me other post) as they use an entirely different standard library and CRT.
There is no toolset other than 'clang' for using clang under Windows AFAIK. If a separate one is needed for clang under Windows then that's up to the Boost Build developers to provide one. I have no idea how to do so and am not proficient with Boost Build and bjam.
I do know that if I use toolset=clang ....
...
I understand that clang has a g++ compatibility mode, though toolset=clang is clearly superior. I'm intrigued at the notion of building clang myself, but I think leveraging the mingw-w64 folks' hard work is a great idea (and reproducing their pain not too appealing). How an easy-to-obtain clang release does with boost is a separate question from how a bleeding-edge build does. Both are interesting and important, but to different audiences. I'm not finding a thing on lack of DLL generation, so maybe I missed something before.