[GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules

[Michael Barton]

Good points.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Thu, 3 Aug 2006 23:19:20 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Paolo Cavallini via RT <grass-bugs at intevation.de>,
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
> nonexisting modules
> 
> 
> Michael Barton wrote:
> 
>>> gis.m menus contain menu entries for modules which are missing for some
>>> reason.
>>> 
>>> i.e. if I compile grass without C++, I don't have r.terraflow, but I sill
>>> will have menu entry for it.
>>> 
>>> Couldn't there be something like script which runs after all module
>>> compilation (before make install?) and masks unavailable module entries?
>>> Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep
>>> menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting
>>> guru, I can't write such script.
>> 
>> This should be a wish, not a bug.
> 
> Actually, I'm not sure that it should even be a wish.
> 
> Leaving the menu entry in place lets the user know that certain
> functionality is "available", even if they have to get a newer version
> or compile GRASS themselves. If the menu entry is simply omitted, they
> won't even consider that option.
> 
> Also, testing whether an executable is present isn't the same thing as
> testing whether or not it can actually be run. It's arguably better to
> treat all such problems in a similar manner (attempt to run the module
> and show any specific errors to the user) than to treat specially the
> case where the executable is absent.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>