L
Luke Kenneth Casson Leighton
no, the above subject-line is not a joke: i really _have_ successfully
built python2.5.2 by installing wine on linux, then msys under wine,
and then mingw32 compiler - no, not the linux mingw32-cross-compiler,
the _native_ mingw32 compiler that runs under msys, and then hacking
things into submission until it worked.
issue-report: http://bugs.python.org/issue4954
source code: http://github.com/lkcl/pythonwine/tree/python_2.5.2_wine
related issue-report: http://bugs.python.org/issue3871
related issue-report: http://bugs.python.org/issue1597850
i'm going to _try_ to merge in #3871 but it's... the prospect of
sitting waiting for configure to take THREE hours to complete, due to
/bin/sh.exe instances taking TWO SECONDS _each_ to start up does not
really fill me with deep joy.
consequently i did a major hatchet-job on configure.in with repeated
applications of "if test $win32build = no; then" ... cue several
hundred lines of configure.in tests blatantly ignored "fi #
$win32build=no! " and thus cut the configure time down from three
hours to a mere 15 minutes. the only reason why this was possible at
all was because PC/config.h already exists and has been pre-set-up
with lots of lovely #defines.
also, there is another significant difference between #3871 and #4954
- i chose to build in to libpython2.5.dll exactly as many modules as
are in the proprietary win32 build. this turned out to be a good
practical decision, due to /bin/sh.exe messing around and stopping
python.exe from running! (under cmd.exe it's fine. i have to do a
bit more investigation: my guess is that the msys "remounter" is
getting in the way, somehow. compiling python to have a prefix of
/python25 results in files being installed in /python25 which maps to
c:/msys/python25/ but.... actually that doesn't get communicated
correctly to the compiled python.exe....
it's all a bit odd - it still feels like things are being
cross-compiled... but they're not... it's just that setup.py has paths
that don't _quite_ match up with the msys environment...
needs work, there.
the regression testing is _great_ fun! some of the failures are
really quite spectacular, but surprisingly there are less than
anticipated. file "sharing violation" isn't a big surprise (under
wine); the ctypes structure failures are going to be a bitch to hunt
down; the test_str %f failure _was_ a big surpise; the builtin file
\r\n <-> \n thing wasn't in the _least_ bit of a surprise
overall, this has been... interesting. and the key thing is that
thanks to #3871 and #4954 and #1597850, python will soon happily
compile for win32 _without_ the dependence on _any_ proprietary
software or operating systems. that's a pretty significant milestone.
l.
p.s. if anyone would like to try out this build, on a windows box, to
see if it fares any better on the regression tests please say so and i
will make the binaries available.
built python2.5.2 by installing wine on linux, then msys under wine,
and then mingw32 compiler - no, not the linux mingw32-cross-compiler,
the _native_ mingw32 compiler that runs under msys, and then hacking
things into submission until it worked.
issue-report: http://bugs.python.org/issue4954
source code: http://github.com/lkcl/pythonwine/tree/python_2.5.2_wine
related issue-report: http://bugs.python.org/issue3871
related issue-report: http://bugs.python.org/issue1597850
i'm going to _try_ to merge in #3871 but it's... the prospect of
sitting waiting for configure to take THREE hours to complete, due to
/bin/sh.exe instances taking TWO SECONDS _each_ to start up does not
really fill me with deep joy.
consequently i did a major hatchet-job on configure.in with repeated
applications of "if test $win32build = no; then" ... cue several
hundred lines of configure.in tests blatantly ignored "fi #
$win32build=no! " and thus cut the configure time down from three
hours to a mere 15 minutes. the only reason why this was possible at
all was because PC/config.h already exists and has been pre-set-up
with lots of lovely #defines.
also, there is another significant difference between #3871 and #4954
- i chose to build in to libpython2.5.dll exactly as many modules as
are in the proprietary win32 build. this turned out to be a good
practical decision, due to /bin/sh.exe messing around and stopping
python.exe from running! (under cmd.exe it's fine. i have to do a
bit more investigation: my guess is that the msys "remounter" is
getting in the way, somehow. compiling python to have a prefix of
/python25 results in files being installed in /python25 which maps to
c:/msys/python25/ but.... actually that doesn't get communicated
correctly to the compiled python.exe....
it's all a bit odd - it still feels like things are being
cross-compiled... but they're not... it's just that setup.py has paths
that don't _quite_ match up with the msys environment...
needs work, there.
the regression testing is _great_ fun! some of the failures are
really quite spectacular, but surprisingly there are less than
anticipated. file "sharing violation" isn't a big surprise (under
wine); the ctypes structure failures are going to be a bitch to hunt
down; the test_str %f failure _was_ a big surpise; the builtin file
\r\n <-> \n thing wasn't in the _least_ bit of a surprise
overall, this has been... interesting. and the key thing is that
thanks to #3871 and #4954 and #1597850, python will soon happily
compile for win32 _without_ the dependence on _any_ proprietary
software or operating systems. that's a pretty significant milestone.
l.
p.s. if anyone would like to try out this build, on a windows box, to
see if it fares any better on the regression tests please say so and i
will make the binaries available.