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-12-05 02:32:08

On 11/21/2013 2:42 AM, Vladimir Prus wrote:
> On 21.11.2013 10:16, Edward Diener wrote:
>> On 11/21/2013 12:30 AM, Vladimir Prus wrote:
>>> On 21.11.2013 05:42, Edward Diener wrote:
>>>> On 11/20/2013 6:59 PM, Gavin Lambert wrote:
>>>>> On 21/11/2013 12:33, Quoth Edward Diener:
>>>>>> I did not think I was removing them, justy changing them to
>>>>>> produce no
>>>>>> compiler option. It seems a flaw in the system that one cannot
>>>>>> specify
>>>>>> generating no compiler option for some Boost Build option(s). What do
>>>>>> you do when some compiler has no equivalent compiler option for a
>>>>>> Boost
>>>>>> Build option ?
>>>>>
>>>>> You don't specify it in the first place.
>>>>>
>>>>> The problem you're having is because your jamfile is including the
>>>>> msvc
>>>>> jamfile, but the compiler is not 100% msvc compliant.
>>>>>
>>>>> Another way you could have done it would have been to copy the msvc
>>>>> file
>>>>> and edit it to match the real capabilities of clang-win, instead of
>>>>> including the msvc file.
>>>>
>>>> You may be right about this but someone else created the jam file, not
>>>> me. I am just trying to modify it. OTOH inheriting flags from msvc
>>>> seems logically much cleaner than having to duplicate them, or even
>>>> duplicate almost all of them.
>>>
>>> toolset.inherit is defined like this:
>>>
>>>      rule inherit ( toolset : base )
>>>      {
>>>          import $(base) ;
>>>          inherit-generators $(toolset) : $(base) ;
>>>          inherit-flags      $(toolset) : $(base) ;
>>>          inherit-rules      $(toolset) : $(base) ;
>>>      }
>>>
>>> You probably can do what clang-darwin does - don't call toolset.inherit,
>>> call these 3 functions directly, and then note this
>>> comment for inherit-flags:
>>>
>>>      # Brings all flag definitions from the 'base' toolset into the
>>> 'toolset'
>>>      # toolset. Flag definitions whose conditions make use of
>>> properties in
>>>      # 'prohibited-properties' are ignored. Do not confuse property and
>>> feature, for
>>>      # example <debug-symbols>on and <debug-symbols>off, so blocking one
>>> of them does
>>>      # not block the other one.
>>>      #
>>>      # The flag conditions are not altered at all, so if a condition
>>> includes a name,
>>>      # or version of a base toolset, it will not ever match the
>>> inheriting toolset.
>>>      # When such flag settings must be inherited, define a rule in base
>>> toolset
>>>      # module and call it as needed.
>>>      #
>>>      rule inherit-flags ( toolset : base : prohibited-properties * :
>>> prohibited-vars * )
>>>
>>> So, if clang on windows does not have any particular options for
>>> exception handling you would use:
>>>
>>>      toolset.inherit-flags clang-win : msvc : <exception-handling>on ;
>>>
>>> or maybe
>>>
>>>      toolset.inherit-flags clang-win : msvc : <asynch-exceptions>off
>>> <asynch-exceptions>on ;
>>
>> First of all the toolset was uploaded as an attachment to a message in
>> the Boost Build mailing list by 'tr1gun' in reply to a message he
>> started on that list called 'Clang windows toolset.
>>
>> The toolset jam file does does have these lines:
>>
>> toolset.inherit-generators clang-win <toolset>clang
>> <toolset-clang:platform>win : msvc ;
>> toolset.inherit-flags clang-win : msvc :
>> <debug-symbols>on/<debug-store>object  : YLOPTION ;
>> toolset.inherit-rules clang-win : msvc ;
>>
>> The issue is that clang does not support any /EH(x) option of msvc and
>> I am trying to change it so that option is not generated when using
>> the clang-win toolset is used to compile ( clang-cl ).
>
> So what if you add
>
>      <asynch-exceptions>off <asynch-exceptions>on
>
> to inherit-flags invocation above?

That works ! Thanks for the solution to the problem of eliminating 
/EH(x) from the clang using VC++ RTL tests.