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:platformwin : 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