add more wheels

[mattip]

Add aarch64 , ppc64le, s390x wheels, and wheels for pypy3.6 on linux64 , linux32, macOS.

In total: 6 4 more wheels. Another PR will be needed for PyPy wheels on windows (only 32 bits is supported) maybe with a move to azure instead of appveyor.

[mattip]

replaces #70. This is much simpler now that multibuild support has improved.

[mattip]

Hmm. manylinux2014 does not support the openblas-manylinux1 gfortran lib. That means if we try to merge this to use the other architectures (which only support manylinxu2014) we cannot build 1.18 since it uses the old manylinux1 openblas libs :(

[charris]

No need to update 1.18 with new libraries and platforms. 1.19 will branch in three months.

[mattip]

Ok, for now leaving out the -msse2 flag seems to avoid the segfaults without causing new test failures. I guess 32-bit linux has been fine so far with the reduced gcc performance, it can continue for a bit longer.

[mattip]

Of course all the new architectures (aarch64, ppc64le, s390x, pypy on linux64, linux32, macOS) fail to pass. Will work on it offline where I can.

[mattip]

The PyPy failures will be fixed by numpy/numpy#15750.

The ARM64 failure is a compiler bug problem with all the gcc compilers I could use with the manylinux2014 image. xref pypa/manylinux#494. On the other hand, the failure is in come of the complex trig functions which are blacklisted with glibc<2.18. Originally we blacklisted glbic 2.16, but in numpy/numpy#7518 the blacklisting was extended to 2.18. Perhaps that is too strict?

The ppc64le test run hangs in lib/tests/test_io.py::TestSaveTxt::test_large_zip.

The s390x one runs out of disk space, xref this travis discussion

[mattip]

Running ppc64le in one of the gcc farm machines, it turns out they define LDBL_EPSILON as 0, but the test_large_zip test passes. test_large_zip may be an issue with the amount of resources, I think I will skip it on non-linux_x86_64.

[andyfaff]

Will numpy 1.19 offer arm64 wheels?

[mattip]

aarch64 and ppc64le are blocked until we can offer post-multibuild2014 wheels, since multibuild2014 does not sufficiently support those architectures. This is the tracking issue for the next generation of wheels.

[mattip]

The four new wheels (aarch64 on python 3.6, 3.7, 3.8; pypy on linux64) pass building and testing on travis. numpy/numpy#16224 should add the missing hashes for the azure manylinux1 builds.

[mattip]

All wheel building passes.

[charris]

How do we keep the OpenBLAS version fixed in a release branch?

[mattip]

The OpenBLAS interaction is entirely defined by numpy/tools/openblas_support.py. The wheels will be built with whatever is used there. We could vendor that file into this repo if you wish to change the version from what is used in numpy/numpy

[charris]

The wheels will be built with whatever is used there.

We normally fix the OpenBLAS version through a release cycle because it makes if easier to track bugs. The numpy and wheels master branches are testing branches, not release branches. It would be good to have a way to pin the OpenBLAS version for releases.

[mattip]

It would be good to have a way to pin the OpenBLAS version for releases.

I propose this workflow:

• update MacPython/openblas-libs with a new OpenBLAS version or tag, the artifacts are uploaded to https://anaconda.org/multibuild-wheels-staging/openblas-libs/files
• modify tools/openblas_support.py to use the new tag via a PR to numpy/numpy and merge that to numpy/numpy#master.
• get downstream scipy/pandas/scikit-* to test the weekly build
• at some point branch numpy/numpy#master into a numpy/numpy#maintenance/XXX branch for the next release. At this point the version of OpenBLAS will be fixed to the one currently in `numpy/numpy#master
• Optionally, change the version of tools/openblas_support.py via a PR to numpy/numpy#maintenance/XXX.

This means the version of OpenBLAS is always driven by numpy/numpy, and not via this repo.

[charris]

Ugh, that's ugly :) I would like to just make a branch in numpy-wheels and everything is done, just like it was before. The master branch can be updated to use new libraries for testing. One possibility might be to use a submodule for the openblas_support.py tool.

@tylerjereddy @rgommers Thoughts.

[charris]

I note that we already have a numpy submodule. As a quick fix we could update it to the release branch.

Also looks like the daily branch is no longer used, I think we can delete it.

[charris]

If the version of openblas_support.py is the one found at the commit hash then your suggestion will probably work, although changing the OpenBLAS version used in a branch won't be as easy to experiment with. Note that the numpy submodule could be pointed to the tip of numpy:master if we want to use the submodule approach.

[tylerjereddy]

Yeah, I was thinking about that this week--there used to be an environment variable that I would just change for wheels OpenBLAS version changes.

The abstraction of the openblas handling machinery to the main repo has the same effect for SciPy.

I suppose openblas_support.py could also be made to accept an environment variable to override the OpenBLAS version used, to avoid having to make a bunch of experimental backport merges in the main repo maintenance branch when OpenBLAS issues show up in a release.

Not sure we'd want to add much more complexity to that module though. If one used an environment variable the hash checking would probably need to be turned off or accepted by another mechanism then (since the hashes are hard-coded into the module).

[charris]

Lets give it a shot. If nothing else, I'd like to see the files in nightly. Thanks Matti.

[mattip]

Nightly is a misnomer: the cron job builds weekly