By the way, it seems OpenBLAS builds with clang on MacOSX, so presumably it works on Windows as well. Unlike GNU toolchains, there is a cl-clang frontend which is supposed to be MSVC compatible. BTW, clang is a fantastic compiler, but little known among Windows users where MSVC and MinGW dominate.
Sturla On 30/01/14 13:29, Carl Kleffner wrote: > I fully agree with you. But you have to consider the following: > > - the officially mingw-w64 toolchains are build almost the same way. The > only difference is, that they have non-static builds (that would be > preferable for C++ development BTW) > - you won't get the necessary addons like spec-files, manifest resource > files for msvcr90,100 from there. > - there is a urgent need for a free and portable C,C++, Fortran compiler > for Windows with full blas, lapack support. You won't get that with > numpy-MKL, but with a GNU toolchain and OpenBLAS. Not everyone can buy > the Intel Fortran compiler or is allowed to install it. > - you can build 3rd party extensions which use blas,lapack directly or > with cython with such a toolchain regardless if you use numpy/scipy-MKL > or mingw-based numpy/scipy > - The licence question of numpy-MKL is unclear. I know that MKL is > linked in statically. But can I redistribite it myself or use it in > commercial context without buying a Intel licence? > > Carl > > > 2014-01-30 Sturla Molden <sturla.mol...@gmail.com > <mailto:sturla.mol...@gmail.com>>: > > On 30/01/14 12:01, Carl Kleffner wrote: > > > My conclusion is: mixing different compiler architectures for > building > > Python extensions on Windows is possible but makes it necessary > to build > > a 'vendor' gcc toolchain. > > Right. > > This makes a nice twist on the infamous XML and Regex story: > > - There once was a man who had a problem building NumPy. Then he > thought, "I'll just use a custom compiler toolchain." Now he had two > problems. > > Setting up a custom GNU toolchain for NumPy on Windows would not be > robust enough. And when there be bugs, we have two places to look for > them instead of one. > > By using a tested and verified compiler toolchain, there is one place > less things can go wrong. I would rather consider distributing NumPy > binaries linked with MKL, if Intel's license allows it. > > Sturla > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org> > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion