Subject: Re: [boost] [log] [asio] Conflicting default configs
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2015-03-31 11:14:30
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
> 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
> 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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk