[GRASS5] Porting list

[Michael Barton]

Hamish,

You are right about shell scripting plus the mapcalc (and other GRASS
commands) offering a powerful development environment, with a built-in way
of getting a nice tcltk interface. Hill-shading, changing
mapset/location/gisdbase, and Brovey transforms are good examples of widely
useful and powerful scripts.

Python and perl provide even more versatility. But working in python or perl
requires that these languages be installed on user machines. (I am thinking
about people creating custom modules that others can use). While both are
freely available and are normally installed on Linux systems, python does
not come normally on Mac OSX (I think perl does, but I'm not sure since I
installed both on my systems along with other things quite awhile back), and
neither come with windows (though you can add them to cygwin). This can be a
significant installation step for people outside the Linux/Unix world.

Still there are some applications that still might really require that new
modules be written. In such cases now, anyone else using the module needs to
have a self-compiled version of GRASS so that they can compile the new
module against it. This really limits the number of people who can use it.

However, if the new module is a pre-compiled binary, can't it just be
inserted into the proper locations in a compiled GRASS binary distribution
(e.g., /bin, /included, and/or /lib)? This assumes, of course that it is
compiled for the OS properly (though I wonder how much this matters for a
module that is simply using the rest of the OS-specific compiled grass
code?). I guess what I'm asking is, 'is there any reason a module cannot be
compiled so that it can simply be added to an existing GRASS installation as
a binary, rather than needing to be compiled against it from source?'

Certainly for scripts, and possibly for other ways of creating modules, it
would then be very nice to have an easy way for users to add modules to the
menu system for easy use. Lorenzo Moretti has proposed an 'extension' menu
heading (and added QGIS to it as a test). But for this to work well, it
would be necessary to make a small installation/deinstallation routine that
in essence would add (or remove) a line to the tcltk code for the extension
menu exec-ing the module in question. I would think that the easiest way to
do this would be to have the extension menu code as a separate, editable
file that would be sourced from the main menu. Items added to it would show
up in the extension menu.

The goal, would be to get more people involved in writing scripts,
python/perl, or C modules that could be easily added to an existing GRASS
installation. I hope you can excuse my rambling here. I've been thinking
about this for awhile, but have never had time to put together a concrete
plan for doing this. So perhaps if I at least make the suggestion in a
schematic way it might generate some interest.

Cheers,
Michael

On 11/2/04 5:55 PM, "Hamish" <hamish_nospam at yahoo.com> wrote:

>> Overall, I'd personally like to see:
>> 1) more generic tools and less very specific ones (e.g., a generic
>> anisotropic spreading module rather than just one specifically for
>> wildfires), and
>> 
>> 2) an easier way for users to develop and add in specific tools to
>> GRASS-along the lines of a 'plugin' or an ArcView extension. (Except
>> for scripting, this currently requires programming in C and users
>> compiling from source to add a particular new function.) This way,
>> users could more easily tailor GRASS to their particular needs while
>> development could focus on powerful, generic tools that could be
>> adapted to many specific uses.
> 
> (1) provides (2) via shell scripting or with "simple" languages like
> python or perl. If we provide generic low level commands (eg mapcalc),
> then C isn't needed to get things done (it's just more efficient).
> I think we already do this pretty well.
> 

____________________
C. Michael Barton, Professor of Anthropology
School of Human, Cultural, and Social Change
PO Box 872402
Arizona State University
Tempe, AZ  85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>