April 2015 - Boost - lists.preview.boost.org

Boost 1.58.0rc1 release delayed
by Marshall Clow 01 Apr '15

01 Apr '15

Due to some problems in Boost.Test, and some unexpected doctor's visits (which delayed said problems getting fixed), the boost 1.58.0rc1 scheduled for today has been delayed until Friday. As a result, the "master" branch in git is still open for bug fixes (if they have been successfully tested on develop) and documentation fixes until 11:59 PM PDT Thursday night (4/2). Sorry for the delay. -- Marshall

2 1

what happened to the "tools/regression" directory - and the stuff in it?
by Robert Ramey 01 Apr '15

01 Apr '15

The tools in the tools/regression directory are critical to the testing of the serialization library on one's local machine. What happened to these. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/what-happened-to-the-tools-regression-di… Sent from the Boost - Dev mailing list archive at Nabble.com.

9 26

[boostorg/regression] Build instructions updated for developers local test reporting
by Beman Dawes 01 Apr '15

01 Apr '15

A README file has been added and index.html updated to aid developers wishing to use these tools for local testing. While these tools are not worthwhile for a small number of tests run against a single variant of a single compiler, they are invaluable for large test matrices. See develop branch at https://github.com/boostorg/regression HTH, --Beman

2 1

Test message testing gsoc-admin@boost.org, please ignore
by Niall Douglas 01 Apr '15

01 Apr '15

Second attempt at getting this to work ... --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015

1 0

[log] [asio] Conflicting default configs
by Andrey Semashev 01 Apr '15

01 Apr '15

Hi, In Boost.Log I'm using Boost.ASIO to implement network-based syslog backend. Boost.ASIO is used in the compiled part of Boost.Log and, obviously, can be used in the user's code as well. By default Boost.ASIO is header-only, so we basically have a copy of Boost.ASIO in Boost.Log and another copy in the user's app. In Boost.Log I have the option to enable compiler-based TLS at the library build stage (BOOST_LOG_USE_COMPILER_TLS macro), which is by default not enabled. In Boost.ASIO there is a similar option (BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION macro) but the feature is enabled by default. I want Boost.Log built libraries to actually respect the BOOST_LOG_USE_COMPILER_TLS option, so I define BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION internally when BOOST_LOG_USE_COMPILER_TLS is not defined. The problem is that Boost.ASIO changes implementation in an incompatible way when BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION is defined. It is further worsened by a recent change that makes all of Boost.ASIO symbols externally visible. Basically, this means hard to debug trouble on user's end, when different versions of Boost.ASIO (one from Boost.Log binaries and the other used by the user's code directly) are used at the same time. I'd like to ask community what is the preferred resolution of this situation (and possibly similar ones in the future). I can see several ways of tackling this: 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. 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. 6. Do not change anything, let the users suffer because of ODR issues. Maybe document this somewhere... Opinions?

5 11