[GRASS-dev] running with GISBASE as a symlink?

[Hamish]

Ticket URL: <https://svn.qgis.org/trac/ticket/346>

William Kyngesburye wrote:
> Hamish wrote:
> 
> > Also to note WRT hardcoding paths: The first thing I did after
> > installing your GRASS.app was to rename it GRASS_6.2.1.app. Too many
> > machines in the student computer lab to keep track of details  
> > otherwise.
> > Also have that in a /Apps/Grass/ folder, as I store PDF instructions
> > manuals there too.
> >
> I was thinking about the qgis.org build of qgis.  My guess is that it  
> was built with Lorenzo's Grass, so that's where Qgis is going to try  
> by default.  Renaming mine to the same as Lorenzo's (as a  
> possibility) probably wouldn't work because the internals are  
> organized differently.
> 
> >> As for hacking the path, ~/Library/Preferences/org.qgis.qgis.plist.
> >> Don't know the setting name to use, though.  Maybe GRASS.GISBASE?
> >
> > Yes, on the mac it seems to be ~/Library/Preferences/ 
> > org.qgis.qgis.plist
> > But it is a binary file I don't know how to modify/browse that?
> >
> > On linux it is stored in ~/.qt/qgisrc as a simple text file:
> > [grass]
> > gisbase=...
> >
> > so "GRASS.GISBASE" is a good guess.
> >
> I hadn't noticed that it's a binary plist.  I have the Xcode tools  
> installed, so it opens in Property List Editor.  I think there's a  
> non-Xcode plist editor out there somewhere (shareware/freeware).
>
> >> Or you could try using the GRASS libraries inside my GDAL framework -
> >> you can navigate into a framework package. Or try my Qgis build ^_^
> >
> > In the future perhaps, but for now I would like to help fix this  
> > problem at the root.
>
> Well, for workarounds, we can't do much about the OSX limitation  
> (except maybe the symlink, or the plist hacking).  A rebuild of Qgis  
> to use some other GRASS is another possibility (the internal Grass  
> library idea would be a good choice).
> 
> Since you have my frameworks installed, the GRASS libs inside the  
> GDAL framework should work - I specifically tweaked that to support  
> Qgis, in addition to GDAL.  This would be a usable short-term  
> solution, but I'm working on removing external linking to  
> GDAL.framework internals, and the Qgis-GRASS link is the last one  
> left.  My next Qgis build will have GRASS libs embedded.  Don't know  
> what Qgis.org will do with theirs, if anything.
> 
> Now that I think about it, I'm not sure relocating GISBASE will fully  
> work.  When you start Qgis from within GRASS, do the GRASS functions  
> of the plugin actually work?
> 
> The problem I'm thinking of is the actual library links in the Qgis  
> GRASS plugin.  They are hardcoded for the GRASS there were built  
> with, and I don't see a DYLD_LIBRARY_PATH used in Qgis, like it is in  
> the GRASS init.sh.  Possibly it will work when started from GRASS,  
> since it might pick up the GRASS environment.  But initiated from  
> Qgis, it doesn't appear to use GISBASE to set DYLD_LIBRARY_PATH, and  
> so won't find the original GRASS libraries. (did that make sense?)


Ok, I have been trying to get QGIS + GRASS toolbox to work with a full
GRASS install. I have not been trying to get QGIS to work with GRASS files
included in the QGIS package download.

I took the following to mean that it included the GRASS plugin, not that
it included functional copies of the ported modules + minimum framework to
allow those to run.

 1 All packages contain GRASS support unless otherwise indicated.

Am I mistaken? Does the qgis.org 0.8pre2 OSX build include parts of grass?
I see libgrass_* in lib/grass/, and plugin bits in share/qgis/grass/.

If QGIS supplies enough GRASS to be self-contained, then presumably
GISBASE becomes /Apps/qgis.app/something/? At which point it should be
changed to automatically pick the internal (relative) location instead of
prompting for an external GISBASE.

If not, why is QGIS distributing lib/grass/libgrass*.dylib?


some more tests:

* creating a shorcut on the desktop to GRASS.app/Resources/ then pointing
 QGIS's GISBASE file dialog to that gets you started, but it fails when you
 try and run a module (eg v.buffer)

* v.buffer works ok if QGIS was started from the GRASS terminal prompt.

* work-around idea: add 'export GISBASE="/Apps/GRASS.app/..."' to
 .bash_profile   (no luck running a module)


When QGIS is started from outside GRASS, at the terminal:

 $ GISBASE=/Apps/GRASS.app/.../Resources  /Apps/qgis.app/.../qgis

I open a GRASS mapset from the plugin menu, but when I click on a module I
 get this error:

Warning:
  Cannot read module description (v.to.rast)
  Unexpected end of file
  at line 1 column 1

sometimes when reclosing mapset I get this error:
  Cannot close mapset. Cannot remove map set lock: /.../$MAPSET/.gislock

and in the term window:
  dyld: Library not loaded: /usr/local/grass-6.2.1/lib/libgrass_gproj.dylib
  Referenced from: /Apps/GRASS.app/.../r.in.gdal
  Reason: image not found


I've never had GRASS in /usr/local/ on that machine...

I tried setting "export LD_LIBRARY_PATH=$GISBASE/lib", no luck.

When QGIS was started from within GRASS, it works fine and automatically
picks up the current mapset.


Hamish