[Numpy-discussion] Binary releases

[David Cournapeau]

On Mon, Sep 16, 2013 at 7:19 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
>
> On Mon, Sep 16, 2013 at 12:12 PM, David Cournapeau <cournape at gmail.com>wrote:
>
>>
>>
>>
>> On Mon, Sep 16, 2013 at 4:36 PM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>> New summary
>>>
>>>    1. 32 bit windows, python 2.6, 2.7, 3.2, 3.3, compiled with MSVC
>>>    2. 64 bit windows, python 2.6, 2.7, 3.2, 3.3, compiled with MSVC,
>>>    linked with MKL
>>>
>>> These should be good for both windows 7 and window 8.
>>>
>>>
>> Wait, when was it decided to move to MSVC for the official binaries ?
>> Especially using ifort/MKL on windows means it will be difficult for other
>> projects to produce packages on top of it.
>>
>>
> It hasn't been decided, this is just a modified version of the initial
> post.
>

ok, sorry for the confusion


> Why not use MSVC? python.org does. What is the problem with statically
> linked MKL? Do other packages need to link to lapack? The windows build
> problem has hung around for years. I'm tired of it.
>

Which build problem ? Being tired of it does not justify a decision in
particular, otherwise we fall into the fallacy "there is a problem,
therefore we must do something". There are multiple issues:

 - moving away from gcc 3.x on 32 bits. Those compilers are old, but it
works well today. It is an untenable situation in the long term, though. I
will look again at building numpy/scipy with mingw-w64 in 32 bits to see if
the problems with -static-* are gone or not.
 - 64 bits support: linked to first point. If the first point is solved, I
am relatively confident this one can too.
 - moving away from Atlas to MKL: this is much more problematic. First, MKL
is *huge*. For info, the MKL package we provide @ Enthought is 70 MB zip
compressed, and that's for the DLLs. The static version may be even bigger
 - using ifort for fortran: by doing this, we impose on *every* package
downstream to use ifort as well (same for MKL BTW).

There is also the issue of a blas/lapack for windows 64 bits. There the
situation has changed a lot since I last looked into those issues: cygwin
(required by atlas) now supports 64 bits natively, and openblas is
relatively well supported. I would certainly be happy to get rid of ATLAS
which is a PITA to maintain, and use openblas instead.

Other packages *do* need to link into lapack (scikit learn, theano are
examples I am aware of).

David

 For Mac there is first the question of OS X versions, (10.5?), 10.6, 10.7,
>>> 10.8. If 10.5 is omitted, packages built on 10.6 should be good for 10.7
>>> and 10.8, so
>>>
>>>    1. OS X 10.6  python 2.6, 2.7, 3.2, 3.3, compiled with native
>>>    compiler, linked with Accelerate.
>>>
>>> The main question seems to be distribution and coordination with scipy.
>>> I was thinking we would link in MKL statically, which I think should be OK.
>>> Christoph does that and it should decouple Numpy from Scipy. It may not be
>>> the most efficient way to do things, but it would work. My impression is
>>> that if we wanted to distribute a dynamic library then every user would
>>> need an MKL license to use it.
>>>
>>> It would be good to get this settled soon as we can't afford to futz
>>> around with this forever waiting to release Numpy 1.8 and Scipy 0.13.
>>>
>>>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130916/c9036a35/attachment.html>