[GRASS-dev] grass 6.x g.extension install path layout simplification

[Hamish]

Hamish:
> > For grass 6.x g.extension.sh installs into
> > GRASS_ADDON_PATH, are there any objections to
> > installing the addon man pages to e.g.
> > ~/.grass6/addons/docs/man/ instead of
> > ~/.grass6/addons/man/ ?
Martin:
> I would keep manual pages where they are. At
> least the current directory layout is
> synchronized with $GISBASE.

but there is no dependency that we try to do that.
basically this is finishing the job of installing
the addon module from the build dir. I hate to
repeat this, but GRASS_ADDON_PATH was never
designed to be a shadow GISBASE, and there is no
reason or great benefit for it to try to become one
now.

> Moving manual pages somewhere else makes things
> less clear from my POV.

moving manuals into docs/ is not clear? (from the
end-user's POV) keeping them outside seems weird
and messy to me, and here we have a short window of
opportunity to fix that, or at least to not
propagate the weirdness.

> Same with creating extra symlinks for the
> binaries which eg. on Windows means to create a
> copy of the file.

er, in the original post, the paragraph directly
following the one you quoted above explained the
plan to get rid of those; and (deactivated) code in
devbr6 is ready to do that, just waiting for review.

bin/ and script/ would go away resulting in a dir
structure looking like:

GRASS_ADDON_PATH /
                 / all executables
                 / docs
                       / html
                       / man/man1

very simple and clean for the end-user.
we get to get rid of the cruft and preserve
historical addon usage at the same time.


> In GRASS7 we could move in $GISBASE `man` do
> `docs` directory.

I don't mind that, but it's another matter.

> Don't spend with GRASS 6 too much energy with
> minimal improvement.

Since 6.4.2 will be the first release with a
functional g.extension for end users without the
source code installed (ie most), I think it is
important that we nail down the design decisions
before release, rather than be left with something
suboptimal for the remainder of the 6.4.x usage
lifetime.


best,
Hamish