r.shade not in menu

[cmbarton]

The new r.shade module is not in the menu. It should probably go under raster/manage colors or raster/terrain analysis.

[annakrat]

The same as #2527.

[cmbarton]

This IS missing from a fresh checkout of GRASS 7.0 beta 4. I am reopening.

[wenzeslaus]

Replying to cmbarton:

This IS missing from a fresh checkout of GRASS 7.0 beta 4. I am reopening.

Same as #2527. It should be already in beta4. It is in the source code:

• trunk: source:grass/trunk/gui/wxpython/xml/toolboxes.xml#L786​
• 70 release branch: source:grass/branches/releasebranch_7_0/gui/wxpython/xml/toolboxes.xml#L786​
• 700beta4 tag: source:grass/tags/release_20141222_grass_7_0_0beta4/gui/wxpython/xml/toolboxes.xml#L788​

Please look to source code you are using, do svn status, svn diff and svnversion. Run also g.version -ge. Clean your GRASS with:

make clean
make distclean
svn revert -R .

Then remove all what svn status is reporting as untracked (? ...).

[neteler]

Replying to cmbarton:

This IS missing from a fresh checkout of GRASS 7.0 beta 4. I am reopening.

I suspect a local problem because Vaclav changed it properly:

​http://trac.osgeo.org/grass/changeset/63636#file5

Timestamp: 12/19/14 20:56:06

which was 3 days before tagging beta4:

​http://trac.osgeo.org/grass/browser/grass/tags/release_20141222_grass_7_0_0beta4

[cmbarton]

To clarify:

1. The problem is not that the modules are missing but that they are not available from the GRASS menu.

2. The beta 4 source I used was a fresh checkout, not an update.

Given the discussion, I suspect that the problem likes in the broken ./wxpython/XML compiling. I am checking now.

[cmbarton]

I can confirm that this is a function of the broken XML compiling. I tried 3 different workarounds. The 3rd one finally created the proper menus with the missing modules (and maybe others I hope).

Since we are no longer building the menu tree manually (in theory a good idea), it is very important that this compiles properly.

Michael

[wenzeslaus]

Replying to cmbarton:

I can confirm that this is a function of the broken XML compiling. I tried 3 different workarounds. The 3rd one finally created the proper menus with the missing modules (and maybe others I hope).

I don't know what are your workarounds. The only workaround I know about is to run make in gui/wxpython directory inside running GRASS session. This so far worked for everybody who needed that.

The fact that GUI started for you and that you had some menus shows that you had some menu or toolbox XMLs somewhere. Perhaps you experimented with custom menus and you had something in home directory? Or you were running different GRASS? Or compiling to directory with existing build? Or you might be doing install step which I personally haven't tested much but there were no problems so far?

Since we are no longer building the menu tree manually (in theory a good idea), it is very important that this compiles properly.

As I said earlier, I don't know how to fix the compilation. Martin tried and it helped for some cases but not for all. The best solution I can do is to make toolboxes independent on wxGUI which is discussed in #2142. However, it is important to know that this just hides the compilation issue by not requiring complete runtime environment during compilation, specifically no wxPython. I had no time to work on it so far but all I know is noted in the ticket, so feel free to re-assign.

[cmbarton]

Is there some way to force an update to the menu from the command line after compilation? A couple of the workarounds involved running a python make from within GRASS.

[cmbarton]

Workarounds:

1. a) Make GRASS,

b) make binary package (bindist), c) start binary (gui crashes) d) cd to wxpython folder inside binary package from the GRASS terminal (e.g., /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython), and run make)

Failed to update xml for me

2. a) Make GRASS,

b) make binary package (make bindist), c) start binary (gui crashes), d) cd to wxpython folder inside binary package from the GRASS terminal (e.g., /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython), e) run the following

python core/toolboxes.py > xml/menudata.xml python core/toolboxes.py "module_tree" > xml/module_tree_menudata.xml

f) Next, copy the newly created menudata.xml and module_tree_menudata.xml files from the binary package back to the compiled but not packaged distribution (in ../dist.x86_64-apple-darwin13.0.0), g) rerun bindist to make a new package

This works

3. reuse the menudata.xml and module_tree_menudata.xml files in a new GRASS compilation before doing a binary distribution with the (apparently erroneous) assumption that these menu xml files dynamically updated when GRASS was run.

Failed to update xml files

[wenzeslaus]

Replying to 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.

How it works with binary distribution or make install, especially on Mac OS X, I have no idea but you can easily encounter some problems with access rights or not execute the whole procedure, e.g. running just make and not make install, I guess.

[neteler]

Replying to cmbarton:

Workarounds:

1. a) Make GRASS,

b) make binary package (bindist),

IMHO you are missing 'make install' here which is needed before running 'make bindist'.

[cmbarton]

make bindist runs instead of make install.

Make install is for Linux (though it can be used on the Mac too). Make bindist makes a *.pkg file that can be generically installed on other computers. It includes a package of additional files, including the required version of wxPython, so that it will run on most other machines without additional dependencies.

Make install won't fix the xml file problem as far as I can tell. This is a failure during make. No one seems to be quite sure what is going on, but it seems like Python code is called during make that ignores the environment settings for the shell that make is running in. This causes the Python code to fail and the xml files to not have their contents updated.

Michael

[cmbarton]

Replying to wenzeslaus:

Replying to 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?

How it works with binary distribution or make install, especially on Mac OS X, I have no idea

This in general is part of the problem, not for you specifically but for most GRASS devs

but you can easily encounter some problems with access rights or not execute the whole procedure, e.g. running just make and not make install, I guess.

This is not a problem in my case at least. Thanks for the suggestions.

Michael

[wenzeslaus]

Replying to cmbarton:

Replying to wenzeslaus:

Replying to 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).

[cmbarton]

Replying to wenzeslaus:

Replying to cmbarton:

Replying to wenzeslaus:

Replying to 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. But to launch the GRASS in the dist folder, what is the launching script called? I don't see anything that is obvious.

Michael

[wenzeslaus]

Replying to cmbarton:

Replying to wenzeslaus:

Replying to cmbarton:

Replying to wenzeslaus:

Replying to 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

[cmbarton]

Replying to wenzeslaus:

Replying to cmbarton:

Replying to wenzeslaus:

Replying to cmbarton:

Replying to wenzeslaus:

Replying to 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.

[cmbarton]

Here is an update.

AFAICT, you can't run GRASS from the ../dist... folder on the Mac. It won't start because it needs environmental settings provided by packaging as an *.app.

I can run another version of GRASS, cd into the source ../wxpython directory.

make clean make

will create the xml files

running the following, without make clean will also generate them.

python core/toolboxes.py > xml/menudata.xml python core/toolboxes.py "module_tree" > xml/module_tree_menudata.xml

But then I have to copy the xml files into the ../dist... folder before making a binary package.

[wenzeslaus]

This was a local problem. Please, open a new ticket if you have other issues.