Luke Kenneth Casson Leighton <l...@lkcl.net> added the comment:
> I disagree;
i would say that you're entitled to disagree, but i have to point
out that unless you've actually been through the process of trying
to port python to mingw32 you're not really in a position of ...
how can i put this best... you're entitled to say "i disagree"
but that doesn't actually carry any weight.
if you said "i've tried compiling this patch, and i looked at
it and i disagreed with the decision to create a new platform,
so i removed that code, here's an updated patch, i found it to
work absolutely fine" THEN i would say that you are in a position
of authority to "disagree".
so - question: have you actually _tried_ compiling python with
mingw32, with the latest patch?
> programs compiled with mingw32 run on Windows, and use the MSVC
> runtime.
they do indeed. this however has absolutely no relevance.
> It's the same platform as the current win32 build.
> It's even possible to use mingw32 to compile extensions
> for the VS9.0 based python.exe.
it is indeed. the patch that i did allowed you to specify
a gcc spec file which did exactly that: i added options to
compile not only extensions but also the entire python.exe
to use a different MSVCRT runtime.
_and_ it did assemblies, too.
> A different compiler does not make a new platform.
ok.
unfortunately, as the work that i did was well over a year ago,
i'm going from memory - but basically, i'm very very sorry to
have to point out that you don't know what you're talking about,
here.
let me try and go through it.
look at the platform detection code: it parses the gcc version
string. it goes "if compiler has string gcc but also has win32
then it must be cygwin platform".
otherwise it goes "this must be MSVC win32 platform".
this _simply_ doesn't work, hence the need to do further
detection, hence the need to have a separate compiler type.
... but it doesn't end there: there are subtle differences
between MSVC win32 and MINGW32 win32 (differences in the
build .lib files that specify what functions are available
in the DLLs. mingw32 is a reverse-engineering project,
remember?)
to be honest i can't remember if i actually set sys.platform to
mingw32 - but the more time i spent getting more and more modules
to compile, the more blindingly obvious it was that a new platform
type was needed.
i encountered dozens of assumptions that "if sys.platform == 'win32'
then you MUST be building using visual studio: f*** off with your
attempt to compile this module using gcc".
over the eight to ten week period in which i focussed on this
non-stop for about 13 hours a day, the list just went on and on
of discrepancies that had to be solved, and if i _hadn't_ set a
new platform type, it would have been necessary to add extra
tests instead:
"if sys.platform == 'win32' and not {something to detect mingw32}":
mingw32 _really_ does fall between both worlds: not just the
compiler type is different, but there are even features and
functions _missing_ from mingw32 that are present in MSVC.
i had to work with roumen to get patches to mingw32 upstream
in some cases!
so please _do_ stop putting road-blocks in the way. this is
a complex enough project, having to fit half way between
two disparate worlds, without it being stymied by "disagreement"
when you haven't _actually_ tried compiling this code (if you
have, i apologise).
btw if you'd like to try compiling it, but are adamant about
staying away from proprietary operating systems, i _did_
manage to get python 2.5 and 2.6 cross-compiled to run under wine.
ironically there were long-standing bugs in wine that ended up
getting fixed as a result of running the 25,000 python unit tests,
but that's another story... :)
l.
p.s. msys runs under wine as well, but the configure stage takes
well over an hour. the patch i created cut out most of configure
and replaced it with a pcconfig.h just like win32, which i had
to create by hand. this was quicker than waiting for configure
to run.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
