Opened 16 years ago
Closed 12 years ago
#640 closed defect (fixed)
setup.py may use different Python than configured for GRASS
Reported by: | kyngchaos | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 6.5.0 |
Component: | Compiling | Version: | 6.4.0 RCs |
Keywords: | python | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
GRASS can be configured for a specific copy of Python, which could be needed if a different version than desired is first in your PATH (maybe a newer or experimental, incompatible version). But, when compiling vdigit and wx nviz for the wx GUI, "python" is used, which may not be the same as was configured. This could cause compilation problems, especially on OSX where setup tools compilation is very particular about the MACOSX_DEPLOYMENT_TARGET.
It looks like platform.make would need another variable to hold the python program path, created from "python-config --prefix".
A quick fix until this is done is to temporarily add the desired python bin to the shell PATH for the GRASS build.
Change History (9)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Component: | wxGUI → Compiling |
---|---|
Keywords: | python added |
Milestone: | 6.4.0 → 6.5.0 |
I think something still should be done about it, though it's not critical for release. I can look into it.
comment:5 by , 12 years ago
Well, this bug is from 4 years ago. In the current 6.4.3 RC and 7 sources, there is no setup.py that is run during make. wx nviz and vdigit don't have compiled C code any more, so it's not needed there. I'd call this an invalid bug now. Or fixed by coincidence.
follow-up: 8 comment:6 by , 12 years ago
ok, so the question becomes what uses Python.make, because that's inheriting the hardcoded $(PYTHON) currently, and does it matter? if not for the core build, then for anyone building their own addon modules, &/or being able to specify the one you want when python 3 becomes more popular.
?, Hamish
comment:7 by , 12 years ago
Ah, right.
Looks like in python.make it's just a compile command. Not an issue for the OS X 32bit vs. 64bit problem, but important to compile for the right version of python.
I also found $(PYTHON) in the wx gui makefile. There it's just running python scripts to generate some files, doesn't look to me like the python version is important.
Configuring a PYTHON could also be useful if some wx stuff is run at compile time, to get around the 32bit OS X problem with old wxpython versions, and on OS X wxpython python scripts need to run in pythonw... hmm, there might already be some of those - wx-based modules that are run to generate the help files.
comment:8 by , 12 years ago
Replying to hamish:
ok, so the question becomes what uses Python.make,
Python.make is used by gui/wxpython, gui/scripts, scripts/r.in.wms, and various subdirectories of lib/python.
GRASS 7 doesn't have any C or C++ code which links against the Python library. The preferred way of integrating C and Python code is to use ctypes to access C functions from Python.
The PYTHON make variable exists to simplify the case where the default "python" command isn't suitable for GRASS (e.g. because it's Python 3.x, or it doesn't have the numpy, wxPython, etc packages). In such cases, it can be overridden on the command line, e.g. "make PYTHON=/usr/local/bin/python2".
comment:9 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
bug report presumed obsolete; if you need to specify your python to the build system see comment:8 by Glynn &/or the value in Platform.make.in.
closing as fixed with replacement of compiled wx modules.
Is this now fixed? Or at least as fixed as it is going to get?
Michael