[GRASS-dev] Installing own Python script

Tue May 31 11:53:32 EDT 2011

Pierre Roudier wrote:

> > The r.mm.html file should not contain the parts which are generated by
> > "r.mm.py --html-description". The build system does this automatically
> > if the .html file doesn't contain an "<html>" tag. This ensures that
> > the .html file is kept up to date if options are added, removed or
> > changed.
> 
> OK, so I understand the HTML file would be generated automatically at
> build time (during the "make" from the top-level dir). Does that mean
> that I can't add more descriptions/references/notes to the HTML file
> manually?

The build system merges the --html-description output with the
<module>.html file (unless the <module>.html file contains an <html>
tag, in which case it is used verbatim; this is intended for modules
which don't recognise the --html-description switch, e.g. g.parser).

Look at the <module>.html files for existing scripts for reference. 
They start with the DESCRIPTION section.

> > The per-module "install" targets are for developers wishing to install
> > individual modules after modifications. As GRASS can be run from the
> > staging directory without being installed, this isn't often required.
> >
> > If this feature is desired for scripts, it should just be a case of
> > adding a slight modification of r43657 to Script.make (change "bin" to
> > "scripts" in the first command).
> 
> What I would like is:
> 1 - Make my r.mm script available from the GRASS prompt, the same way
> other Python scripts like r.grow or r.buffer are available, so I can
> test it,
> 2 - Most importantly, I would like to access my r.mm module from other
> Python scripts using eg grass.run_command('r.mm', input = input, ...,
> flags = flags, quiet = quiet)
> 
> Does that mean I should recompile GRASS entirely after each
> modification made to my r.mm module, or is the per-module install
> option just doing that (sorry I'm not sure I got it right)?

If you're actively developing GRASS, you wouldn't normally install it. 
Just run it using the bin.<arch>/grass70 script. This will set the
environment variables (GISBASE, PATH, etc) to use the version in the
dist.<arch> staging directory.

Running "make" in a module/script/library/etc directory places the
resulting files in the staging directory. If you're running GRASS from
the staging directory, subsequent commands will used the updated
files.

Running "make install" from the top level just copies the whole of
dist.<arch> to the installation directory (e.g. /usr/local/grass70)
and bin.<arch>/grass70 to the bin directory (e.g. /usr/local/bin), and
fixes any embedded paths in scripts and configuration files.

The per-module "install" target (which doesn't exist for scripts at
present) copies a single module (along with its manual page in HTML
and man formats) from the dist.<arch> directory to the installation
directory.

AFAICT, this is only useful if you're pushing your changes into the
installed version so frequently that having to do a full "make install"
from the top level each time would actually be a problem.

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