AMDG On 03/30/2015 04:54 PM, Andrey Semashev wrote:
1. Introduce an inline ABI namespace in Boost.ASIO, much like the one I have in Boost.Log. The namespace name would depend on BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION and other macros that affect binary compatibility. This would be my preferred solution, although I'm not sure how fast and easy it can be implemented.
2. Remove symbol visibility enforcement from Boost.ASIO, or at least make it optional. That way I could encapsulate my private copy of Boost.ASIO in Boost.Log binaries.
Both of these will tend to result in pointlessly duplicating ASIO.
3. Change the defaults, either in Boost.Log or in Boost.ASIO, so that they are aligned by default. When the user changes Boost.Log config he would be expected to know that Boost.ASIO config also needs to be changed accordingly. If he doesn't, Boost.Log is still built consistently with its own config. Note, however, that since Boost.Log is a built library and in most distributions it is built with default options, the choice for Boost.Log is more significant and because of that should probably be more conservative.
4. Same as 3 but also remove the enforcement of Boost.ASIO config by Boost.Log. Whenever the user wants to change the default, he would have to define macros for the both libraries, otherwise Boost.Log can be built inconsistently.
5. Do not change the defaults but remove the config enforcement. BOOST_LOG_USE_COMPILER_TLS becomes Boost.Log-local and as such does not guarantee that the resulting binaries do not in fact use compiler-based TLS. Users can get surprised.
I don't think that libraries should set configuration options for other libraries.
6. Do not change anything, let the users suffer because of ODR issues. Maybe document this somewhere...
In Christ, Steven Watanabe