Hi,
I am trying to work around this QGIS GRASS-plugin bug:
https://svn.qgis.org/trac/ticket/346
(the OSX file picker won't let me select GISBASE which is within a
subdirectory of /Apps/GRASS.app/; it's greyed out)
Q: if I symlink $GISBASE to something else not in /Apps/*.app/ then
point QGIS to the symlink, will I enter into a world of pain?
thanks,
Hamish
A couple notes on the problem.
On Dec 18, 2006, at 1:26 AM, Hamish wrote:
Hi,
I am trying to work around this QGIS GRASS-plugin bug:
https://svn.qgis.org/trac/ticket/346(the OSX file picker won't let me select GISBASE which is within a
subdirectory of /Apps/GRASS.app/; it's greyed out)
Indeed, on OSX you can't navigate into an application package. And, depending on Finder options, you may or may not see the .app extension.
If it's a valid GRASS installation and was built against that particular GRASS, it should work - a unix path can refer to something inside an app package with no problem. As long as that GRASS is not moved, Qgis GRASS plugin should find it and not ask for a GISBASE. Once GRASS is moved, Qgis needs to ask where it now is.
One solution I can think of, and that I'll probably do with my Qgis binary in the future, is to package the necessary GRASS libraries and support in the Qgis app. That way there are no worries of moving GRASS around and having to set GISBASE, or making sure you have the right GRASS version. It works for me with my GDAL framework - currently my Qgis build uses the GRASS libraries I have in my GDAL framework.
I wonder - are you using the Qgis.org download of Qgis and trying to use my GRASS.app with it? This email implies that, though your Qgis bug says Lorenzo's. There *may* be library version incompatibilities.
As for hacking the path, ~/Library/Preferences/org.qgis.qgis.plist. Don't know the setting name to use, though. Maybe GRASS.GISBASE? Or you could try using the GRASS libraries inside my GDAL framework - you can navigate into a framework package. Or try my Qgis build 
-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/
All generalizations are dangerous, even this one.
William Kyngesburye wrote:
A couple notes on the problem.
Hamish wrote:
> I am trying to work around this QGIS GRASS-plugin bug:
> https://svn.qgis.org/trac/ticket/346
>
> (the OSX file picker won't let me select GISBASE which is within a
> subdirectory of /Apps/GRASS.app/; it's greyed out)Indeed, on OSX you can't navigate into an application package. And,
depending on Finder options, you may or may not see the .app
extension.If it's a valid GRASS installation and was built against that
particular GRASS, it should work - a unix path can refer to something
inside an app package with no problem. As long as that GRASS is not
moved, Qgis GRASS plugin should find it and not ask for a GISBASE.
Once GRASS is moved, Qgis needs to ask where it now is.
If I start QGIS from the GRASS command line (your 6.2.1 package), then
$GISBASE is already set and the GRASS plugin works, but $GISBASE is not
stored.
If I start QGIS from outside GRASS it asks for GISBASE, but then I run
into the GRASS.app/ selection problem.
Indeed setting $GISBASE as an enviro var before launching QGIS from a
(non-GRASS) Terminal gets it to work.
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.
One solution I can think of, and that I'll probably do with my Qgis
binary in the future, is to package the necessary GRASS libraries and
support in the Qgis app. That way there are no worries of moving
GRASS around and having to set GISBASE, or making sure you have the
right GRASS version. It works for me with my GDAL framework -
currently my Qgis build uses the GRASS libraries I have in my GDAL
framework.I wonder - are you using the Qgis.org download of Qgis and trying to
use my GRASS.app with it? This email implies that, though your Qgis
bug says Lorenzo's. There *may* be library version incompatibilities.
I am now working with the 0.8pre2 binary from qgis.org + your 6.2.1
package + your 17 Dec frameworks package.
Earlier I was working with Lorenzo's 6.2.0beta2 package + grasslibs.
These are now outdated & removed.
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.
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.
-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/All generalizations are dangerous, even this one.
cheers,
Hamish
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 buildIn 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@kyngchaos.com>
http://www.kyngchaos.com/
"Time is an illusion - lunchtime doubly so."
- Ford Prefect
Oops, used wrong account to send last reply. Anyways, my brain wouldn't let me sleep on this - I figured out a way to get around the OSX package limitation:
1. in the Finder, contextual menu on GRASS.app and Show Package Contents
2. command-option-drag the "Contents" folder to the desktop to create an alias
3. run Qgis and do what you need to do to get it to ask for GISBASE
4. use the alias on the desktop to navigate into the GRASS.app package! Then you can locate and select your GISBASE.
'night
-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/
Theory of the Universe
There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened.
-Hitchhiker's Guide to the Galaxy 2nd season intro
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
On Dec 19, 2006, at 10:27 PM, Hamish wrote:
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.
I took a look at the qgis.org Qgis, and it appears to me like the grass libs in the package are just for library linking for the GRASS plugin/provider. A couple things that are normally found in the GRASS etc folder are missing for QGis to consider this a "GISBASE".
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)
Might be the DYLD_LIBRARY_PATH problem again. Or PATH missing the GRASS bin and scripts folders.
* v.buffer works ok if QGIS was started from the GRASS terminal prompt.
sometimes when reclosing mapset I get this error:
Cannot close mapset. Cannot remove map set lock: /.../$MAPSET/.gislockand 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 foundI've never had GRASS in /usr/local/ on that machine...
That would be the DYLD_LIBRARY_PATH problem. Without the full GRASS environment, GRASS commands can't find the GRASS libraries - it's trying the original build location. Perhaps Qgis needs to do more environment setup, like GRASS does in init.sh?
I tried setting "export LD_LIBRARY_PATH=$GISBASE/lib", no luck.
DYLD_LIBRARY_PATH
Looking at the grass init.sh, there are a few environment variables that Qgis might need to set, if it doesn't already, based on GISBASE, or that you could try from the Terminal as a test:
PATH, to find the GRASS module executables and scripts
DYLD_LIBRARY_PATH, for the libraries
ETC, for support for some modules
-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy