Re: [boost] [log] [asio] Conflicting default configs

Subject: Re: [boost] [log] [asio] Conflicting default configs
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2015-03-31 11:14:30

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