#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 cmbarton): Replying to [comment:16 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 > }}} This is for Linux. AFAICT, it's not there for the Mac. -- Ticket URL: <http://trac.osgeo.org/grass/ticket/2528#comment:17> GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev