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

Subject: Re: [boost] [build] Default compiler options for a toolset
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-11-21 02:42:08

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?

>
> Luckily the "hack" which Steve Watanabe showed me in reply to another message on this thread does work to eliminate any /EH(x) option.
>
>>
>>
>> Note that I can't find clang-win anywhere on trunk, but presumably after
>> we switch to git there will be some pull request?
>
> It is not on trunk or anywhere, except as an attachment in the aforementioned Boost Build thread mentioned above. I made a previous appeal
> on the Boost Build mailing list for a Boost Build implementation of clang on Windows using VC++ but no one responded. Then 'tr1gun'
> responded with his implementation and I have been using it locally to test out clang on Windows using VC++.

It seems normal process to me, really - except that eventually, somebody should propose this for inclusion, hopefully when clang on Windows
is part of regression testing matrix.

- Volodya