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-12-09 03:07:52

On 12/8/2013 11:16 PM, Vladimir Prus wrote:
> 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: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 ).
>>>>
>>>> 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.

You can clone the repository with my changes at 'develop' from 
https://github.com/eldiener/build.git. You will need to build clang on 
Window using VC++ RTL in order to test out clang using clang-cl. My 
user-config.jam line for clang is:

using clang : 3.4 : 
C:/Programming/VersionControl/bclang/bin/Release/clang-cl.exe : 
<cxxflags>"/D_HAS_EXCEPTIONS=0 /D_STATIC_CPPLIB /GR-" <compatibility>vc11 ;

You can build the latest clang-cl etc. by following the instructions at 
http://clang.llvm.org/get_started.html and using Visual Studio to build 
everything. You will also need the free Visual Stusio Express to build 
everything.

Using clang-cl still has compiler problems when typeinfo is included. I 
have already informed the clang developers of this via a bug report. But 
it would still be very nice if we could have an official toolset for it 
in Boost Build. More info about running clang-cl is at 
http://clang.llvm.org/docs/UsersManual.html#clang-cl .