Re-running the script for an installed GRASS addon module re-installs the requested extension. This is a handy way to apply updates or rebuild compiled modules after installing a new version of GRASS.
The default action is to install the files into the first directory listed in the GRASS_ADDON_PATH environment variable. If that has not been set it will default to ~/.grass6/addons/ on UNIX or %APPDATA%\GRASS6\addons on MS Windows. With suitable administrative permissions you can optionally install directly into the main GRASS program directory ($GISBASE).
Help and man pages installed with the module will be available through the g.manual module.
If your GRASS_ADDON_PATH environment variable contains more than one
path, the default action is to use the first directory in the list.
Custom user scripts and installed addons can share the same addons
directory.
Note: Bourne shell and Python scripts run within
GRASS that use the g.parser module must be in the system's
search PATH, or else g.parser will not be able to find them and
complain about a failure to obtain the module's interface description. As
long as the GRASS_ADDON_PATH environment variable is set before
you start GRASS this will be taken care of automatically at startup.
For users building all of GRASS from source code who have also checked out the GRASS-addons Subversion repository, an alternate approach is to cd into the addon module's source directory, then run:
make MODULE_TOPDIR=/path/to/grass/source
UNIX users can set up an alias in their ~/.bash_aliases file:
alias gmake643='make MODULE_TOPDIR=/path/to/grass643/source'
Users with GRASS installed from a GNU/Linux package can build without the full GRASS source code installed, but they will need the associated grass-dev and grass-doc packages installed.
Upgrading the GRASS version and users with multiple versions of GRASS installed on the same system require special care when dealing with compiled addon modules (those written in C and C++ and linking to the GRASS C libraries). If you try to run a compiled C addon module which was built using a different version of GRASS, you will get an error that the module can not find the shared GIS libraries of the other version, or if it can find them it will still check the internal versions and exit with an error if they do not match. In these cases you can simply re-run g.extension to rebuild the module and solve the problem.
You can typically share a single GRASS_ADDON_PATH directory for Bourne shell scripts and Python addon modules written for any version of GRASS 6. Since your Addon modules and scripts will typically be in your user's home directory and thus persist even when GRASS is upgraded or reinstalled, some notes on compatibility:
g.extension r.out.kml
Note that Bourne shell and Python scripts can simply be downloaded from the online Subversion repository browser and moved into your GRASS_ADDON_PATH directory by hand. On UNIX you will likely need to set the executable bit using chmod before the script will run. In this case the associated usage section of the help page will not be created.
Installing addon Python scripts on MS Windows is still experimental and is not guaranteed to work properly at run-time due to association of ".py" file extensions with python.exe. It is possible to run them, but be aware that you will typically need to call them with ".py" as part of the module name.
Last changed: $Date$