Supporting non-Microsoft compilers
A couple of people are working on support in the Distutils for building extensions on Windows with non-Microsoft compilers. I think this is crucial; I hate the idea of requiring people to either download a binary or shell out megabucks (and support Chairman Bill's monopoly) just to use some handy Python extension. (OK, OK, more likely they'll go without the extension, or go without Python. But still...) However, it seems like it would be nice if people could build Python itself with (eg.) cygwin's gcc or Borland's compiler. (It might be essential to properly support building extensions with gcc.) Has anyone one anything towards that goal? It appears that there is at least one patch floating around that advises people to hack up their installed config.h, and drop a libpython.a somewhere in the installation, in order to compile extensions with cygwin gcc and/or mingw32. This strikes me as sub-optimal: can at least the required changes to config.h be made to allow building Python with one of the Windows gcc ports? I would be willing to hold my nose and struggle with cygwin for a little while in Windows in dull moments at work -- had to reboot my Linux box into Windows today in order to test try building CXX (since my VMware trial license expired), so I might as well leave it there until it crashes and play with cygwin. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367
Greg Ward wrote:
However, it seems like it would be nice if people could build Python itself with (eg.) cygwin's gcc or Borland's compiler. (It might be essential to properly support building extensions with gcc.) Has anyone one anything towards that goal?
Robert Kern (mingw32) and Gordon Williams (Borland).
It appears that there is at least one patch floating around that advises people to hack up their installed config.h, and drop a libpython.a somewhere in the installation, in order to compile extensions with cygwin gcc and/or mingw32. This strikes me as sub-optimal: can at least the required changes to config.h be made to allow building Python with one of the Windows gcc ports?
Robert's starship pages (kernr/mingw32) has a config.h patched for mingw32. I believe someone else built Python using cygwin without much trouble. But mingw32 is the preferred target - cygwin is slow, doesn't thread, has a viral GPL license and only gets along with binaries built with cygwin. Robert's web pages talk about a patched mingw32. I don't *think* that's true anymore, (at least I found no problems in my limited testing of an unpatched mingw32). The difference between mingw32 and cygwin is just what runtime they're built for. - Gordon
participants (2)
-
Gordon McMillan
-
Greg Ward