On 09.12.2013 01:03, Edward Diener wrote:
On 12/5/2013 2:32 AM, Edward Diener wrote:
On 11/21/2013 2:42 AM, Vladimir Prus wrote:
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?
That works ! Thanks for the solution to the problem of eliminating /EH(x) from the clang using VC++ RTL tests.
I spoke soo soon. Even with the above added to the inherit-flags invocation the command line still generates the /EHs option.
Can you fork the 'boostorg/build' repository on github, and put your changes to the develop branch thereof and then point to the commit? Otherwise it's hard to keep track of what changes are applied to which initial file. Thanks,