Boost logo

Boost :

Subject: Re: [boost] [build] Default compiler options for a toolset
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-11-24 23:54:32

On 11/20/2013 6:29 PM, Steven Watanabe wrote:
> On 11/20/2013 02:33 PM, Edward Diener wrote:
>> I just can't figure out how to override it in the clang-win.jam file so
>> that it does not pass an '/EH(x)' setting to clang-cl. It is Boost
>> Build/bjam voodoo which to me is unnecessarily complicated but to Boost
>> Build developers must be as clear as air.
> The system isn't designed for this. toolset.flags only
> allows options to be added. They can't be removed.
> It is possible to fix the flags manually, but it's
> a hack:
> rule compile.c++ ( targets * : sources * : properties * )
> {
> C++FLAGS on $(targets) = [ set.difference
> [ on $(targets[1]) return $(C++FLAGS) ] :
> /EHs ] ;
> }

I had successfully added the above to my local clang-win.jam file.

While this works when compiling with clang to remove the /EHs option,
when I have a 'run' action, as opposed to a 'compile' or 'compile-fail'
action, no compile takes place at all but the 'run' action attempts to
do a link without a compile, and of course it fails because the object
file it is looking for does not exist.

Is there something else I need to add to my clang-win.jam file so that
the compile is done before the link when a 'run' action is encountered ?

Without the rule above being added to my clang-win.jam file a 'run'
action does attempt a compile before it does the link, but of course the
compile now uses the obsolete for clang /EHs compile flag.

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