ENH: bump boost-headers-only to 1.80.0

[mckib2]

Reference issue

• Closes ENH: Bump boost.math version #15136

What does this implement/fix?

• upgrades Boost 1.75.0 -> 1.80.0

Additional information

• FreeBSD patch may need to be remade

[tupui]

I think this is a leftover from local tests?

[mckib2]

This will need to be changed -- doing some testing to see if we can jump straight to Boost 1.80.0

EDIT: see scipy/boost-headers-only#10

[mckib2]

@h-vetinari CI failure here looks unrelated to Boost changes -- no rush, but if you have a chance to look at impacts to conda-forge and it works, besides the OpenBSD/FreeBSD patch and updating scipy/boost-headers-only, this might be ready to go

[andyfaff]

Could you rebase on main? There are several CI fails on macosx_arm64 that I'm hoping my get fixed by this PR. The CI infrastructure isn't present yet in your branch.

[mckib2]

Could you rebase on main? There are several CI fails on macosx_arm64 that I'm hoping my get fixed by this PR. The CI infrastructure isn't present yet in your branch.

Should have latest main now as well as latest upstream patch for M1 compiler bug

[mdhaber]

Do I understand that this will fix gh-14901? Any chance it also fixes gh-17101?

[andyfaff]

It doesn't fix the issues we're seeing on macosx_arm64 on cirrus.

[mborland]

Do I understand that this will fix gh-14901? Any chance it also fixes gh-17101?

These should both be fixed in Boost 1.81.0.

#14901 was fixed with boostorg/math#827
#17101 will be fixed with boostorg/math#846

[mdhaber]

It looks like gh-17146 is fixed by boostorg/math#847, too. Thanks @mborland!

Do you think we can get 1.81 before SciPy 1.10.0 releases, @mckib2?

[mborland]

It looks like gh-17146 is fixed by boostorg/math#847, too. Thanks @mborland!

Do you think we can get 1.81 before SciPy 1.10.0 releases, @mckib2?

Boost 1.81 is scheduled to release the 14 of December. Do you use the standalone version of Boost.Math, or the Boost super project? If you are using the standalone we can cut a 1.80.1 in the event 1.81 doesn't meet your timeline.

[mckib2]

We have been generating headers from the "regular" Boost distribution which includes most of the super-project. I believe we did it this way as we thought we might anticipate using other Boost libraries, but I don't think that's a huge concern for us now. Boost.Math is really all we need.

@mdhaber @rgommers Is it worth the small refactor in scipy/boost-headers-only to use the standalone version of Boost.Math? It's unclear to me if anyone else is now relying on that repo to provide more than just Boost.Math.

[mdhaber]

Anyone else in SciPy? I don't think so. I think you reviewed the only other use of Boost in SciPy that I know of, which is (presumably Math) in scipy.special.

[rgommers]

@mdhaber @rgommers Is it worth the small refactor in scipy/boost-headers-only to use the standalone version of Boost.Math? It's unclear to me if anyone else is now relying on that repo to provide more than just Boost.Math.

That does sound like a good idea to me - smaller checkouts, and more flexible in terms of releases it looks like.

No one else should be relying on that repo, and in case they do they can just fork it and do their own thing. This is meant for SciPy only.

One thing to keep in mind is to not lose the old commits in the boost-headers-only repo. It can be a disconnected commit history in the main branch though.

[mdhaber]

Please revert as much of gh-17272 as possible when this PR gets merged.

[mckib2]

If we use the standalone version of Boost.Math, we may no longer need the machinery around the Boost headers-only repo. In this case, closing this PR in favor of gh-17432 which includes Boost.Math directly

[mdhaber]

On the other hand, we've discussed using additional parts of Boost, like the odeint and polygon. Would these still be available with gh-17432?

[rgommers]

It can always be reverted. Boost is huge, so adding a dependency on more of it probably needs a separate conversation. Looking at those topics, it also seems that those may not materialize. scipy.integrate gets very little attention, and polygon would be for scipy.spatial I guess? We also have no owner for QHull there at the moment.

[mborland]

gh-17432

No. There are precious few Boost libraries that support their own standalone mode. For most you need the whole monolith (which is one of the most common complaints against Boost). While not a complete replacement for Boost.Odeint if you are looking to expand scipy.integrate we have quadrature inside of Boost.Math written by @NAThompson. It is also more actively maintained.