Le 16/03/15 17:51, Vladimir Prus a écrit :
On 03/16/2015 03:19 PM, John Maddock wrote:
I'm not at all sure this is the right fix: I believe Boost.Test really does need asynch-exception support turned on to work it's magic.
In that thread, Gennadiy say it does not need that from Boost.System, that it only needs client to set that. It's not quite clear whether Boost.Test itself should be built with that or not.
This is not exactly what I understood from "I am sure execution_monitor.cpp needs it." (http://lists.boost.org/Archives/boost/2015/03/220493.php)
Anyway, my primary point, if you allow a bit of ranting, is that it's clearly Boost.Test that tries to use custom settings that cause issues, but the people who appear to care most are Jürgen and Paul and you and I, neither of whom are Boost.Test maintainers. That's not really productive. So with this change, it's up to Boost.Test maintainers to do whatever is right, which might be updating documentation, or using just explicit /EHa cflags, or something else.
It looks to me that now several libraries are trying to do that as well, and to me everything is related to the fact that, at some point, a chain of dependency reaches boost.system with different and conflicting options. So even if a user code uses boost.test in header mode (in order to have its options handled properly), this code would link at some point with boost.system with potentially conflicting options. This lead me to think that the issue is not only related to boost.test, but rather in any compiled library that would be linked against a client code with specific options conflicting with boost.system. The case of boost.test is just an example of the client code that might use boost.system. Or maybe I am missing something there? Best, Raffi PS.: sorry for not being pro-active in the list, but neither Gennadiy nor myself came up with a clear status on this issue.