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

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'

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.

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

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.

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

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.

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

I wanted one last look after the conflict is fixed

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

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)