Re: [boost] [build] Default compiler options for a toolset

Subject: Re: [boost] [build] Default compiler options for a toolset
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-11-20 17:33:33

On 11/20/2013 5:12 PM, Gavin Lambert wrote:
> On 20/11/2013 18:49, Quoth Edward Diener:
>> In a clang-win.jam toolset created by someone else and posted on the
>> Boost Build forum, the toolset flags are inherited from msvc. This was
>> created for clang-cl under Windows using the VC++ RTL. However there is
>> no supported /EH(x) like option for this clang-cl compiler. How can I
>> disable the command line from propagating this option entirely ? I do
>> not know what clang-cl uses for the various <exception-handling>,
>> <asynch-exceptions>, or <extern-c-nothrow> combinations, but the
>> compiler works fine without the clang-cl equivalent, whatever it is, of
>> VC++ /EH(x) being set. Nonetheless I want to remove this when using the
>> clang-win.jan file since the non-support of /EH(x) in clang-cl causes
>> repeated warning messages for each test compiled. Is there any easy way
>> to do this in the clang-win.jam toolset so basically no /EH(x) compiler
>> option is generated ?
>
> You probably shouldn't try to remove that.
>
> Eventually the clang folks will implement exception handling "properly"
> for Windows (since they're aiming for compatibility), and then
> presumably the warning will go away.  In the meantime, it's alerting you
> that it's not doing what MSVC would do, which might change behaviour.
> This is useful to know (and useful to know when that changes).

I disagree. When/if clang changes the particular jam file should change 
appropriately, but in the current situation there is no need to have a 
jamfile option which is unrecognized by clang and which it reports as 
unrecognized for every file being compiled. It just adds to unnecessary 
compiler output information when using Boost Build.

I am communicating to clang developers about this msvc option on their 
developers mailing list, so I am willing to keep up to date about this 
if clang does decide to support VC++'s /EH(x) options. So far the word 
is that they do not intend to emulate the option.

I just can't figure out how to override it in the clang-win.jam file so 
that it does not pass an '/EH(x)' setting to clang-cl. It is Boost 
Build/bjam voodoo which to me is unnecessarily complicated but to Boost 
Build developers must be as clear as air.

The major showstopper still with clang using VC++ RTL on Windows is that 
clang-cl does not support RTTI, meaning it always gives an error 
whenever a compile includes 'typeinfo' ( or 'typeinfo.h' ). But that is 
another problem which a bug fix should eventually solve.