Opened 14 years ago

Closed 12 years ago

#1180 closed defect (fixed)

g.extension fails on install step when GRASS is launched from source directory

Reported by: marisn Owned by: grass-dev@…
Priority: normal Milestone: 6.4.1
Component: Default Version: svn-releasebranch64
Keywords: g.extension Cc: frankie
CPU: x86-64 Platform: Linux


Tested g.extension with current 6.4 branch. Compilation goes fine, still installation fails. It is possible to write into destination directory. I run GRASS directly from source dir (no make install).

Installing v.profile...
+ grep 'default: script' /home/maris/grass_data/personal_spearfish_60/user1/.tmp/glacier/5410.0/v.profile/Makefile
+ '[' 1 -eq 0 ']'
+ test '!' -d /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu
+ test '!' -d /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/bin
+ test '!' -d /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/docs/html
+ test '!' -d /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/man/man1
++ basename /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/scripts/g.extension
+ touch /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/g.extension.5410
+ '[' 0 -ne 0 ']'
++ basename /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/scripts/g.extension
+ rm -f /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/g.extension.5410
+ test -f /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/bin/v.profile
+ rm -f /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/bin/v.profile
+ make MODULE_TOPDIR=/home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu INST_DIR=/home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu install
/usr/bin/install -c  /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/bin/v.profile /home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/bin/
/usr/bin/install: cannot stat `/home/maris/soft/grass_64/dist.x86_64-unknown-linux-gnu/bin/v.profile': No such file or directory
make: *** [install] Error 1

Change History (8)

comment:1 by neteler, 14 years ago

This is a know problem (same here). The problem that in this case the source and target install dir are the same. So a test would be needed to simply skip the installation then as not needed (note that g.extension was written for a properly installed GRASS).

I tried to fix it but cannot obtain the related variables from the Makefile job to obtain the path names (essentially from Platform.make).


comment:2 by hamish, 14 years ago

Cc: frankie added
Keywords: g.extension added

[see also #1178, #854, and less so #620]

on the DebianGIS list frankie wrote:

I guess you mean

# GRASS dirs
GRASS_HOME          = /build/buildd-grass_6.4.0~rc6+42329-1+b1-i386-7qc3Bn/grass-6.4.0~rc6+42329
RUN_GISBASE         = /build/buildd-grass_6.4.0~rc6+42329-1+b1-i386-7qc3Bn/grass-6.4.0~rc6+42329/dist.i486-pc-linux-gnu

which should be:

GRASS_HOME = /usr/lib/grass64
RUN_GISBASE = /usr/lib/grass64 ?

but what about the other dir?

Francesco P. Lovergine

short answer is that I'm not sure what RUN_GISBASE should be for post-build includes. FWIW the demolocation is used for building the documentation which generally needs the command to be run from inside a valid GRASS environment (g.command --html-description).

with respect to where to install new addons on an end user's system (considering that they may not have sudo rights to put them in to /usr/ or /usr/local/, or C:\Program Files\), perhaps we could go for ~/.grass6/addons/ or so and then add that to GRASS_ADDON_PATH automatically (+additionally)? We could recommend that users add GRASS_ADDON_PATH to their .bashrc or equiv. in a closing message from g.extension, but it wouldn't always happen.

need to have another look at how the linux R-cran installed packages register themselves, and maybe press the GRASS_ADDON_ETC into action (a home for user-installed addon man pages?)

Maybe add a new flag to g.extension that tries sudo for a system wide install to /usr/local/ or /c/.../msys/... on Windows? (but then it's really up to the admin to make sure GRASS_ADDON_PATH is set)


comment:3 by hamish, 14 years ago

when 'make install' (or packaging install rules) copies Platform.make to $(PREFIX)/grass-6.4.0/include/Make, it could replace GRASS_HOME and RUN_GISBASE with ${INST_DIR}.

right now the Makefile's install: just does:

-cd ${GISBASE} ; tar cBf - include | (cd ${INST_DIR} ; tar xBf - ) 2>/dev/null

there are some sed commands on the following lines for the font and monitorcap files which may serve as examples.

e.g. after the install by tar:

  -sed -i -e "s#^\(GRASS_HOME.[^=]*\).*#\1= ${INST_DIR}#" \
          -e "s#^\(RUN_GISBASE.[^=]*\).*#\1= ${INST_DIR}#" \

I guess for WinGrass the $INST_DIR wants to be "quoted"?


comment:4 by hamish, 14 years ago

some experimental fixes committed to 6.5svn in r43734-6

please review, comment, improve, etc.


comment:5 by hamish, 14 years ago

As reported on the UbuntuGIS mailing list (ubuntu@ lists.osgeo), after fixing the MODULE_TOPDIR stuff, the build goes forward on a 'make install'ed system, but then fails in the doc building step as tools/g.html2man is not installed by either 'make install' or the distro package.

(I know this bug was supposed to be about when launched from the source dir, sorry, just trying to keep the momentum going)

I propose we install it to $(ETC)/tools/ (where is already living), and I've just committed a patch along those lines to the main Makefile in 6.5svn for review.


comment:6 by hamish, 13 years ago

[see also #1178, #854, #620, r45804, r45796]

comment:7 by neteler, 13 years ago

Some more fixes in 6.4.svn and 6.5.svn. Please retry.

comment:8 by hamish, 12 years ago

Resolution: fixed
Status: newclosed

seems to be fixed.

Note: See TracTickets for help on using tickets.