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.
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 ?
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 ] ; }
Thanks, I will give it a try.
The major showstopper still with clang using VC++ RTL on Windows is that clang-cl does not support RTTI, meaning it always gives an error whenever a compile includes 'typeinfo' ( or 'typeinfo.h' ). But that is another problem which a bug fix should eventually solve.