[GRASS-dev] build errors in trunk with make -j 4

Glynn Clements glynn at gclements.plus.com
Thu Jan 7 22:08:10 EST 2010


Anne Ghisla wrote:

> > v.krige is a known problem, and isn't specific to parallel builds. It
> > imports modules from wxGUI (even if you just use --help etc), but the
> > "scripts" directory is built before the "gui" directory, so those
> > modules aren't present in $PYTHONPATH when v.krige is initially
> > "built". If you try again when the rest of GRASS has been built, it
> > will work.
> > 
> > Also, v.krige will use the system Python when it may need to use
> > $GRASS_PYTHON (as it uses wxPython). It should probably be split into
> > a front-end script which invokes the "real" script via $GRASS_PYTHON
> > when (and if) grass.parser() returns; then, --html-description would
> > work without requiring wxPython or any wxGUI modules.
> 
> Hi Glynn, Hamish, all,
> 
> the split is done in r40303, and there are no more errors during make.
> It's far than perfect, so testing and comments are welcome :) 
> ATM, the "Plot variogram" in GUI is not functional as it is matter of
> global variables. I'm looking at this now. 
> 
> I don't understand what is the problem with #!/usr/bin/env python.

On Unix (including MacOSX), this will run whichever Python is in the
PATH, which may not work (it may not have wxPython, or it may not have
the correct version of wxPython).

The user can get around that by changing $PATH (although that might
interfere with the use of Python scripts which aren't part of GRASS).

A more significant problem is that the #! line is ignored on Windows,
which uses the .py file association instead, and the user can't easily
change that (the file associations are per-user, not per-process like
environment variables).

Consequently, anything which runs Python scripts which require
wxPython (e.g. g.gui, G_parser()) invokes the script via
$GRASS_PYTHON.

> How can the scripts use GRASS_PYTHON instead? How is the link
> between this and import wx?

scripts/v.krige/v.krige.py shouldn't use wxPython directly or
indirectly (i.e. it shouldn't import wx or any module which uses wx).
Instead, it should execute the GUI script with e.g.:

	python = os.getenv("GRASS_PYTHON")
	gisbase = os.getenv("GISBASE")
	script = os.path.join(gisbase, "etc", "wxpython", "v_krige_wxGUI.py")
	args = [python, script] + sys.argv[1:]
	os.execvp(python, args)

IOW, Python scripts which may be executed directly by the user from
the command line can only assume the presence of a recent version of
Python (2.4, 2.5 or 2.6) with the standard Python library, plus the
grass.script package. They can't assume that any additional packages
(e.g. wxPython) will be available.

Anything which needs wxPython must be invoked via $GRASS_PYTHON. This
allows the user to specify a suitable version of Python in the event
that the "system" Python isn't suitable.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list