[GRASS-dev] g.extension not working on debian - grass 6.4.3svn

[Hamish]

[hi all, popping my head in for a few minutes but still mostly
offline for another few weeks]

Margherita wrote:
> > After having tested g.extension (svn-releasebranch64)
> > with fresh installation both on Debian and on Red Hat, both
> > with default installation and on local installation (bindir
> > and prefix in /home/somewhere), FWIW, the result is that the
> > only way to make it work is to compile grass without
> > installing (make without make install).

Markus N wrote:
[...]
> Then you probably see where is goes wrong.

I'm pretty sure I know what's wrong with the Debian/Ubuntu side,
and will try to explain it.

>From the error message posted, it is failing in the g.html2man
step, first check that the svn checkout was done from a totally
clean dir, and that you totally remove any previous install in
the same /usr/local/ install dir.

It's all supposed to work auto-magically now, but it has trouble
if there's left over files from a previous install. The fun is
because we like to make grass work from both the source build
dir and "properly" installed.

Specifically, in the source code, g.html2man script is in a
tools/g.html2man/ subdir, while once "properly" installed to
/usr/local/ (or /usr/ if coming from an official package) the
script just lives in tools/. The magic part of it is the Makefile
install script (or packaging rules as in the case of official
Debian packages) which adjusts the build script to look for the
right file in the right place. If it tries to install the script
but there is already a directory there by the same name, it fails.
And/or if the adjustment to the Make.* file fails it can try to
run g.html2man from the wrong place.

I had hoped that the stale-file problem would just go away with
time as the change was made a long time ago, but it seems to
persist or still have a bug in it. So I think the next step is
to add some gratuitous checks and double-checks to try and
forcibly remove dirs before installing the script, and test if
the script is a script before trying to run it, and adjust the
executable name on the fly. I hadn't done this already as that
stuff needs to happen in the Makefile, and I'd prefer to keep
those as clean as possible. Bourne shell can be ugly enough
without the extra single-line constraints of a Makefile.

note the make install step (or packaging scripts) must also
adjust the location of the include dir. that may work unupdated
as long as the source tree still exists on the drive, but only
by accident and only as long as the source tree is there and in
a similar state.


regards,
Hamish