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



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



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



On Mon, Sep 16, 2013 at 4:36 PM, Charles R Harris <charlesr.harris@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