Fixed: pyMinGW patched Python compiles in MinGW & passes regrtests

[Bengt Richter]

On 20 Sep 2004 10:09:48 -0700, abkhd at earth.co.jp (A. B., Khalid) wrote:

>Hello all.
>
>This is to inform those interested in getting Python to compile in
>MinGW that the pyMinGW patch is now able to help compile both Python
>2.3.4 Final and Python 2.4a3 and the resulting MinGW Python passes the
>regrtests as follows.
>
>
>#-----------------------------------------
># Python 2.3.4 Final:
>#-----------------------------------------
>$ python -i
>Python 2.3.4 (#53, Sep 19 2004, 03:47:39) 
>[GCC 3.2 (mingw special 20020817-1)] on win32
>Type "help", "copyright", "credits" or "license" for more information.
>>>> import sys
>>>> sys.winver
>'2.3'
>>>> raise SystemExit
>
>
>
>#-----------------------------------------
># Python 2.3.4 Final: regrtests
>#-----------------------------------------
>$ python -i ../Lib/test/regrtest.py -unetwork
>[CUT]
>215 tests OK.
>40 tests skipped:
>    test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl
>    test_commands test_crypt test_curses test_dbm test_dl
>    test_email_codecs test_fcntl test_fork1 test_gdbm test_gl test_grp
>    test_imgfile test_ioctl test_largefile test_linuxaudiodev
>    test_macfs test_macostools test_mhlib test_mpz test_nis
>    test_normalization test_openpty test_ossaudiodev test_pep277
>    test_plistlib test_poll test_posix test_pty test_pwd test_resource
>    test_scriptpackages test_signal test_sunaudiodev test_timing
>Those skips are all expected on win32.
>D:\PYTHON23\lib\test\test_format.py:19: FutureWarning: %u/%o/%x/%X of
>negative int will return a signed string in Python 2.4 and up
>  result = formatstr % args
>
>
>
>#-----------------------------------------
># Python 2.4a3:
>#-----------------------------------------
>$ python -i
>Python 2.4a3 (#56, Sep 19 2004, 04:37:06) 
>[GCC 3.2 (mingw special 20020817-1)] on win32
>Type "help", "copyright", "credits" or "license" for more information.
>>>> import sys
>>>> sys.winver
>'2.4'
>>>> raise SystemExit
>
>
>
>#-----------------------------------------
># Python 2.4a3: regrtests
>#-----------------------------------------
>$ python -i ../lib/test/regrtest.py -unetwork
>[CUT]
>242 tests OK.
>46 tests skipped:
>    test__locale test_aepack test_al test_applesingle test_bsddb185
>    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
>    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw
>    test_commands test_crypt test_curses test_dbm test_dl test_fcntl
>    test_fork1 test_gdbm test_gl test_grp test_imgfile test_ioctl
>    test_largefile test_linuxaudiodev test_macfs test_macostools
>    test_mhlib test_nis test_normalization test_openpty
>    test_ossaudiodev test_pep277 test_plistlib test_poll test_posix
>    test_pty test_pwd test_resource test_scriptpackages test_signal
>    test_sunaudiodev test_threadsignals test_timing
>Those skips are all expected on win32.
>No handlers could be found for logger "cookielib"
>
>
>
>Get pyMinGW from here:
>http://jove.prohosting.com/iwave/ipython/pyMinGW.html
>
>
Great work ;-) Minor glitch: In order to get a successful linking for python.exe
on NT4 I had to add ../PC/_subprocess .c and .o into pythoncore.mak
into the contexts where ../PC/config .c and .o appear, but otherwise
is seems to have succeeded. python.exe runs in a windows "DOS box"
much like my 2.3.2, and also runs under the msys shell, though the
latter requires that I type raise SystemExit to exit from the
interactive session.

I just ran it from the MinGW directory, so I haven't got it finally arranged,
but it looks good so far. 

Your efforts are much appreciated.

My msys/MinGW is not the latest, so I don't know how much problem that causes:
[13:28] ~>uname -s -r -v
MINGW32_NT-4.0 1.0.9(0.46/3/2) 2003-07-03 07:26

I think what would be great would be a python migration script that would
be available via python.org along with all necessary md5's and signatures
for stuff on other sites that might be downloaded.

It could check what msys & MinGW was installed, and if none, provide the option for
an automatic download (using urllib etc), md5 check against info on python.org,
some tests, then downloading of the latest python tgz and pyMinGW and decompressing
them into destination directories prompted for at the beginning (so you can leave it chug),
and then building python under msys.

It should of course create a log, and be resumable to continue after fixing glitches.

Having such a script would let windows users have a unix interface to python an other
tools, which makes it easier when encountering linux or bsd or mac os under the hood.

Regards,
Bengt Richter