[GRASS-dev] Re: proposal for grass extensions and addons

William Kyngesburye woklist at kyngchaos.com
Sat Sep 22 13:13:11 EDT 2007


On Sep 22, 2007, at 11:17 AM, Michael Barton wrote:

>> Yes. I would be in favour of that: one plugin dir for each user and
>> nothing more (to worry about).
>>
>
> I don't know how g.manual currently searches for the main GRASS doc
> directory, but it seems like it wouldn't be hard to change it to  
> look in a
> doc directory within GRASS_ADDON_PATH.
>
> Like other extension files, this would survive a binary update on  
> Mac and
> Windows.

We should decide if we want keep GRASS_ADDON_PATH as the path(s) to  
bin/ and add GRASS_ADDON_HELP.  Or simplify all the GRASS_ADDON_* to  
GRASS_ADDON_PATH which would be the base of a structured folder with  
bin/, docs/, lib/, etc/ subfolders.

I like the simplifying idea, but it could break users' shell inits  
(for setting their personal scripts dirs) until they reread the docs  
to see what's going on.  And it would make using 6.2 and 6.3 together  
difficult for setting such psersonal scripts dirs.

Maybe a different name base would be best, like GRASS_XTN_PATH  
(matches the 'xtn' naming proposed for the menu file and what's  
currently used in the GEM menus).  We could then keep  
GRASS_ADDON_PATH as a legacy variable in init.sh.  GRASS_ADDON_ETC is  
so new that it could be dropped completely.

>> Also, extensions need to ship with different binaries for different
>> systems. We could try and guess the right ones automatically for the
>> user but I don't suppose there is a portable do of doing that.
>
> Binaries would be highly desirable for many users when possible.  
> But whether
> or not they would get built should be up to the developer to hassle  
> with. It
> isn't realistic to try to create a binary for all possible systems,  
> but a
> limited number could cover a lot (e.g., RPM's, Debian, Mac,  
> Windows). If you
> have a standard directory structure within a GRASS_ADDONS_PATH  
> (e.g., make
> sure that path/bin is listed), it should make it easier to  
> automatically
> install such binaries.
>
Name the tarballs of any binaries with the platform's ARCH (or  
portion thereof) as specified in platform.make.  A user can easily  
see which one they need from the name.  Trying to figure out  
automatically if a binary is appropriate for a platform could be  
simple with this (but could be a bit tricky on OSX with multi-arch  
binaries and compatibility between major OS versions).

A simple script (or binary prog like GEM) can copy them to one of the  
bin/ folders in GRASS_ADDON_PATH (so make tools aren't needed).

> Can I expect to find the following?
>
> 1) a SINGLE ascii menu file, named xtnmenu.dat
> 2) that can be found in the directory specified by GRASS_ETC_PATH
> 3) in which each line contains: "main:<menu item name>:<executable
> name>:<help text>" OR contains "main:separator::"

or a comment.  A structured comment(s) can be used to separate auto- 
generated menus from installers or startup from manually-added user  
menus (or a future menu editor), so that installers/startup routines  
can easily figure out what's theirs to manage.  I believe GEM does  
this currently.

>
> Note the term 'main' as the first line of a xtnmenu.dat file line.  
> The idea
> is that if we add submenus, we can replace 'main' by 'submenu',
> 'submenustart', or something along that line to do nested submenus.
>
> If this is OK, I'll craft a parser in gmenu.tcl with some dummy  
> entries for
> you all to test.
>
Looks good.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike.  Cheating, murdering, lying,  
fighting, and all for things that the beasts of the jungle would not  
deign to possess - money to purchase the effeminate pleasures of  
weaklings.  And yet withal bound down by silly customs that make them  
slaves to their unhappy lot while firm in the belief that they be the  
lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan





More information about the grass-dev mailing list