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
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
