Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at