[GRASS-dev] Re: [GRASS-SVN] r49122 - grass/branches/develbranch_6/include/Make

[Hamish]

(devbr6)

Glynn:
> Man.make still uses MODULE_TOPDIR to locate g.html2man.

that now gets converted to $(GISBASE) at build time for the
copy of Man.make which gets installed to $src/dist.x86..../tools/
see devbr6/Makefile and devbr6/lib/Makefile

the copy of Man.make with MODULE_TOPDIR in the source tree gets
used during standard compiles, and that works 100% fine in that
context, so I don't like to mess with it.  but g.extension is
operating in another context, and that's the problematic issue.


> If it's going to use it "in place", either it should use
> $(GRASS_HOME) or SRCDIR should be set in Platform.make.in.

GRASS_HOME warrants some investigation. SRCDIR misses the point
of running g.extension when the source code is not present on
the end-user's computer.

> [GRASS_HOME is set to $(DSTDIR), which is the current
> directory when configure is run, while $(SRCDIR) is the
> directory containing the configure script.
...
> If we supported out-of-place builds,
> $(SRCDIR) and $(DSTDIR) could differ.]

that's just the thing: g.extension is doing all these contortions
to try and support out-of-place builds (in $MAPSET/.tmp/) for
end-users who installed from a package and get their include/
grass files from a grass-dev package. they don't have the source
tree and don't necessarily have write permission* to the "real"
aka shell enviro var $GISBASE install dir.
[*] or like me don't like to install non-package-managed files
outside of /usr/local or /home, making backups and audits easier

> 7.0 installs g.html2man.py to $(ARCH_DISTDIR)/tools at the
> start of the build process, and the rest of the build process
> accesses it from there (specifically, as $(GISBASE)/tools
> /g.html2man.py).

that won't help here as $(ARCH_DISTDIR) has been redirected to
$MAPSET/.tmp/, and so support files like $MAPSET/.tmp/tools/
won't exist. (Martin ran into that earlier today) thus the need
for something like $(REAL_GISBASE) to keep track of where the
real support structure lives even after the build-into dir has
be redirected to a local+temporary dir.

we're trying to eat our cake and have it too by redirecting the
build destination to one place, while retaining the rest of
the already-built stuff somewhere else. and we can almost get
away with it..
I've never really had the expectation of g.extension working
everywhere, for every module, but for unix based systems I
suspect we can realistically make it to 80%, and 90% with effort.


Hamish