[Release managers] Permission to rollback Boost.Thread breaking changes
Hi, I would like to apply the following patch to trunk and release branch to avoid the Boost.Thread breaking changes. * [@http://svn.boost.org/trac/boost/ticket/6229 #6229] Rename the unique_future to future following the c++11. * [@http://svn.boost.org/trac/boost/ticket/6266 #6266] Breaking change: thread destructor should call terminate if joinable. * [@http://svn.boost.org/trac/boost/ticket/6269 #6269] Breaking change: thread move assignment should call terminate if joinable. This will let us the time to discuss the best way to manage with this breaking changes. Is someone against this late change? Best, Vicente svn diff boost/thread libs/thread Index: boost/thread/detail/config.hpp =================================================================== --- boost/thread/detail/config.hpp (revision 82295) +++ boost/thread/detail/config.hpp (working copy) @@ -78,9 +78,9 @@ #define BOOST_THREAD_RVALUE_REFERENCES_DONT_MATCH_FUNTION_PTR #endif -// Default version is 3 +// Default version #if !defined BOOST_THREAD_VERSION -#define BOOST_THREAD_VERSION 3 +#define BOOST_THREAD_VERSION 2 #else #if BOOST_THREAD_VERSION!=2 && BOOST_THREAD_VERSION!=3 && BOOST_THREAD_VERSION!=4 #error "BOOST_THREAD_VERSION must be 2, 3 or 4" Index: libs/thread/src/win32/thread.cpp =================================================================== --- libs/thread/src/win32/thread.cpp (revision 82295) +++ libs/thread/src/win32/thread.cpp (working copy) @@ -12,7 +12,7 @@ #ifndef WINVER #define WINVER 0x400 #endif -#define BOOST_THREAD_VERSION 3 +//#define BOOST_THREAD_VERSION 3 #include <boost/thread/thread.hpp> #include <boost/thread/once.hpp> Index: libs/thread/src/pthread/thread.cpp =================================================================== --- libs/thread/src/pthread/thread.cpp (revision 82295) +++ libs/thread/src/pthread/thread.cpp (working copy) @@ -6,7 +6,7 @@ // Distributed under the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -#define BOOST_THREAD_VERSION 3 +//#define BOOST_THREAD_VERSION 3 #include <boost/thread/detail/config.hpp> #include <boost/thread/thread.hpp>
On 31 December 2012 10:25, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi,
I would like to apply the following patch to trunk and release branch to avoid the Boost.Thread breaking changes.
You should apply a patch to trunk before asking to add it to release. I'll provisionally say to do it, but wait to see if any of the other release managers have an opinion. Shouldn't there be a documentation change as well?
Le 31/12/12 14:50, Daniel James a écrit :
On 31 December 2012 10:25, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi,
I would like to apply the following patch to trunk and release branch to avoid the Boost.Thread breaking changes. You should apply a patch to trunk before asking to add it to release. I'll provisionally say to do it, but wait to see if any of the other release managers have an opinion. Committed revision 82302. I will merge tomorrow if it is time yet.
Shouldn't there be a documentation change as well?
Yes, for the time been I've identified to comment in the history the breaking change. I have no time today to look for more doc changes. Best, Vicente Index: libs/thread/doc/changes.qbk =================================================================== --- libs/thread/doc/changes.qbk (revision 82295) +++ libs/thread/doc/changes.qbk (working copy) @@ -10,11 +10,13 @@ [heading Version 4.0.0 - boost 1.53] +[/ [*Breaking changes:] [warning BOOST_THREAD_VERSION==3 by default since Boost 1.53. So that all the deprecated features since 1.50 are not included by default. You can change this by setting the appropriated define (see Configuration section). ] +] [*Deprecated features:]
Le 31/12/12 16:13, Vicente J. Botet Escriba a écrit :
Le 31/12/12 14:50, Daniel James a écrit :
On 31 December 2012 10:25, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi,
I would like to apply the following patch to trunk and release branch to avoid the Boost.Thread breaking changes. You should apply a patch to trunk before asking to add it to release. I'll provisionally say to do it, but wait to see if any of the other release managers have an opinion. Committed revision 82302. I will merge tomorrow if it is time yet.
Hi, could I merge this change? Best, Vicente
On 2 January 2013 14:19, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi, could I merge this change?
Yes, go ahead. Btw. looking at the test results, some easy (maybe?) fixes: If vacpp isn't supported, then it should be marked up as such. This error looks valid, lock_guard doesn't seem to be movable or copyable: http://www.boost.org/development/tests/trunk/developer/output/Sandia-darwin-... This test fails because make_unique_locks is only available when std::tuple is available, it should check that BOOST_NO_CXX11_HDR_TUPLE is not defined (or maybe use boost::tuple instead?): http://www.boost.org/development/tests/trunk/developer/teeks99-1a-win7-32on6...
Le 02/01/13 16:10, Daniel James a écrit :
On 2 January 2013 14:19, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi, could I merge this change? Yes, go ahead.
Thanks, done at https://svn.boost.org/trac/boost/changeset/82320.
Btw. looking at the test results, some easy (maybe?) fixes:
If vacpp isn't supported, then it should be marked up as such.
This platform was supported and now it fails without error Test output: Rev 82302 / Mon, 31 Dec 2012 15:49:37 +0000 *Report Time: *Wed, 2 Jan 2013 16:06:49 +0000 Compile [2013-01-01 05:04:38 UTC]: succeed xlC -F:xlC_r -c -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -qcpluscmt -qNOOPTimize -qnoinline -qfullpath -qfuncsect -qeh -qrtti -qxflag=EnableIssue214PartialOrdering:MangleCVOnTemplateTypeArgs:IgnoreCvOnTopOfFunctionTypes:FunctionCVTmplArgDeduction2011 -D__IBM_ALLOW_OVERRIDE_PLACEMENT_NEW -D__IBMCPP_NO_C99_FPCLASSIFY_MACROS__ -D__IBMCPP_NO_C99_FPCOMPARISON_MACROS__ -I".." -o "/nfs/sparky/home/montana/boost_NEW/boost-CVS/121.aix/results/boost/bin.v2/libs/thread/build/vacpp-12.1.0.1/debug/threading-multi/future.o" "../libs/thread/src/future.cpp"
This error looks valid, lock_guard doesn't seem to be movable or copyable:
http://www.boost.org/development/tests/trunk/developer/output/Sandia-darwin-...
I have fixed it as for https://svn.boost.org/trac/boost/changeset/82311. The problem is that config file doesn't defines BOOST_NO_CXX11_HDR_INITIALIZER_LIST for gcc 4.4 and 4.5 even if the feature is incomplete as the private overload is taken instead of the initializer list overload. The tester that have run after this change show that there is no error anymore.
This test fails because make_unique_locks is only available when std::tuple is available, it should check that BOOST_NO_CXX11_HDR_TUPLE is not defined (or maybe use boost::tuple instead?):
http://www.boost.org/development/tests/trunk/developer/teeks99-1a-win7-32on6... Fixed already with https://svn.boost.org/trac/boost/changeset/82317. See tester teeks99-1a-win7-32on64 <http://www.boost.org/development/tests/trunk/teeks99-1a-win7-32on64.html>.
It is OK to merge both fixes? Best, Vicente
On 2 January 2013 17:24, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 02/01/13 16:10, Daniel James a écrit :
If vacpp isn't supported, then it should be marked up as such.
This platform was supported and now it fails without error
Ah, right. Maybe try asking on the testing list sometime?
I have fixed it as for https://svn.boost.org/trac/boost/changeset/82311. The problem is that config file doesn't defines BOOST_NO_CXX11_HDR_INITIALIZER_LIST for gcc 4.4 and 4.5 even if the feature is incomplete as the private overload is taken instead of the initializer list overload. The tester that have run after this change show that there is no error anymore.
OK, I see, I'm not totally up to date on the unified initialization stuff. I think you should be using the BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX macro in addition to BOOST_NO_CXX11_HDR_INITIALIZER_LIST, rather than checking the gcc version.
Fixed already with https://svn.boost.org/trac/boost/changeset/82317. See tester teeks99-1a-win7-32on64 <http://www.boost.org/development/tests/trunk/teeks99-1a-win7-32on64.html>.
It is OK to merge both fixes?
No, wait until the beta is out. I was just going through the test results to see if there was any reason not to merge.
Le 02/01/13 18:51, Daniel James a écrit :
On 2 January 2013 17:24, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 02/01/13 16:10, Daniel James a écrit :
If vacpp isn't supported, then it should be marked up as such. This platform was supported and now it fails without error Ah, right. Maybe try asking on the testing list sometime?
I have fixed it as for https://svn.boost.org/trac/boost/changeset/82311. The problem is that config file doesn't defines BOOST_NO_CXX11_HDR_INITIALIZER_LIST for gcc 4.4 and 4.5 even if the feature is incomplete as the private overload is taken instead of the initializer list overload. The tester that have run after this change show that there is no error anymore. OK, I see, I'm not totally up to date on the unified initialization stuff. I think you should be using the BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX macro in addition to BOOST_NO_CXX11_HDR_INITIALIZER_LIST, rather than checking the gcc version.
Thanks, I will try it.
Fixed already with https://svn.boost.org/trac/boost/changeset/82317. See tester teeks99-1a-win7-32on64 <http://www.boost.org/development/tests/trunk/teeks99-1a-win7-32on64.html>.
It is OK to merge both fixes? No, wait until the beta is out. I was just going through the test results to see if there was any reason not to merge.
No problem. I will prepare a new patch with your suggestion once the regression test pass for these versions. Best, Vicente
On 2 January 2013 23:48, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
No problem. I will prepare a new patch with your suggestion once the regression test pass for these versions.
We're going to have a second release candidate for the beta, so if your changes are ready, you can merge them now.
Le 04/01/13 19:06, Daniel James a écrit :
On 2 January 2013 23:48, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
No problem. I will prepare a new patch with your suggestion once the regression test pass for these versions. We're going to have a second release candidate for the beta, so if your changes are ready, you can merge them now.
Done. Committed revision 82356. Vicente
participants (2)
-
Daniel James -
Vicente J. Botet Escriba