On Mon, Sep 16, 2013 at 12:31 PM, David Cournapeau <courn...@gmail.com>wrote:
> > > > On Mon, Sep 16, 2013 at 7:19 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> >> On Mon, Sep 16, 2013 at 12:12 PM, David Cournapeau <courn...@gmail.com>wrote: >> >>> >>> >>> >>> On Mon, Sep 16, 2013 at 4:36 PM, Charles R Harris < >>> charlesr.har...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
