Python 3.0.1 and mingw

[lkcl]

On Jun 23, 10:59 pm, smartmobili <v.richo... at gmail.com> wrote:
> I wanted to know if you have some patch to compile python 3.x on mingw
> platform because I found some
> but doesn't work very well :

 you should compile a 2.N version.

 despite efforts and proof that the efforts passed all but about 8-12
regression tests, the python development core team deemed the 2.5 and
the 2.7 mingw port efforts to be a waste of time.

 if you or anyone else disagrees with this, please do say so, on the
python-dev mailing list and also in the bugtracker.  at least one
person has already done so:

   http://bugs.python.org/issue4954#msg85994



  http://bugs.python.org/issue5046 states that i am not allowed to
post "work in progress", despite it being significantly complete, and
despite it being worthwhile to have added in as-is into the standard
python repository.

 http://bugs.python.org/issue4954 is where a python2.5 mingw native
_and_ cross-compile was successfully built.

 http://bugs.python.org/issue3871 is where roumen continues to provide
the benefits of the continuous work that he is doing.  when i last
checked, he wasn't able to do native mingw32 builds but only cross-
compiles, but that may have changed.

 the most significant difference between 4954 and 3871 at the time
when my efforts were terminated due to python developer hostility is
that i spent considerable time reducing the size of configure.

 firing up a new /bin/sh under MSYS, native, takes 0.7 seconds (and <
0.01 on a gnu/linux box). firing up a new /bin/sh under MSYS, running
under Wine, took _well_ over two seconds.

 consequently, running an "unmodified" version of configure would take
well over half an hour.

 by cutting most of configure out and going with a pre-prepared
Config.h i was able to reduce that time down to (only) about 10
minutes.

 which is just about tolerable.

 like all free software projects, there is considerable additional
work to be done: everything is "work in progress", but thanks to the
python developers applying one standard to themselves on what
constitutes "work in progress" and another for contributors, you will
not get the benefit of my input and expertise until you (python users)
can get the python developers to treat my efforts to help users with a
little more respect.

l.