Hi, On Mon, Mar 7, 2016 at 12:29 PM, Olivier Grisel <[email protected]> wrote: >>> Do you plan to update the travis config script for the matrix entry >>> that generate wheels to generate manylinux1 wheels instead? >> >> You mean, within the travis-ci docker container, open up another >> docker with the manylinux image? > > I mean changing the .travis.yml config of numpy to enable the docker > service so as to use the manylinux1 image to build and run tests on > manylinux1 wheels for the master branch of numpy.
Do you happen to have any good examples to hand? Sorry to be lazy, I haven't used docker in travis yet. >> Second - how should we go about naming / building / distributing our >> external (non-Python) dependencies? > > I think Nathaniel suggested clib_<project_name>, that is clib_openblas > in our case. The naming step is certainly the easiest! But there are other problems. The most obvious one is - what package structure should we go for? A prefix within the unpackacked directory? (clib_openblas/lib clib_openblas/include ...)? >> First - should we be using openblas for the manylinux wheels? We know >> of at least one bug that is not yet fixed in openblas master, and our >> vague suspicion is that there may be quite a few more: > > Alright, we can defer the discussion to externalize the BLAS/LAPACK > implementation to later. Let's get some wheel out with embedded > openblas for now. What about the problems with openblas? Should we instead get a wheel out with embedded ATLAS? Cheers, Matthew _______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
