On 11/20/2013 6:29 PM, Steven Watanabe wrote:
AMDG
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.