[GRASS-dev] g.extension not working on debian - grass 6.4.3svn

Paulo van Breugel p.vanbreugel at gmail.com
Tue Jan 29 02:17:39 PST 2013


Just recompiled grass 6.4 (completely clean):

* The earlier mentioned problem with g.html2man not being in the right 
folder was solved, it appears in the tools folder now

* It did not solve the problem of omitting the parameter part in the 
manual page. When installing addons (tried script and py addons) using 
the g.extension gui interface (only showing the error messages):

...
ERROR: G_getenv(): Variable LOCATION_NAME not set
....
ERROR: G_getenv(): Variable LOCATION_NAME not set
...
WARNING: Unable to parse 
'http://grass.osgeo.org/addons/grass6/modules.xml'. Metadata file not 
updated.
Installation of <r.csr> successfully finished

* The addon does not appear in the list when using the 'remove 
extension' gui interface

All is run from within GRASS (using the menu 'settings-addon 
extensions'). Just to be complete, running e.g, r.mess 
--html-description from the command line does give the expected html 
file with the NAME, KEYWORDS and SYNOPSIS sections (i.e., the ones left 
out in the manual tab).

Cheers,

Paulo


On Mon 28 Jan 2013 10:58:50 PM CET, Paulo van Breugel wrote:
> Hi Hamish,
>
> No, I just run it from within GRASS.  But let's see if it works with
> the latest version (I'LLC try tomorrow).
>
> Thanks!
>
> Paulo
>
> On Jan 28, 2013 10:14 PM, "Hamish" <hamish_b at yahoo.com
> <mailto:hamish_b at yahoo.com>> wrote:
>
>     Margherita wrote:
>     > Hamish,
>     > KUDOS! It works like a charm, tested with addons in C, in
>     > python and in bash.
>     > Thanks A LOT!
>
>     glad to hear it. It's just the first step though, making sure it
>     also still works from the various packages (esp. Mac) is needed.
>
>     Paulo, re.:
>     > ERROR: G_getenv(): Variable LOCATION_NAME not set
>
>     I'd again ask Markus's question- are you trying to run the script
>     from outside of GRASS? The help pages get their usage info auto-
>     matically from a modified version of 'g.module --help', so if
>     you try to run it from outside of GRASS the module fails to run
>     and that's the error you are seeing. During the main build we
>     don't have a grass session to use for that so we employ a trick
>     that creates a fake grass session (called "demolocation", perhaps
>     a poor choice of words) and runs it there. The bootstrapping from
>     that to the installed stripped down build system for g.extension
>     and self compiled addon modules or self-supplied scripts  is in
>     large part the cause of all the trouble we've had with this, it's
>     a multicontext situation. But solvable, and hopefully that part of
>     it is all ok now.
>
>
>     regards,
>     Hamish
>


More information about the grass-dev mailing list