Extension development

General

Gather ideas and resources on developing extensions. Especially for installing extensions external to the main GRASS installation.

Other Pages

• Development GEM - Current GEM SVN setup
• GRASS 7 Conceptual Changes - formalizing a user GRASS prefs and addons dir

Environment variables

Setting environment variables should be left up to the user or build startup.

Currently, there is a relatively new GRASS_ADDON_ETC. It is a list of paths which point directly to "etc/" directories where an external module can find any support data files or programs it needs (an example is the adinit.dat file needed by v.in.dwg). It is used by the libgis function G_find_etc(), and the general module g.findetc.

There is also GRASS_ADDON_PATH, which has been around for many years, and is a list of paths to "bin/" dirs where external modules can be found. This is appended to the shell PATH.

To simplify the possible need for an extension to need any of the standard dirs - bin, include, lib, etc, scripts, docs,... - I suggest a variable having paths point to the common root of those, say GRASS_EXTN_DIR. Then, as necessary, the appropriate subdir would be added. ie init.sh would add */bin to the shell PATH and */lib to [DY]LD_LIBRARY_PATH. This can easily support the $HOME/.grass7 dir idea in the future.

GRASS_ADDON_PATH should be kept for backwards compatibility, and it can still be useful for random user scripts. GRASS_ADDON_ETC should at least be deprecated, if not completely removed - it's a recent CVS addition and I doubt anyone has used it yet.

Compilation

In 6.3CVS, the Makefiles are now installed. With a little Makefile cleanup, and a few extra necessary items installled (demolocation and a couple tools), an installed GRASS can support compiling an extension without needing the full GRASS source, and without needing any extra module setup (as is needed currently by GEM-enabled modules). A standard GRASS module Makefile is all the would be needed.

[...in progress... more to come...]