[GRASS-dev] Re: proposal for grass extensions and addons

Benjamin Ducke benjamin.ducke at ufg.uni-kiel.de
Thu Sep 20 16:04:29 EDT 2007


> scripts, the GEM approach, William's makefile approach, and certainly
> others. It's probably a good idea to settle on a limited number of these
> (e.g., decide on the best way to compile a binary from source, and a best
> way to distribute a binary, etc.).

GEM and its whole approach to packaging source code is actually a pretty
dirty hack. If William can come up with a cleaner, less fatty solution
of compiling modules outside the source tree -- I'll be happy to 
supplant that for what's currently in GEM.
Both William's approach and mine are essentially the same idea. It would
be not much work to make GEM use William's, potentially revised make
system instead of mine. We can also add support for customizable 
extension folder to GEM. I think GEM does a decent job as a GUI to the
installation process. However, we are still left with a few crucial issues:

1. Acquiring super-user permissions for installations (maybe not a 
problem any longer once we have user-definable extension dirs support)

2. Integrating extension modules' HTML man pages into main index without
using the GRASS Make system

3. Binary installs

> 
> With the switch to wxPython, XML will become a viable option without any new
> dependencies. Until then, it would be good not to introduce new dependencies
> to the extent possible.

Also, module installation should be possible, even if GRASS is installed 
  w/o Python support!

> The folder structure is elegant for creating cascading menus. However, it
> has some complications for actually holding extensions that can be
> run--especially from the command line. If a directory holding an extension
> is listed in GRASS_ADDON_PATH, it can be run by simply typing its name from
> the command line. If you put extensions into a nested hierarchy of folders,
> they would all have to go into GRASS_ADDON_PATH to run the extension from
> the command line. This could quickly get unwieldy.

I was actually thinking about ONLY putting the menu description files 
into these folders. Executables would stay in the respective bin 
directories, where they belong (be it $GRASS_ADDON_PATH or some global
system dir).

Benjamin





More information about the grass-dev mailing list