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