BLD: Accelerate wheels for macOS 14+

[thalassemia]

What does this implement/fix?

Adds GHA jobs to build Accelerate wheels for macOS >= 14 as discussed in #19816 (comment).

Additional information

• Used the gfortran included with the runner images to build Accelerate wheels
• Bumped our x86 macOS OpenBLAS builds to use macos-12 (macos-11 is EOL)
• Tricked pip into installing and testing wheels targeting macOS >= 14 on the macOS 13 runner that built them (no free x86 runners on macOS 14) by renaming wheel during repair step and reverting name change after testing
  • These are the relevant issues for the failed tests:
    • BUG: test fail in scipy.optimize.tests.test_linprog.TestLinprogIPDense.test_bug_6139 #20216
    • BUG: Test failures from BLAS-flavour testing for 1.13 in conda-forge #20472
  • The failing tests were addressed by TST: Skip or fix some failing tests on certain macOS builds #20522 and TST: tolerance bumps for the conda-forge builds #20474

[andyfaff]

In order to get the wheels to build you'll need to have [wheel build] in the commit message.

[andyfaff]

It's often better to iterate on your own fork, as it can decrease CI usage. I open a PR against my own fork and iterate. When I'm happy I close the PR against my own fork and make a PR against the scipy fork.

To get the CI to run on your own fork you have to change if: github.repository == 'scipy/scipy' to if: github.repository == 'thalassemia/scipy'

[thalassemia]

It's often better to iterate on your own fork, as it can decrease CI usage. I open a PR against my own fork and iterate. When I'm happy I close the PR against my own fork and make a PR against the scipy fork.

I did this before putting this PR up. You can view build logs from those early iterations via the link in the PR description. Just had a couple belated realizations afterwards haha.

[andyfaff]

Hmm the rerun should've worked because I merged 20522. Can you rebase this PR on scipy/main after committing #20510 (comment)?

[thalassemia]

I added another commit that keeps our custom gfortran compilers for all our current builds. This eliminates most of the warnings about mismatched macOS target versions. The only such remaining warnings are in the ARM OpenBLAS builds, but the discrepancy is so small that it's probably fine (12.0 vs 12.2). I like the fact that this solution is more objectively correct (avoids warnings) and gives us more control over the build toolchain. It leaves a lot of complexity in the code (took me quite a while to get things right), but hopefully we won't need to touch this often. If this seems preferable, I can squash the commits to make this PR easier to review.

[andyfaff]

I think if you get it working then we should merge. However, I would like to transition to pre installed gfortran as it'll make life easier in the longrun

[thalassemia]

Many of the Linux Meson Python 3.12 failures are related to numpy/numpy#26215. Here is the relevant code in our repo.

I'll look into the sign flip in scipy/linalg/tests/test_decomp.py::TestOverwrite::test_eig_banded.

[rgommers]

This accumulated one merge conflict now. Other than that, is it good to go?

[andyfaff]

I wanted one last look after the conflict is fixed

[andyfaff]

What happens if the pre-installed gfortran is used for the openblas builds? It'd be nice to get rid of the gfortran installation in cibw_before_build_macos.sh.

[andyfaff]

Whilst we could probably iterate a bit further (e.g. to see if we can remove gfortran from cibw_before_build_macos), I think it's best to merge now. More mods could be done in a further PR. Thanks @thalassemia

[rgommers]

Great to get this in - thanks for the hard work! I added notes on Accelerate in https://github.com/scipy/scipy/wiki/*Release-Note-Entries-for-SciPy-1.14.0-(asterisk-makes-this-appear-at-the-top)