wine users - Jan 2009 - compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now

folks, hi,
this is a fairly important issue for python development
interoperability - martin mentioned that releases of mingw-compiled
python, if done with a non-interoperable version of msvcrt, would
cause much mayhem.
well, compiling python on mingw with msvcr80 _can_ be done; using it
can also be a simple matter of creating a python.exe.manifest file,
but i can't actually do any testing because it doesn't work under
wine.
so, pending any further advice and guidance from anyone which allows
me to successfully proceed, i'm not going to continue to compile - or
release - python2.5 *or* python2.6 builds (when i get round to that)
using msvcr80 or msvcr9X.
one issue in favour of this decision is that the DLL that's produced
by the autoconf build process is "libpython2.5.dll.a" - not
"python2.5.dll".  it has a different name.  it should be abundantly
clear to users and developers that "if name equals libpython2.5.dll.a
then duh build equals different".  additionally, the setup.py
distutils all goes swimmingly well and lovely - using
libpython2.5.dll.a.
the only issue which _is_ going to throw a spanner in the works is
that people who download win32-built precompiled c-based modules are
going to find that hey, "it don't work!" and the answer will have
to
be "go get a version of that module, compiled with mingw, not MSVC".

of course - if python for win32 ENTIRELY DROPPED msvc as a development
platform, and went for an entirely free software development
toolchain, then this problem goes away.

thoughts, anyone?

l.

On Tue, Jan 20, 2009 at 08:02, Luke Kenneth Casson Leighton
<luke.leighton at googlemail.com> wrote:
> of course - if python for win32 ENTIRELY DROPPED msvc as a development
> platform, and went for an entirely free software development
> toolchain, then this problem goes away.
That's a non-starter for anyone who incorporates Python in an existing
MSVC-based development environment.

When in Rome...

-- 
Tim Lesher <tlesher at gmail.com>