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 00:30:34

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 ;

Note that I can't find clang-win anywhere on trunk, but presumably after we switch to git there will be some pull request?

HTH,
Volodya