[GRASS-dev] GRASS extensions/addons mismatch

[Hamish]

Markus Metz wrote:
> IMHO, g.extensions should be only one module, not two versions
> ( one as script, one through the wxGUI).

ideally, but we're here now with two working variants, so let's move on.
Since it is a tricky task to get right for all cases, I don't mind so
much to give the user a second-try method if the first one fails.

IMO the g.extension.py in 6.x should call the .sh version to do the
actual build and install part, and stick to being the intelligent
frontend (just for 6.x). I added a (perhaps less than diplomatic) comment
in the 6.5svn python script at the point in the code that the system()
call should go but it went away.


> Considering that 6.x has two GUIs, any extension installer should
> not be restricted to a particular GUI

(or, importantly, any GUI at all)

[and technically it has 3 GUIs + the CLI, the old xmon based tcktk gui
is still surprisingly nice]

> which for GRASS 6.x means a no-go for the wxGUI version.

I would phrase it as for 6.x the shell version must be there; but that
does not necessarily imply that the wxGUI one must be removed.

I haven't complained about this duplication as the wxGUI tool is rather
nice and opens the door for MS Windows users to install ~100 extra
modules (ie download pre-built copies). That usefulness seems to trump
the maintenance burden and confusion of two work-alikes, and a personal
dislike of cloned code as a concept.


> The GRASS 6.x extension installer should properly install shell
> scripts and C modules and their manuals.

(afaik what is in 6.4svn now does that to everyone's satisfaction)


> For shell scripts under windows, a *.bat file needs to be created

n.b. the Makefile system used by GRASS doesn't like spaces in pathnames,
and there are two ways around that:
 - the user installs to C:\GRASS + C:\osgeo4w and runs "make" locally
 - the user picks from a list and downloads a pre-built copy from Martin's
   server.

currently g.ext.sh is set to send a warning message that it probably
won't work if a space in any of the pathnames is found (any OS), I
hesitate to make that fatal as I'd like to leave the opportunity for
power users to experiment with it getting it to work, rather than declare
that it never can. If they can get past that hurdle creating themselves
a .bat file is easy business. (so for g.ext.sh I haven't bothered)

since most windows users I expect will try the wxGUI menu item first
I don't expect to see many complaints.  [but mention in the release notes]

> Because there are a number of C modules in the official GRASS
> addons, they need to match the current GRASS version and revision,
> otherwise they would bomb out with a library mismatch error.
> I would suggest to keep the version match on the level of RC,
> e.g. addon modules compiled against grass-6.4.2rc2 work only with
> grass-6.4.2rc2 and no other version.

(but let libgis ultimately make that decision based on GIS_H if the user
tries anyway ignoring the mismatched path name)

> People using grass-6.4.2.svn are supposed to know what they are doing,
> i.e. reinstall any addon after every `svn up`.
...
> Apparently this issue is far from resolved, therefore I
> would opt for releasing rc3 asap and fix that in 6.4.3.

fine with me..


Hamish