Extension development

Information outdated, more a historical document but there is still a place for this topic.

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 6.3 Feature Plan - backreference - hopefully extension compilation can be done for 6.3
• 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.

Makefiles

Some notes from discussion with Glynn:

• change RUN_GISBASE and RUN_GISRC to be based on ARCH_DISTDIR - this makes it possible to override them for an extension build. Then move them from platform.make.in to grass.make.in, as they are then not configured values.
  RUN_GISBASE = ${ARCH_DISTDIR}
RUN_GISRC = ${RUN_GISBASE}/demolocation/.grassrc${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR}
• move LIB_PREFIX, LIB_SUFFIX and GRASS_LIBRARY_TYPE from grass.make.in to platform.make.in, as they are configured values. Though, leave the version variables, which are configured values, in grass.make.in? Why not put those in platform.make.in, and have grass.make.in -> grass.make - then there is just one configured make fragment, platform.make.in?
• have 2 values in ARCH_INC and ARCH_LIBPATH, based on ARCH_DISTDIR and GISBASE. In a normal build, they are the same. In an extension build, ARCH_DISTDIR is the extension source "staging area" and GISBASE is the installed binary base, and thus will pick up both as needed. There appear to be a few module makefiles that use GISBASE that should be updated to use ARCH_DISTDIR.
  ARCH_INC = -I$(ARCH_DISTDIR)/include -I$(GISBASE)/include
ARCH_LIBPATH = -L$(ARCH_DISTDIR)/lib -L$(GISBASE)/lib
• some main makefile stuff is needed in the fragments to enable installation in alternate (ie external to installed GRASS) locations. It was suggested to move common install features to an new makefile fragment.
• dependencies need to be taken care of in bin and etc targets. vpath seems to be the key. And it's not critical, as nothing is actually built by dependencies.

GEM

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