Development

GRASS License

The GRASS GIS project is developed under the terms of the GNU General Public License (the GPL) in the open by volunteers the world over.

• How the Open Source software development model works

• Wikipedia entry discussing the GPL
• The Software Freedom Law Center's Legal Issues Primer for Open Source and Free Software Projects

Resources for Developers

Communication

• You can contact GRASS folks in IRC
• Developer mailing list

Documentation

• GRASS 8 Programming Manual

GRASS libraries are self-documenting using Doxygen header comments.

• GRASS Programming Howto (partially outdated)
• Scripting tips
• Updating GRASS Documentation How-To

• GIS Concepts and how they are implemented in GRASS
• Large File Support (LFS) implementation
• Eclipse tips how to use the Eclipse IDE for GRASS development

Debugging

• GRASS Debugging

Code

• Tracking bugs, patches and feature requests
• GRASS AddOns - User code contributions (custom scripts, modules, icons, etc)
• Compile and Install hints
• Lines of source code:
  • GRASS SLOC analysis 2004

Code submission procedure

• Creating Patches
• Submit patches to the trac system
• Core developer write access

Code submission standards

• General notes
• C language coding standards
• Python script coding standards
• wxGUI: wxPython-based GUI code
• User message standardization: formatting, standard phrases, i18N etc.
• Documentation coding standards (manual pages)

See also:

* RFC 7: Language Standards Support: C and C++ Language
* RFC 8: Language Standards Support: Python

Explanation of C indentation rules

(see C language coding standards)

-bap	Force blank lines after procedure bodies.
-bbb	Force blank lines before block comments.
-bli1	Indent braces 1 space.
-bls	Put braces on the line after struct declaration lines.
-br	Put braces on line with if, etc.
-cbi0	Indent braces after a case label 0 spaces.
-ci4	Continuation indent of 4 spaces.
-cli0	Case label indent of 0 spaces.
-d0	Set indentation of comments not to the right of code to 0 spaces.
-di0	Put variables in column 0.
-fc1	Format comments in the first column.
-hnl	Prefer to break long lines at the position of newlines in the input.
-i4	Set indentation level to 4 spaces.
-ip4	Indent parameter types in old-style function definitions by 4 spaces.
-l80	Set maximum line length for non-comment lines to 80.
-lc80	Set maximum line length for comment formatting to 80.
-lp	Line up continued lines at parentheses.
-nbad	Do not force blank lines after declarations.
-nbbo	Do not prefer to break long lines before boolean operators.
-nbc	Do not force newlines after commas in declarations.
-ncdb	Do not put comment delimiters on blank lines.
-nce	Do not cuddle } and else.
-ncs	Do not put a space after cast operators.
-nfca	Do not format any comments.
-npcs	Do not put space after the function in function calls.
-nprs	Do not put a space after every '(' and before every ')'.
-npsl	Put the type of a procedure on the same line as its name.
-nsob	Do not swallow optional blank lines.
-pi4	Specify the extra indentation per open parentheses '(' when a statement is broken.
-sbi0	Indent braces of a struct, union or enum 0 spaces.
-sc	Put the `*' character at the left of comments.
-ss	On one-line for and while statments, force a blank before the semicolon.
-ts8	Set tab size to 8 spaces.

GRASS Makefile writing

PGM must be set before including Module.make.

In general, the point at which variables get defined doesn't matter if they are only used in commands, but it matters if they are used in the dependency line. Essentially, dependency lines get expanded at the point they are read, while commands are expanded at the point they are executed.

The list of variables where the order is significant is:

       PGM
       LIB_NAME
       SUBDIRS
       CMD_OBJS
       LIB_OBJS
       LOCAL_HEADERS
       EXTRA_HEADERS
       DEPENDENCIES

The "documentation" for writing Makefiles boils down to: try to find something similar in the main GRASS tree and use its Makefile as a reference; if there isn't one, or if that doesn't work, ask on the developers' list.

Writing documentation for this will result in either wasted effort (from describing situations which never actually happen) or inadequate documentation (from failing to describe situations which actually happen) or (most likely) both.

A couple of points about wx.metadata specifically:

1. Using "parsubdirs" won't work as, because mdlib (presumably) needs to be built before any of the modules.

2. Files should not be installed using "cp"; use $(INSTALL) for anything which should be installed with execute permission or $(INSTALL_DATA) for anything without it.

3. Directories shouldn't be copied with "cp -r". Rather, the individual destination files should be listed as pre-requisites, so that "building" the target "builds" the destination files (typically via pattern rules).

wx.metadata/Makefile should probably include "templates" and "config" in $(SUBDIRS). These would have their own Makefiles; e.g. for templates/Makefile, something like:

       include $(MODULE_TOPDIR)/include/Make/Other.make
 
       DSTDIR = $(ETC)/mdlib/templates
 
       SRCFILES := $(wildcard *.xml)
       DSTFILES := $(patsubst %.xml,$(DSTDIR)/%.xml,$(SRCFILES))
 
       default: $(DSTFILES)
 
       $(DSTDIR)/%.xml: %.xml:
               $(INSTALL_DATA) $< $@

This should allow wx.metadata/Makefile to be a simple "directory" Makefile (i.e. set SUBDIRS, include Dir.make, "default: subdirs").

GitHub

• Repository: https://github.com/OSGeo/grass/
• Working with git in GRASS GIS development
• GRASS commit mailing list archive

QA

• Official document about Quality Control measures: https://grass.osgeo.org/development/code-submission/
• Automated GRASS GIS testing suite
• grass-commit mailing list (showing the diff's)
• Coverity Scan
• Travis-CI
• Historical QA:
  • Code Quality Control System Mailing list
  • Testing GRASS software - a test protocol based on the Spearfish sample data set
  • External GRASS test suite (TU Berlin)
    • GRASS Test Suite a small test suite for GRASS, the current html output is available here and with memory check here
  • External GRASS Quality Assessment and monitoring system (École Polytechnique de Montréal and FEM-CRI (since 2008; from 2005-2007 ITC-irst was the partner))

Code Search and Metrics

• Google Code Search

• Openhub Metrics

• Koders Code Search

Ongoing and Plans

Overview

• Reports:
  • GRASS Project Update 2007Q1
• Release Roadmap (old Development Roadmap which needs freshening) - please help with testing release candidates
• GRASS Module Porting List (check here if you don't find a certain command in GRASS 6)
• GRASS ToDo List (overview of GRASS related community projects, see also Release Roadmap)
• GRASS 6 Vector TODO
• Vector network analysis ideas (new ideas)
• List of new features in GRASS 7 (and renamed options)

Works in Progress

• Next generation GRASS GUI development

• Native Windows development

• Message standardization and translation

• Cairo display driver

Sandbox (ideas section)

• GRASS 7 ideas collection
• Image processing
• GRDSS (Geographic Resources Decision Support System)
• Ideas on a replacement raster format specification
• add support (at least storage!) of vertical datum and units
• Discussion on Development Specs for standardized messages
• Discussion on add-on manager repository setup: GEM repository
• Discussion of support for time series in GRASS, e.g. for linking to data and models
• Metadata Management ideas
• GRASS Summer of Code ideas

Linking GRASS to external languages

• GRASS-SWIG interface: generic interface to various languages
• GRASS and PHP
• GRASS and Python
• GRASS and Shell: Starting and running GRASS from a script
• GRASS and ABM
• JGRASS

GRASS and QGIS

• Building QGIS/GRASS Windows Binary On Linux (using MinGW)

• Adding GRASS Tools

• QGIS GRASS Cookbook - Recipes for common tasks

• GRASS-QGIS relevant module list

Commercial development for GRASS

This is an unsorted (and most probably incomplete) list of paid development for GRASS GIS

• Comune di Trento (Italy): better vector editing, printing
• ITC-irst:
  • WILMA - Trento Wireless Projekt -> babyGRASS
  • MITRIS traffic-project
  • GRASS 6 vector engine, vector network analysis
• Faunalia, Italy:
  • r.li suite
  • v.in.gpsbabel
  • OGR GRASS vector driver
  • MySQL spatial GRASS connector

• Tekmap Consulting, Canada: NVIZ and many more
• NAVICON CSE, Denmark: GRASS/Qt
• Advanced Computer Systems (ACS), Italy: NVIZ 3D Histograms, Fly-through
• Orkney Inc., Japan: i18N Infrastructure in GRASS 5.0
• Geomodel, Slovakia:
  • r.sun
  • r.flow etc.
• Lockheed Martin LMCO, USA:
  • d.rast.proj
  • d.mon.proj (GRASS 5 contrib)

Related projects

With connections to GRASS

• JGrass - Java based frontend for GRASS incuding extended hydrological modelling tools
• KerGIS - BSD-like licensed fork of GRASS 4.1.5
• GAL - Project to reimplement a GRASS-like GIS using a modern object oriented approach

• pyWPS - Python Web Processing Service (GRASS on the web)
• PROJ.4 - Cartographic Projections Library
• GDAL - Geospatial Data Abstraction Library
• QGIS - Quantum GIS

• OSGeo- The Open Source Geospatial Foundation
• FreeGIS.org - Interactive information base for the GIS Free Software world
• DebianGIS - Project coordinating geospatial software for Debian GNU/Linux

• R statistics - High powered geostatistical analysis engine
• gstat - Multivariable geostatistical modelling, prediction and simulation

Not connected to GRASS

• GMT - The Generic Mapping Tools advanced cartography package
• SAGA GIS - A modern programming method GIS for the geosciences
• uDig - User-friendly Desktop Internet GIS (uDig) web portal
• gvSIG - Similar in nature to QGIS, but written in Java
• JUMP - For viewing and manipulating spatial data-sets, using Java
• Starspan - Mixed raster and vector spatial analysis
• OpenEV - Raster and vector GIS with good support for image analysis