[GRASS-dev] Re: [GRASS-SVN] r49122 -
hamish_b at yahoo.com
Tue Nov 8 22:19:02 EST 2011
> sh: 0: Can't open
ok, things are still slightly confused with the *.make files.
where does your devbr6's $GISBASE/include/Make/Man.make point
to for g.html2man? After a full rebuild it should now point
to $(GISBASE)/tools/g.html2man, while the source/include/Make/...
one should point to $(MODULE_TOPDIR)/tools/g.html2man/g.html2man
from the above it seems that $(GISBASE) has been reset. I expect
this is because within in the makefiles GISBASE has been reset to
the .tmp build dir by setting ARCH_DISTDIR on the make command
Grass.make:GISBASE = $(ARCH_DISTDIR)
..while we wish to keep the variable locked to the "real" GISBASE.
MODULE_TOPDIR happens to be reset to "real" GISBASE by g.extension
which is why g.extension.sh worked for you, but I don't like to
keep it as that as context dependent variable definitions makes
debugging a nightmare, and just adds to the confusion.
we could add a TOOLS= line into Grass.make similar to ETC=, but
we still have the problem of trying to reset the build dir while
still depending on files in the "real" build dir. we're trying
to have it both ways..
Besides $(MODULE_TOPDIR), $(GRASS_HOME) is another potential
variable to play with, but I wonder if g.extension.sh should have
then pass that along on the make command line, and have Man.make
check if that variable exists and use it at run-time if it does.
still seems less than ideal, and doesn't address the root problem
of us hijacking the build dir then the build files getting upset
because files it expects to find are not there in the new temp-
orary build dir structure.
"make REAL_GISBASE" complicates things but to me it seems that
the reuse and misuse of the existing variables is leading us in
(again, AFAIK it is just gr65 run from $src/bin.x86.../grass65
where g.extension.sh has troubles right now)
we'll get there eventually, it is so very close...
More information about the grass-dev