boost @1.59.0 Update to to 1.60.0

[crmoore (Chris Moore)]

Upstream available here: ​http://www.boost.org/users/history/version_1_60_0.html

[ryandesign (Ryan Carsten Schmidt)]

I'm aware this is available, but haven't done it because it might mean needing to revbump all ports that use boost, and that takes a lot of time to do and test.

[mouse07410 (Mouse)]

So far in my experience all the boost upgrades (tracking from 1.52) went pretty well. Thus there's a good chance that most of the ports depending on boost won't need to be changed. (Or am I missing something?)

Speaking of which, boost-1.56 broke uniform_real_distribution for multi-precision (see ​https://svn.boost.org/trac/boost/ticket/10364). Perhaps you could integrate the proposed commit ​https://github.com/boostorg/random/commit/d4514f1e075f43e5ea7b754529740442d091b6fe to fix this problem?

Thanks!

[ryandesign (Ryan Carsten Schmidt)]

Replying to uri@…:

So far in my experience all the boost upgrades (tracking from 1.52) went pretty well. Thus there's a good chance that most of the ports depending on boost won't need to be changed. (Or am I missing something?)

Many, even most, prior boost updates have broken some ports. This is because the developers of boost do not appear to consider backward compatibility a priority and frequently make breaking changes. They also do not assign library version numbers, so it is not possible to tell at a glance when such breakage has occurred. In the past, I've simply updated the boost port, leaving it to the users and maintainers of ports that use boost to discover and fix any breakage. This is a bad user experience. So before I commit a boost update, I would like to verify that a number of popular ports that use boost at least still compile, and ideally still work, however I don't have time for such testing right now.

Speaking of which, boost-1.56 broke uniform_real_distribution for multi-precision (see ​https://svn.boost.org/trac/boost/ticket/10364). Perhaps you could integrate the proposed commit ​https://github.com/boostorg/random/commit/d4514f1e075f43e5ea7b754529740442d091b6fe to fix this problem?

Looks like that commit is in 1.60, so that will solve itself once we update.

[mouse07410 (Mouse)]

I understand. Hope you would find time rather sooner than later. ;-)

Looks like that commit is in 1.60, so that will solve itself once we update.

Well, I bit the bullet and built a local boost_1_60_0 (leaving other packages to use the Macports 1_59_0 in /opt/local). So far I don't see success. You can see the details on the boost ticket tracker (URL in the previous post).

One more point. It looks like the -mt suffix has been discontinued by boost since 1.42, and the standard boost build does not append it, creating libraries named like libboost_system.a rather than libboost_system-mt.a. This -mt suffix confuses auto configuration applications such as cmake - they claim they can't find boost libraries. While I personally hate cmake, I'd rather that it worked on my system with packages I'm trying to install. So could I ask to abolish this -mt business and just build the libraries thread-safe? Thanks!

[mouse07410 (Mouse)]

Also, it looks like some libraries are not built static and dynamic, but dynamic only? Can I ask for an option to build both (static and dynamic) for all of the boost libraries?

[michaelld (Michael Dickens)]

uri@…: Do you have a patch for this upgrade? I'd be happy to test local to my system before committing; many of my projects (in MP and not) use numerous Boost modules.

[michaelld (Michael Dickens)]

W/r.t. the "-mt" extension: Maybe we can do the build without it, but add in symlinks to that name for a few iterations of Boost updates. So long as the self-id is without it, then usage will slowly migrate to not using it on user's systems. Maybe then at 1.62 we can remove it altogether; or something like that.

[mouse07410 (Mouse)]

W/r.t. the "-mt" extension: Maybe we can do the build without it, but add in symlinks to that name for a few iterations of Boost updates.

I find it perfectly reasonable and agreeable.

​uri@ Do you have a patch for this upgrade? I'd be happy to test local to my system before committing; many of my projects (in MP and not) use numerous Boost modules.

Not sure I understand. I don't have a patch from Boost-1.59 to Boost-1.60. I do have the commit/patch that presumably fixed the problem I had with uniform_real_distribution<mpf_float_50>:

commit: ​https://github.com/boostorg/random/commit/d4514f1e075f43e5ea7b754529740442d091b6fe

patch: ​https://github.com/boostorg/random/commit/d4514f1e075f43e5ea7b754529740442d091b6fe.patch

[michaelld (Michael Dickens)]

I was going for a patch to the MacPorts Portfile associated with Boost, and then for anything else within Boost that might need to be patched in MP that have been patched in the source (like the one you list for uniform_real_distribution). As for the former, some patches within the Portfile have already been incorporated into the source, and some probably need tweaking to work correctly. I honestly haven't found time to try figuring out which patches are which; neither apparently has @ryandesign. Hence my question. If not that's OK too; we'll get there.

[mouse07410 (Mouse)]

Oh, I see. Let me take a look at the Portfile, and get back within a day or two if I find that I can handle the patch.

[mamoll (Mark Moll)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

This ticket is about updating boost to 1.60.0 only. Other changes should be proposed in other tickets.

Duplicate #50671 has a patch​ to update the port to 1.60.0.

Re: dropping the "-mt" suffix: See #44118 for why we're not doing that.

Re: static libraries: If you want them, disable the no_static variant, which is enabled by default.

[michaelld (Michael Dickens)]

Let's move this entire ticket to #50671, since it has the patches.