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. Roumen
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4