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: grass-dev@…
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 cmbarton, 15 years ago

Is this now fixed? Or at least as fixed as it is going to get?

Michael

comment:2 by kyngchaos, 15 years ago

Component: wxGUICompiling
Keywords: python added
Milestone: 6.4.06.5.0

I think something still should be done about it, though it's not critical for release. I can look into it.

comment:3 by hamish, 13 years ago

what's the current status of this?

comment:4 by hamish, 12 years ago

$(PYTHON) is hardcoded as "python" in include/Make/Platform.make.in.

comment:5 by kyngchaos, 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.

comment:6 by hamish, 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 kyngchaos, 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.

in reply to:  6 comment:8 by glynn, 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 hamish, 12 years ago

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.