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

William Kyngesburye kyngchaos at kyngchaos.com
Tue Dec 19 00:59:39 EST 2006


On Dec 18, 2006, at 10:23 PM, 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?)

-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect





More information about the grass-dev mailing list