[SciPy-Dev] win32 binaries and scipy 0.17.0 release

[Tony Kelman]

Carl Kleffner <cmkleffner <at> gmail.com> writes:

> I propose different configurations of the toolchains based upon its users:

2 issues here: you're adding more maintenance burden for yourself by
having to rebuild your own custom gcc configuration all the time, and
mingw-w64 already has a "too many configurations and sources of binaries"
problem. Once this all settles down and is finished being upstreamed, it
would be best if mingwpy could avoid making that problem worse, is all I'm
saying. Wouldn't it be great if mingwpy could just be a wheel repackaging
of one of the many existing sources of mingw-w64 binary builds? With
some wrappers setting flags for things like msvc crt linkage. Long term
target.

> And throwing C++ exceptions across library boundaries is not an issues at 
all for scipy as there are no library boundaries (this is true for most of the 
python packages I'm aware of)

Even for calling into unmodified libraries via cffi?


> If you want python binaries depend on gcc shared runtime libraries you get 
another major problem on CPython for Windows. It is not garantueed, that 
correct versions of the libraries are found automatically at runtime. And 
python binaries (pyd's) are spread all around within the site-packages folder 
and subfolders. There is only one workaround I can think of: explicit 
preloading of all necessary runtime DLLs into the process space. This could be 
handled within a dedicated mingw-runtime package. That unfortunately means: an 
additional windows-only package dependency to all mingw-w64 based python 
binaries.

This seems like the ideal technical solution here. Static linking is
good for single file executables, less good for library ecosystems with
complicated interdependencies.