I was trying to compile a python plugin (for gimp) using the MSYS shell and the MINGW compiler. I now have put this in 'sitecustomize' $ cat /c/Python24/lib/site-packages/sitecustomize.py import sys import os import re if os.environ.get("MSYSTEM") == "MINGW32": os.sep='/' os.pathsep='/' sys.prefix = re.sub('\\\\','/',sys.prefix) sys.exec_prefix = re.sub('\\\\','/',sys.exec_prefix) It would probably be better to have python detect that it's running from inside the msys shell, and output '/'es instead of '\'es. maybe someone could extend os.path to do this in the standard distribution: implement an msyspath.py, which calls ntpath for each function, and does a replace at the end of the evaluation. Unfortunately, I'm just starting to look into python, so I do not know what the cleanest implementation of this would be...
On Tue, Jun 28, 2005, lode leroy wrote:
I was trying to compile a python plugin (for gimp) using the MSYS shell and the MINGW compiler.
python-dev is the wrong place for this question; please start with comp.lang.python (or find another suitable place). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng.
On Tue, Jul 05, 2005, "Martin v. L?wis" wrote:
Aahz wrote:
Martin removed the attribution here:
I was trying to compile a python plugin (for gimp) using the MSYS shell and the MINGW compiler.
python-dev is the wrong place for this question
Actually, it isn't - he is really asking what the best way of porting Python to MSYS is.
Hrm. I thought we told people to start with comp.lang.python for porting questions, but I'm happy to be corrected. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng.
Aahz wrote:
Hrm. I thought we told people to start with comp.lang.python for porting questions, but I'm happy to be corrected.
I'm unaware of such a policy, but I may have missed the relevant discussion. I could understand that questions of the kind "I tried to build Python on X, and the compiler gave me the error message Y" are for comp.lang.python - these messages are really the of the "I need help" kind. The specific message was more of the "I would like to change code fragment X to Y to make it work on platform Z" kind - although in the end, he still indicated that he appreciated help. Oh well, Martin
""Martin v. Löwis"" <martin@v.loewis.de> wrote in message news:42CB12F8.9070406@v.loewis.de...
Aahz wrote:
Hrm. I thought we told people to start with comp.lang.python for porting questions, but I'm happy to be corrected.
I'm unaware of such a policy, but I may have missed the relevant discussion. I could understand that questions of the kind "I tried to build Python on X, and the compiler gave me the error message Y" are for comp.lang.python - these messages are really the of the "I need help" kind.
I had the same impression as Aahz: questions about how to use the existing distribution should go to c.l.p. Besides keeping pydev clear, someone once claimed (as I remember) that there are many people with experience building Python on various systems that read c.l.p but not pydev. (Still true? don't know!) On the otherhand, once that fails and someone thinks the codebase needs more #ifdefs, then it does become a pydev matter. And you saw right off that MSYS support might need just that. tjr
lode leroy wrote:
maybe someone could extend os.path to do this in the standard distribution: implement an msyspath.py, which calls ntpath for each function, and does a replace at the end of the evaluation.
The chances are good that nobody else will work on this - so it is likely that it is either you who are doing this, or nobody else. Then, when you eventually come up with a patch, somebody will tell you that you partially erred, and that it should have been done in a different way. Still, I think this might be the only way to come to a solution that gets integrated with Python. I'm personally in favour of supporting "MSYS" as a target system. If you want to do it, I'm willing to review patches, but I'm not willing to do them myself, as I don't use MSYS. If you believe that MSYS is a target system in a way similar to mingw32, and to cygwin, I believe it should get the same treatment as mingw32 and cygwin. That means all places that currently deal with either of these two systems should also deal with MSYS in a similar way. What this means in actual code, I don't know. OTOH, I already fail to follow you in the very first assumption: why is it that you need to change os.sep on MSYS? Regards, Martin
From: "Martin v. Löwis" <martin@v.loewis.de> I'm personally in favour of supporting "MSYS" as a target system. If you want to do it, I'm willing to review patches, but I'm not willing to do them myself, as I don't use MSYS.
If you believe that MSYS is a target system in a way similar to mingw32, and to cygwin,
actually, MSYS is the package that has the command line tools (i.e. bash, tar, cp, automake, ...) required to be able to compile a native windows binary from a source distribution that is depending on autotools.
I believe it should get the same treatment as mingw32 and cygwin. That means all places that currently deal with either of these two systems should also deal with MSYS in a similar way. What this means in actual code, I don't know.
OTOH, I already fail to follow you in the very first assumption: why is it that you need to change os.sep on MSYS?
"configure" detects what the install-path is (python -c "print os.syspath") which returns C:\Python. MSYS uses a bash shell which does not like "\" but needs "/" as os.sep. Anyways, in the mean time, it's been solved in the m4 files... Maybe it's better to ask the automake guys to support Python with MSYS...
Regards, Martin
participants (4)
-
"Martin v. Löwis" -
Aahz -
lode leroy -
Terry Reedy