On Mar 18, 2015 8:14 AM, "anatoly techtonik" <techtonik@gmail.com> wrote:
>
> On Mon, Mar 16, 2015 at 7:31 PM, Chris Barker <chris.barker@noaa.gov> wrote:
> > On Mon, Mar 16, 2015 at 6:24 AM, anatoly techtonik <techtonik@gmail.com>
> > wrote:
> >>
> >> "Autotools has reached the Chandrasekhar mass limit of software and
> >> become a black hole of suck that consumes endless hours of bright
> >> peoples’ time without any good result. It is well past time for it to
> >> die." (c) "Autotools must die", ESR. http://esr.ibiblio.org/?p=1877
> >>
> >> I couldn't sum up this better. It looks even worse from Windows machine.
> >
> > Is it even used for building Python on Windows (for the "normal" python.org
> > builds)?
>
> There was some success with MinGW toolchain, but I am not tracking if it was
> integrated into official source. The FUD was that compiled extensions are not
> compatible between MSVC builds and MinGW builds, but I could not confirm
> that. If I understand correctly, the incompatibility is only for C++ programs,
> because of strange SEH strategy and proprietary name mangling.

This isn't FUD, alas. mingw in almost all of its variants uses effectively a different "libc" than MSVC, so code compiled with two compilers can't even agree on the meaning of file numbers. It is mostly possible to set up a mingw-w64 build that produces MSVC-compatible extensions, but it requires using a configuration that's undocumented and untested upstream (I.e. you will run into mingw bugs). NumPy *may* switch to this at some point -- we've been working on it for like a year now -- but it's extremely non-trivial.

-n