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

Hamish hamish_b at yahoo.com
Thu Nov 24 16:56:58 EST 2011

> > 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/ ?
> 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

> 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:

                 / 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


More information about the grass-dev mailing list