[GRASS-dev] [GRASS GIS] #2528: r.shade not in menu

[GRASS GIS]

#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>