Re: [Boost-build] Possibilities of clang for Windows

Subject: Re: [Boost-build] Possibilities of clang for Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-09 11:56:37

On 7/9/2014 4:06 AM, Vladimir Prus wrote:
> On 07/09/2014 12:01 AM, Edward Diener wrote:
>> The clang for Windows executable can be created so that the target
>> defaults to either vc++ or mingw/gcc mode. In Boost Build we currently
>> have a single toolset called clang, which works on the MacOS and
>> Linux. In order for it to work on Windows we can choose among these
>> separate possibilities:
>>
>> 1) Create a separate toolset, called 'clang-cl', for clang on Windows
>> targeting vc++.
>>
>> 2) Require the end-user using clang on Windows targeting vc++ to
>> invoke the command:
>>    a) as 'clang-cl'
>>    b) as 'clang' with a 'compatibility' option ( 'vcnn' as in 'vc12' )
>>
>> 3) Require the end-user to specify a 'target' option, either
>> 'i386-pc-win32' for vc++ mode or 'i386-pc-mingw32' for gcc/mingw mode.
>>
>> 4) Execute 'clang --version' piping the output back into stdin or
>> writing the output to a file and reading the file back in, and parsing
>> the
>> information to automatically figure out which mode it is.
>
> The last option is quite attractive. On the other hand, would a user
> ever need to use both flavours of clang at the same time? If so,
> we're back to the question of how to identify them. I wonder whether the
> produced binaries are significantly different in these
> cases - like, do they happen to have different C++ ABI?

The binaries I am told on the clang development mailing list are the 
same but the one built with vc++ defaults to vc++ mode as the -target 
while the one built with mingw/gcc defaults to gcc/mingw mode as the 
target. Obviously an end-user could choose to build clang in both modes 
in different places, so in choosing one or the other he would not need 
to specify the -target option.

>
>> Thoughts ? Ideas ?
>>
>> Whatever Boost Build decides to do I probably need some help
>> implementing the solution in bjam language. I have added to 'develop' the
>> clang-win.jam file, but it currently never gets invoked because the
>> change I have locally to invoke it in clang.jam precludes the mingw/gcc
>> mode of clang for Windows. I also have a local change to common.jam
>> which also precludes the possibility of mingw/gcc mode in Windows.
>> Solving this problem of supporting both vc++ and mingw/gcc mode for
>> clang under Windows is essential if we are going to support it in
>> Windows as well as in the MacOS and Linux.
>
> While my schedule is just as unpredictable as usual, I do have some
> extra interest in clang support these days, so hopefully we'll figure
> things out.

That would be great ! See my reply to the other thread about the files I 
have added to 'develop' to provisionally support clang on Windows.

The latest clang on Windows built with vc++ finally solves the RTTI and 
exception handling problems which kept the vc++ emulation from working 
when testing against Boost libraries. I am still struggling to build 
clang on Windows using mingw/gcc but when I do I will test it out and 
see if it now supports multithreading correctly. I do think that the 
clang developers have done good work in supporting clang on Windows and 
that Boost Build should support it also.