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-21 01:16:52

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 ).

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++.