Hamish wrote: > perhaps for grass7, but 10 years worth of backwards > compatibility with the implementations in grass5 and > grass6 says otherwise for those.
I think perhaps I should say something about why GRASS_ADDON_PATH came to be. This isn't THE history, but it is a history; you were there & I don't mean to be condescending or anything, just to explain where I'm coming from since we seem to be looking at this from different perspectives. [If you are too busy to read this little story, skip down to the "Back to the issue at hand" paragraph below.] once upon a time if you wanted to compile a non-standard module obtained from elsewhere or self-written you had to copy it into the source tree (e.g. into raster/r.module/), or symlink it there, and compile with `gmake5`. it then (optionally) got installed into your GISBASE. and all was good until you did a 'make clean'. worse, if you installed a new version of GRASS and uninstalled the old one, you lost access to your self-compiled module, so it was nice to copy it somewhere outside of the install dir which got replaced every few months. so far, so obvious, and fwiw I maintain a `gmake6` alias which runs `make MODULE_TOPDIR=...` which is generally what I use instead of g.extension, but then again I've got the source code installed which is a special case. --it's probably worth noting here that if the GRASS ABI changed you had to recompile, but the same is true for things compiled with g.extension today, although luckily we have the GIS_H version test these days. At the same time, and I'd expect much more common but _invisible to developers_, people were writing their own scripts to do their own little jobs connecting the building blocks "do one thing well" modules together in a similar fashion to the GUI graphical modeler. For example, my ADDON_PATH is littered with dozens of these work related scripts (reusable macros if you prefer) and a few personal preference shortcuts (e.g. see d.stations in addons svn; it's not really a module, just a glorified alias). mainly these are the cache of scripts to run some set of analyses or generate some reusable plot template. they are not modules, but are the personal repository of workflow scripts. That is not to say there are no personal modules mixed in there, far from it, only to say that there are both modules and user-scripts to consider and to accommodate. anyway, back to the story: So eventually with grass6 we abandoned contrib/ and the list of external addons maintained on the website, and started the grass wiki and its list of addon modules. And then as some of those external websites started to go 404, about the same time as we moved to trac svn, and the addons svn was born as a more permanent home. Finally some of the things in the addons svn matured and become rather interesting to others, and non- developer users had some trouble compiling them, and so Makefiles started to pop up in the addon module dirs, g.extension came to be, a bit later Makefiles were added to compile collections of addons, and most recently the osgeo4w addon collection. (as `make` is not happy to run due to spaces in path names, and most people will not install to C:\GRASS-6.4.1\) With about 20% of all public GRASS modules being addons, and easier access to them, progress has been good and we seem to be on the right track! A small digression: With automatic compiles of everything with a Makefile in addons svn there is the conceptual conflict in addons being a module incubator, or is it a home for finished, release quality modules? A svn sandbox had been added, but I'm still not fully convinced that addons svn should be abandoned as a place for still-in- development works, and what the role of the sandbox should be. Mainly I think where things grow organically is a better guide than any planned rule, so I'll wait and see where that goes with an open mind. Back to the issue at hand: I get the point about addon modules in theory being drop-in additions to the normal source tree, and so experiencing the same fate and expectations (in a relative dir sense) as an official module, but my main point here is that GRASS_ADDON_PATH over the years has been as much, if not more so, useful as a place to put your end-user scripts, not "modules" at all. And GISBASE, or a GISBASE-alike, makes no sense in the context of a script which is not a module. In practice mine has held both self-built modules and non-module grass user-scripts to varying degrees, what I object to is imposing refugee status on the personal work-scripts at this late stage in a stable 6.x release series by redefining GRASS_ADDON_PATH into a GRASS_ADDON_BASE. For backwards compatibility we must keep GRASS_ADDON_PATH in grass6 in the $PATH, and so this is just silly, for no gain: PATH="$PATH:$GRASS_ADDON_PATH:$GRASS_ADDON_PATH/bin:$GRASS_ADDON_PATH/scripts" vs PATH="$PATH:$GRASS_ADDON_PATH" symlinks are one way to do that, but not ideal for Windows. (but g.extension doesn't work there anyway, so I wonder if in practice that actually matters?) Anyway simply combining $ADDONS/bin/ and $ADDONS/scripts/ avoids the symlinks and makes avoids the unnecessary dir structure ta boot. If i.pr or some advanced addon wants some other part of the GISBASE structure, still no problem, it still gets installed. Since g.manual(.sh) and the guis know nothing of GRASS_ADDON_PATH (yet), there is no backwards compatibility to break if we move $ADDONS_6/man/man1 into docs/. No code is depending on that, and it isn't making the man pages difficult to discover when exploring by hand. Ah well, enough rambling.. gobble gobble, Hamish _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
