#2528: r.shade not in menu
--------------------------+-------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: reopened
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: toolboxes, menu, r.shade
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment(by wenzeslaus):
Replying to [comment:15 cmbarton]:
> Replying to [comment:14 wenzeslaus]:
> > Replying to [comment:13 cmbarton]:
> > > Replying to [comment:10 wenzeslaus]:
> > > > Replying to [comment:8 cmbarton]:
> > > > > Is there some way to force an update to the menu from the
command line after compilation?
> > > >
> > > > * compile with `make`
> > > > * run GRASS from `dist...` directory, i.e. using `bin.../grass..`
> > > > * `cd` into `gui/wxpython`
> > > > * `make clean`
> > > > * `make`
> > > >
> > > > This should work. If you want to recompile the toolboxes and not
the whole GRASS, use:
> > > >
> > > > * (in GRASS session)
> > > > * `rm dist.../gui/wxpython/xml/*.xml`
> > > > * `cd` into `gui/wxpython`
> > > > * `make clean`
> > > > * `make`
> > > >
> > > > If you want to script it, you probably have to start GRASS from
command line in the demo location and set the environmental variable
`GRASS_BATCH_JOB` to a script where you have the steps which must be
executed inside GRASS.
> > >
> > > I'll try these. They might at least reduce the number of steps in a
workaround. Do you think that the 2nd one will work if I'm running any
GRASS 7 session? Or must it be the one just compiled?
> >
> > It could work but I wouldn't do that. Mixing two different GRASS
versions (in sense of directories/installations/compilations) will
probably end up in some confusion. The safe way is to use GRASS in
`dist...` and `bin...` directories of the code you are working with; this
is the code which is used during compilation if GRASS session is needed
(and that's the environment you are trying to fake it).
>
> I'd be using the same version, just a different revision.
Yes, using different revisions, this is what I meant. That's not a good
idea. It might turn against you one day.
> But to launch the GRASS in the dist folder, what is the launching script
called? I don't see anything that is obvious.
For the reasons I don't know, the script/binary to run GRASS from
`dist...` is in `bin...`:
{{{
$ ls bin.x86_64-unknown-linux-gnu/
grass71
$ ls dist.x86_64-unknown-linux-gnu/
AUTHORS driver locale
bin etc REQUIREMENTS.html
CHANGES fonts scripts
contributors.csv GPL.TXT share
contributors_extra.csv grass71.tmp tools
COPYING gui translation_status.json
demolocation include translators.csv
docs lib
}}}
{{{
$ head bin.x86_64-unknown-linux-gnu/grass71
#!/usr/bin/env python
#############################################################################
#
# MODULE: GRASS initialization script
# AUTHOR(S): Original author unknown - probably CERL
# Andreas Lange <andreas.lange rhein-main.de>
# Huidae Cho <grass4u gmail.com>
# Justin Hickey <jhickey hpcc.nectec.or.th>
# Markus Neteler <neteler osgeo.org>
# Hamish Bowman <hamish_b yahoo.com>
}}}
{{{
$ ./bin.x86_64-unknown-linux-gnu/grass71 -text
Cleaning up temporary files...
Starting GRASS GIS...
...
> echo $GISBASE
.../dist.x86_64-unknown-linux-gnu
}}}
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2528#comment:16>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
