Hi Guix,

python-numpy currently depends on Atlas, which means that it cannot be
substituted with a binary built elsewhere.  OpenBLAS is an alternative
to Atlas and the binary can be used on all supported CPUs at runtime.
This makes it possible for us to make numpy substitutable.

We currently do not have a working OpenBLAS on MIPS, so the attached
patch selects OpenBLAS as an input only when not on MIPS.  Some
additional configuration happens only unless "atlas" is among the
inputs.

I have successfully compiled numpy and python-scikit-image for both
versions of Python on x86_64 with these changes.  I should say, however,
that there's a note in the numpy sources that warns about a bug under
certain conditions:

    # **Warning**: OpenBLAS, by default, is built in multithreaded mode. Due to the
    # way Python's multiprocessing is implemented, a multithreaded OpenBLAS can
    # cause programs using both to hang as soon as a worker process is forked on
    # POSIX systems (Linux, Mac).
    # This is fixed in Openblas 0.2.9 for the pthread build, the OpenMP build using
    # GNU openmp is as of gcc-4.9 not fixed yet.
    # Python 3.4 will introduce a new feature in multiprocessing, called the
    # "forkserver", which solves this problem. For older versions, make sure
    # OpenBLAS is built using pthreads or use Python threads instead of
    # multiprocessing.
    # (This problem does not exist with multithreaded ATLAS.)

I do not know if this is still a problem and I haven't yet tried to
reproduce this.  Our OpenBLAS is not built with openmp, so I think this
problem does not affect us.

Anyway, I just wanted to post this here to ask for opinions.  Maybe this
is a bad idea.  (In my case it makes sense not to use Atlas, because the
compile-time tuning is useless when a shared store is used and clients
use Atlas on machines other than the build host.)

Comments are very welcome!

~~ Ricardo