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

William Kyngesburye woklist at kyngchaos.com
Thu Sep 20 17:03:16 EDT 2007


On Sep 20, 2007, at 3:04 PM, Benjamin Ducke wrote:

>> scripts, the GEM approach, William's makefile approach, and certainly
>> others. It's probably a good idea to settle on a limited number of  
>> these
>> (e.g., decide on the best way to compile a binary from source, and  
>> a best
>> way to distribute a binary, etc.).
>
> GEM and its whole approach to packaging source code is actually a  
> pretty
> dirty hack. If William can come up with a cleaner, less fatty solution
> of compiling modules outside the source tree -- I'll be happy to  
> supplant that for what's currently in GEM.

See also Glynn's comment on the makefile frags already in the  
install.  With what I've figured out for my method, Glynn's helpful  
comments, and your GEM work, I think we can work out something simple  
and flexible.


> Both William's approach and mine are essentially the same idea. It  
> would
> be not much work to make GEM use William's, potentially revised make
> system instead of mine. We can also add support for customizable  
> extension folder to GEM. I think GEM does a decent job as a GUI to the
> installation process. However, we are still left with a few crucial  
> issues:
>
> 1. Acquiring super-user permissions for installations (maybe not a  
> problem any longer once we have user-definable extension dirs support)
>
Indeed, part of the idea is for non-admin users to be able to build  
addons and install them in their home folder.

> 2. Integrating extension modules' HTML man pages into main index  
> without
> using the GRASS Make system
>
Right now, I use a separate help index from the installed/built one.   
I don't think there is a way with basic HTML files to dynamically  
include other html files.  It could work if there was a local  
webserver, but that's not something we can count on.

For now, I make use of the Mac OS X help system to easily access the  
help files (though that isn't necessary in this context).  Similar to  
building the GUI menu off the addons menu file(s), we could also  
build the help menu from additional help index files.  Something  
would have to be done with the command line help also - it would have  
to check paths for module help files, something like  
$GRASS_ADDON_HELP.  (Michael - I forgot that the help menu was  
another bit to work on along with the addon menu.)

Though with all these GRASS_ADDON_* variables, I wonder if we should  
simplify them into just GRASS_ADDON_PATH which would be the base for  
structured dir with bin, lib, docs, etc subdirs.

> 3. Binary installs
>
I was thinking about how to handle that.  Even installs from a source  
build for a module.  I didn't come up with anything, but it should be  
possible.  For a make install for a module, pass the INST_DIR and let  
it override the configured INST_DIR.  The same could be used for a  
binary distribution for a module.


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

First Pogril: Why is life like sticking your head in a bucket filled  
with hyena offal?
Second Pogril: I don't know.  Why IS life like sticking your head in  
a bucket filled with hyena offal?
First Pogril: I don't know either.  Wretched, isn't it?

-HitchHiker's Guide to the Galaxy





More information about the grass-dev mailing list