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
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
