coming in boost 1.66

coming in boost 1.66

[Casey Bodley]

There are a couple of interesting changes in the upcoming boost 1.66 
release, based on the work-in-progress release notes: 
http://www.boost.org/users/history/in_progress.html

- the Beast library was accepted into boost earlier this year, and 1.66 
will be its first release. We're currently including it in a submodule, 
so we'll need to come up with a strategy to transition.
- the Asio library is getting "interface changes to reflect the 
Networking TS" (which is awesome!) but we might see some compilation 
failures in radosgw as a result.

Now that we have the tooling to build specific boost versions, how do 
people feel about forcing the update to 1.66 once we've got it tested? 
This could avoid the extra work needed to a) maintain the beast 
submodule alongside boost's, and b) work around any hypothetical api 
breakage in asio. Once 1.66 is out, we'll have a better idea how much 
work that actually requires, but I wanted to float the idea ahead of time.

Casey

Re: coming in boost 1.66

[Jesse Williamson]

On Mon, 27 Nov 2017, Casey Bodley wrote:

> - the Asio library is getting "interface changes to reflect the Networking 
> TS" (which is awesome!) but we might see some compilation failures in radosgw 
> as a result.

Very cool! IMO the Networking TS makes some worthwhile improvements, this 
is great news.

> is out, we'll have a better idea how much work that actually requires, but I 
> wanted to float the idea ahead of time.

+1 for doing it.

-Jesse

Re: coming in boost 1.66

[Casey Bodley]

On 11/27/2017 11:03 AM, Casey Bodley wrote:
> There are a couple of interesting changes in the upcoming boost 1.66 
> release, based on the work-in-progress release notes: 
> http://www.boost.org/users/history/in_progress.html
>
> - the Beast library was accepted into boost earlier this year, and 
> 1.66 will be its first release. We're currently including it in a 
> submodule, so we'll need to come up with a strategy to transition.
> - the Asio library is getting "interface changes to reflect the 
> Networking TS" (which is awesome!) but we might see some compilation 
> failures in radosgw as a result.
>
> Now that we have the tooling to build specific boost versions, how do 
> people feel about forcing the update to 1.66 once we've got it tested? 
> This could avoid the extra work needed to a) maintain the beast 
> submodule alongside boost's, and b) work around any hypothetical api 
> breakage in asio. Once 1.66 is out, we'll have a better idea how much 
> work that actually requires, but I wanted to float the idea ahead of 
> time.
>
> Casey

Boost 1.66 was released yesterday! The boost::beast changes were minimal 
(only one function name changed), but the changes to boost::asio were 
extensive and necessitated major changes to my PR for librados bindings 
at https://github.com/ceph/ceph/pull/19054. So I'm still proposing that 
we pin our boost dependency at 1.66 to avoid #ifdefs and build hackery 
to continue supporting earlier versions. That PR includes the cmake 
changes to do this, though I'm happy to pull those into a separate PR if 
necessary.

Casey

Re: coming in boost 1.66

[Casey Bodley]

On 12/19/2017 01:56 PM, Casey Bodley wrote:
>
> On 11/27/2017 11:03 AM, Casey Bodley wrote:
>> There are a couple of interesting changes in the upcoming boost 1.66 
>> release, based on the work-in-progress release notes: 
>> http://www.boost.org/users/history/in_progress.html
>>
>> - the Beast library was accepted into boost earlier this year, and 
>> 1.66 will be its first release. We're currently including it in a 
>> submodule, so we'll need to come up with a strategy to transition.
>> - the Asio library is getting "interface changes to reflect the 
>> Networking TS" (which is awesome!) but we might see some compilation 
>> failures in radosgw as a result.
>>
>> Now that we have the tooling to build specific boost versions, how do 
>> people feel about forcing the update to 1.66 once we've got it 
>> tested? This could avoid the extra work needed to a) maintain the 
>> beast submodule alongside boost's, and b) work around any 
>> hypothetical api breakage in asio. Once 1.66 is out, we'll have a 
>> better idea how much work that actually requires, but I wanted to 
>> float the idea ahead of time.
>>
>> Casey
>
> Boost 1.66 was released yesterday! The boost::beast changes were 
> minimal (only one function name changed), but the changes to 
> boost::asio were extensive and necessitated major changes to my PR for 
> librados bindings at https://github.com/ceph/ceph/pull/19054. So I'm 
> still proposing that we pin our boost dependency at 1.66 to avoid 
> #ifdefs and build hackery to continue supporting earlier versions. 
> That PR includes the cmake changes to do this, though I'm happy to 
> pull those into a separate PR if necessary.
>
> Casey

It looks like part of updating the default boost version in cmake is to 
mirror that boost tarball on download.ceph.com (iirc this was because of 
sourceforge downtime). Could someone with access please upload a copy of 
https://dl.bintray.com/boostorg/release/1.66.0/source/boost_1_66_0.tar.bz2 
so that it's available under download.ceph.com/qa/? You can see 
https://github.com/ceph/ceph/pull/19054/files#r157844349 for the 
relevant cmake logic.

Thanks,
Casey