- Boost - lists.preview.boost.org

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

[serialization][release][teeks99] All MSVC tests for Boost.Serialization failing?
by Joaquín M Lopez Munoz 31 Mar '15

31 Mar '15

Hi All teeks99-* regression tests for Boost.Serialization in MSVC compilers appear as failing, yet when one clicks on any the information seems to indicate nothing went wrong: http://tinyurl.com/nf5bd9a Any clue? Thank you Joaquín M López Muñoz Telefónica

3 4

Transferring a library on Github
by Edward Diener 31 Mar '15

31 Mar '15

In order to get VMD under boostorg in order to begin the process of integrating the library into Boost for the release after the current pending one I tried to transfer the library as explained on the page https://svn.boost.org/trac/boost/wiki/NewLibFromGit. But I do not have the necessary admin rights for boostorg. How do I proceed ? I want to get VMD under boostorg and then do whatever is necessary to add it to the superproject and have it part of for regression testing.

2 4

[detail] Bug in is_postfix_incrementable
by Edward Diener 31 Mar '15

31 Mar '15

There is a rather bad bug in is_postfix_incrementable in the detail/is_incrementable.hpp header file. I noticed this when I was looking at how I can remove the dependncies in is_incrementable.hpp on the deprecated Type_traits header files in Version2 of type_traits. The bug looks totally obvious to me. It's that the is_postfix_incrementable metafunction is derived from the is_incrementable_::impl<T> implementation rather than the is_incrementable_::postfix_impl<T> implementation. I am sure this was just a copy-paste problem but evidently has been in the header file from the beginning. Can we fast forward the simple fix to the new release ? I posted this just to be sure I haven't missed anything in the file. I believe that only the iterator library currently uses the is_incrementable and is_postfix_incrementable metafunctions in its tests. Since it is Boost detail no end-user should be using it. Still we should have it correct, shouldn't we, in our release ?

1 0

Conflicts when building libraries at root
by Peter Dimov 31 Mar '15

31 Mar '15

On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get error: Name clash for '<pstage\lib>libboost_system-vc80-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on When I add --without-context --without-coroutine, I now get error: Name clash for '<pstage\lib>libboost_system-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>off error: - <asynch-exceptions>on So I add --without-test. error: Name clash for '<pstage\lib>libboost_timer-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>on <library>object(file-target)@10959 error: - <asynch-exceptions>off <library>object(file-target)@9953 Now where did _that_ come from. :-) Ah. --without-endian. Builds now. This is perhaps old news for some, but it looks like it doesn't play well with our simple build instructions. Or maybe it doesn't occur on the master branch, so we don't care? I haven't checked yet. It's also perhaps an indication of a deeper problem. I can use b2 --with-test and have 'test' built; it builds its dependencies (system, chrono and timer) with <asynch-exceptions>on in bin.v2, and if I use it from within Boost.Build, it will link to them. But if I stage (or install) Boost.Test, and then stage or install Boost.System separately, Boost.System will be built with <asynch-exceptions>off. So the library user who just has headers and binaries will link those, potentially creating a conflict, which may in this case be benign. Or not.

12 55

[Container] const boost::container::vector is mutable??
by Eric Niebler 31 Mar '15

31 Mar '15

Why are the elements of a const boost::vector mutable through its const_iterator? #include <boost/container/vector.hpp> int main() { using C = boost::container::vector<int>; C c{1,2,3,4}; C const & r = c; r[0] = 42; // Error, good. *r.begin() = 42; // Compiles! huh?? } -- Eric Niebler Boost.org http://www.boost.org

2 3

how to contact iterator developers
by Claas H. Koehler 31 Mar '15

31 Mar '15

Hi! About a week ago I sent a question about a specific bug to the iterator developers via this list and haven't received any feedback yet. Is this list not the right place to ask such questions or are there currently no active iterator developers managing the project ? Regards Claas

3 3