Fixed: pyMinGW patched Python compiles in MinGW & passes regrtests

[A. B., Khalid]

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.


#-----------------------------------------
# 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.


#-----------------------------------------
# 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


Regards
Khalid




--
Q. The purpose of life?

[A]: "I created the jinn and humankind only that they might
worship Me." (Translation, Qur'an, 51:56)

: "Let us hear the conclusion of the whole matter:
Fear God, and keep his commandments: for this is the
whole duty of man." (KJV, Ecclesiastes 12:13)

 

[Paul Moore]

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.

Cool! It would be nice if this could be made into a patch to core
python, so that the main sources support a mingw build.

Paul.

 

[A. B., Khalid]

Cool! It would be nice if this could be made into a patch to core
python, so that the main sources support a mingw build.

Paul.

Hello Paul. Sorry for the delay.

Yes, it would be, wouldn't it? If you were addressing me there, as
opposed to the general audience of c.l.py or the core-developers of
Python, then allow me to say that in principal I have no problem with
pyMinGW making it to Python's core, provided of course that a
copyright notice appears somewhere (at least in the makefiles). This I
think would not be a problem. After all, and from what I have seen of
Python's source, there is a good habit of including copyright notices
of contributing authors to Python in the works they authored.

I must confess that aside from me being totally unfamiliar with the
process of officially patching Python, the major hurdle appears to me,
in addition to that, in whether the patch was tested enough, or by
enough people, so as to earn itself a place in the core- that of
course if it will be allowed a place there to start with. Have you
tried it out? Please do if you still didn't have the chance.

I might be mistaken, but I think that testing should come first. After
all there is nothing urgent here, or is there? When people find that
it really works, they will call for it to be included in Python's
source. In the meantime, pyMinGW is there for those who need it, and
being a third-party patch should not be a reason to scare people away
from using it, especially since it gets the job done. With that said,
I am open to any thoughts on this from your esteemed person or from
anyone else.


Best regards
Khalid

 

[Steve Holden]

Hello Paul. Sorry for the delay.

Yes, it would be, wouldn't it? If you were addressing me there, as
opposed to the general audience of c.l.py or the core-developers of
Python, then allow me to say that in principal I have no problem with
pyMinGW making it to Python's core, provided of course that a
copyright notice appears somewhere (at least in the makefiles). This I
think would not be a problem. After all, and from what I have seen of
Python's source, there is a good habit of including copyright notices
of contributing authors to Python in the works they authored.

I must confess that aside from me being totally unfamiliar with the
process of officially patching Python, the major hurdle appears to me,
in addition to that, in whether the patch was tested enough, or by
enough people, so as to earn itself a place in the core- that of
course if it will be allowed a place there to start with. Have you
tried it out? Please do if you still didn't have the chance.

I might be mistaken, but I think that testing should come first. After
all there is nothing urgent here, or is there? When people find that
it really works, they will call for it to be included in Python's
source. In the meantime, pyMinGW is there for those who need it, and
being a third-party patch should not be a reason to scare people away
from using it, especially since it gets the job done. With that said,
I am open to any thoughts on this from your esteemed person or from
anyone else.

I believe that contributors to the core are nowadays (or will shortly be
expected to) assign the right to the PSF to use the material. I believe
this is done in such a way as to allow the contributor to retain the
rights to do whatever they like with the code also, but you should
familiarize yourself with the current state of play.

http://www.python.org/psf/psf-contributor-agreement.html is, alas, an
out-of-date draft, but there's probably more recent documentation
available. python-dev is probably the place to go for authoritative
comment on this matter.

regards
Steve

 

[Bengt Richter]

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.


#-----------------------------------------
# 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.


#-----------------------------------------
# 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

 

[A. B., Khalid]

(e-mail address removed) (Bengt Richter) wrote in message

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.

Hello Bengt,

The subprocess module was added only in the beta release of Python
2.4. The pyMinGW version you had access to only patched the alpha 3
release of Python 2.4. I did update my local copy to include the new
module, and was going to update the publically available pyMinGW in
good time. It is good to read that you did manage to do it though. I
feel I should warn you, however, that by patching (in our case
replacing) a newer version with an old version of a Python source file
that you might be overwritting important updates and bugfixes that may
have been made to the source. At any rate, I think the latest pyMinGW
update is ready and I may post it today, and that would include, God
willing, support for Python 2.4rc1.

Also, the MSYS behavior of your system seems identical to mine, so I
wouldn't worry about that.


Regards
Khalid