<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 7:19 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Mon, Sep 16, 2013 at 12:12 PM, David Cournapeau <span dir="ltr"><<a href="mailto:cournape@gmail.com" target="_blank">cournape@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Mon, Sep 16, 2013 at 4:36 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">New summary<br><div><ol><li>32 bit windows, python 2.6, 2.7, 3.2, 3.3, compiled with MSVC</li>
<li>64 bit windows, python 2.6, 2.7, 3.2, 3.3, compiled with MSVC, linked with MKL</li>
</ol><p>These should be good for both windows 7 and window 8.<br>
</p><p></p></div></div></blockquote><div><br></div></div><div>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.</div>
<div><br></div></div></div></div></blockquote><div><br></div></div><div>It hasn't been decided, this is just a modified version of the initial post. </div></div></div></div></blockquote><div><br></div><div>ok, sorry for the confusion</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>Why not use MSVC? <a href="http://python.org" target="_blank">python.org</a> 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. <br>
</div></div></div></div></blockquote><div><br></div><div>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:</div>
<div><br></div><div> - 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.</div>
<div><div> - 64 bits support: linked to first point. If the first point is solved, I am relatively confident this one can too.</div></div><div> - 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</div>
<div> - using ifort for fortran: by doing this, we impose on *every* package downstream to use ifort as well (same for MKL BTW).</div><div><br></div><div>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.</div>
<div><br></div><div>Other packages *do* need to link into lapack (scikit learn, theano are examples I am aware of).</div><div><br></div><div>David</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr"><div><p>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 <br></p><div>
<ol><li>OS X 10.6 python 2.6, 2.7, 3.2, 3.3, compiled with native compiler, linked with Accelerate.</li></ol></div><p>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.</p>
<p>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.</p><p></p></div></div></div></blockquote></div></div></div></blockquote><div>
<br></div><div>Chuck <br></div><br></div></div></div></div>
<br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div><br></div></div>