[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:
>

If it isn't a good reason, what is? ;)


>
>  - 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.
>

OK. What is the timeline? Days, weeks, months?

 - 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
>

I don't think static linkage would bring in the whole library, just the
parts needed. Christolph's packages are < 10MB. Redistribution using the
offered licenses is a potential problem that we need to get clarification
on. No redistribution, no MKL.


>  - using ifort for fortran: by doing this, we impose on *every* package
> downstream to use ifort as well (same for MKL BTW).
>

How does that work?


>
> 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).
>

So we need to distribute an LAPACK DLL? That sounds like a separate problem.

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