Pat said:
On Windows, most users are used to installing precompiled binary
packages, rather than compiling from source. When you do have to
compile from source, it often requires you to fiddle with nitty gritty
details about which you'd rather remain ignorant. The less fiddling
required, the happier the user will be, and the easier it will be for
that product to get adopted on that platform. No psychic abilities are
required. No Python abilities are required, either, for that matter.
;-)
And the fact that building *any* Windows native program without commercial
software is a PITA is the py-dev crew's fault, how?
The python.org releases provide pre-built binaries for Windows, support for
compiling Windows extensions with various compilers (including MinGW), and
autoconf/automake support for POSIX-ish platforms (including Cygwin).
For native Windows compilation of the interpreter, they support MSVC6 and MSVC7.1.
If you're a serious commercial Windows shop, you will have one of the Microsoft
compiler suites installed *somewhere*. At that point, building your own version
of Python is trivial.
Which leaves the hobbyists, and those companies which, for whatever reason,
choose not to use Visual Studio to build C/C++ code on Windows.
If it meets your needs, the easiest solution is to build a non-native version
using Cygwin (./configure, make, make altinstall). That's what I currently do,
as the easiest free way to hack Python on a Windows box.
Which means our target group is now only those who want to build a Windows
Python binary, and don't want to use Visual Studio, and don't want to use Cygwin
(hmm, the group under discussion must be getting rather small by now).
Anyway, to support this group, the real thing that is needed is a tool to
translate the MSVC7.1 solution files into GNU make files (so the MSYS make
utility can parse them and invoke MinGW or the free MS compiler appropriately)
For anyone who actually wants to make this work, this message summarises where I
got to before giving up and switching to a different platform for builds:
http://mail.python.org/pipermail/python-dev/2004-August/047215.html
Things have moved on since then - the Python project files no longer reference
the unneeded ODBC libraries, but they do reference options the version of
vcproj2make in the python-dev archives doesn't understand.
Also, vcproj2make has a dependency on PyXML, which isn't necessarily obvious
from the error message you get when the sln parser fails to work.
It can be done, and it could be automated, but it doesn't take a Python core
hacker to do it - it takes someone who cares about it, and understands GNU make
and Python well enough to maintain vcproj2make.
To finish the job, someone would need to:
1. Commit to maintaining vcproj2make
2. Get Garth to put a real license on it
3. Finish it well enough that it works on the Python PCBuild directory
4. Provide instructions (and possibly a script) for building Python with
vcproj2make, MSYS and MinGW.
5. See about including those instructions in Python CVS
(MinGW is probably a better option than the free MS compiler, since the files
you need aren't scattered all over the MS website, embedded in over 300 MB worth
of downloads, and you aren't bound by the MS EULA. Don't go redistributing
msvcr71.dll though)
The trick is finding someone who cares enough, or someone who will pay someone
to care enough - I cared for a while, but not enough to finish it. For what I
want (hacking the interpreter core), Cygwin suffices, and it's a hell of a lot
easier.
The pyMinGW folks appear to care, but for reasons best known to them, have
chosen to track the PCBuild project files manually, rather than automating the
process. They've also chosen to maintain separate files on their own site,
rather than providing diff's and submitting appropriate patches to improve MinGW
support in the main Python CVS. *shrug* Their call.
Cheers,
Nick.
P.S. if Ilias volunteers, or offers to pay someone to do this, instead of just
complaining, will hell freeze over?)
