[Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now

Roumen Petrov bugtrack at roumenpetrov.info
Fri Jan 23 00:46:26 CET 2009

Luke Kenneth Casson Leighton wrote:
>> version. I hope that users will understand that it is disjoint from
>> the python.org version (as they seem to understand fine for the
>> Cygwin build, which already picks up its extension modules also from
>> a disjoint location, which helps to keep the two separate).
>  yes i made the default installation location (--prefix=) c:/python2.5
> _not_ c:/python25 but obviously it _has_ been necessary to make the
> installation of modules into the exact same _style_ of location as the
> msvc build, because it has obviously also been necessary to use
> PC/getpathp.c not getpath.c

I'm thinking about possibility to avoid compatible paths, i.e. to drop
windows specific PC/getpathp.c and to return back to posix getpath.c.
The problem is that MSVC based build is not installed in tree compatible 
to the posix build.
Now I think that GCC(mingw) build has to use same tree as other posix 
builds. Mixing posix build and install (makefile) with paths used by 
from MSVC build require additional changes either in makefile or in 
PC/getpathp.c. In the both case change is more the 100 lines and now I 
prefer mingw to use posix tree. This open another issue. Тhe posix build 
install in fixed location. I think that with a small change in distutils 
(no more then 10-20 lines) we may overcome this.

>  so, .pyd modules will get installed in
> c:/python2.5/lib/site-packages/ and most importantly they'll get
> _looked_ for in there!  for a while, they were being installed in
> c:/python2.5/lib/python2.5/site-packages which was a bit of a mess -
> that's the "unix" style of module locations.  getpathp.c looks for
> "Lib/os.py" whilst getpath.c looks for "os.py"
> there's a whole _stack_ of knock-on effect little things like that.

:) The installation is the last issue.


More information about the Python-Dev mailing list