[Numpy-discussion] Binary releases

[Charles R Harris]

On Mon, Sep 16, 2013 at 12:31 PM, David Cournapeau <cournape at gmail.com>wrote:

>
>
>
> 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.
>
>
Openblas includes some of lapack and is available for x86_64 on windows. It
isn't clear what is included nor what compiler was used.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130916/0e5c84ab/attachment.html>