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>
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"
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++
wrote: python.org 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