Development: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(Update links)
 
Line 48: Line 48:
==== Code submission standards ====
==== Code submission standards ====


* [http://svn.osgeo.org/grass/grass/trunk/SUBMITTING C language coding standards]
* [https://trac.osgeo.org/grass/wiki/Submitting/General General notes]
* [http://svn.osgeo.org/grass/grass/trunk/SUBMITTING_SCRIPTS Shell script coding standards]
* [https://trac.osgeo.org/grass/wiki/Submitting/C C language coding standards]
* [http://svn.osgeo.org/grass/grass/trunk/SUBMITTING_TCLTK Tcl/Tk script coding standards]
* [https://trac.osgeo.org/grass/wiki/Submitting/Python Python script coding standards]
* [http://svn.osgeo.org/grass/grass/trunk/SUBMITTING_PYTHON Python script coding standards]
* [https://trac.osgeo.org/grass/wiki/Submitting/wxGUI wxGUI]: wxPython-based GUI code
* [http://svn.osgeo.org/grass/grass/trunk/SUBMITTING_DOCS Documentation coding standards] (manual pages)
* [https://trac.osgeo.org/grass/wiki/MessageStandardization User message standardization]: formatting, standard phrases, i18N etc.
* [https://trac.osgeo.org/grass/wiki/Submitting/Docs Documentation coding standards] (manual pages)
 
See also:
* [https://trac.osgeo.org/grass/wiki/RFC/7_LanguageStandardsSupport RFC 7: Language Standards Support]: C and C++ Language
* [https://trac.osgeo.org/grass/wiki/RFC/8_LanguageStandardsSupportPython RFC 8: Language Standards Support]: Python


===== Explanation of C indentation rules =====
===== Explanation of C indentation rules =====
(''see [http://svn.osgeo.org/grass/grass/trunk/SUBMITTING C language coding standards]'')
(''see [https://trac.osgeo.org/grass/wiki/Submitting/C C language coding standards]'')


:{| class="wikitable" border="1"
:{| class="wikitable" border="1"

Latest revision as of 13:05, 17 February 2022

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.

Resources for Developers

Communication

Documentation

GRASS libraries are self-documenting using Doxygen header comments.

Debugging

Code

Code submission procedure

Code submission standards

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

QA

Code Search and Metrics

Ongoing and Plans

Overview

Works in Progress

Sandbox (ideas section)

Linking GRASS to external languages

GRASS and QGIS

Commercial development for GRASS

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

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
Retrieved from "https://grasswiki.osgeo.org/w/index.php?title=Development&oldid=26629"