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

[Benjamin Ducke]

> 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.
> 

This should not even require changing anything about GEM for the time
being. Just replace the makefiles I currently use for extensions
packages (see 'skeleton' dir that gets installed into 'etc' for GRASS
CVS installs) with the revised versions. GEM really just calls make
install and the rest is done by the make files included in the extension
package. I have documented this approach (and all make file changes I
made) in the GEM documentation accessible from the GRASS CVS help index.
> 
>> 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.

Right, GEM currently used a lot of HTML file parsing to manipulate the
main index.html (it looks for a special commented in there in order
to find the place to append its own index). However, for user installs,
we need a local HTML index, which needs to be linked to the system-wide
HTML index (however, in order to manipulate that one, we again would
need superuser rights -- aargh!).

It might be easier to create a second HTML index especially for
extensions which we can layout so that it becomes easier to parse for
our purposes. We could create a second GRASS script like g.manual.user
to display that index and put a not about it into the global HTML index.
> 
> 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.

Yes. I would be in favour of that: one plugin dir for each user and
nothing more (to worry about).

> 
>> 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.

Yes. Only problem is that for a simple "make install" (which is what
GEM currently does for binaries!) the user needs to
have GNU make tools installed on the system. So it would be better to
code all the stuff we need in C and include that in GEM.
If we manage to sort out the issues with the plugin dir and the HTML
page merging, this should not be very hard to do.

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.

Benjamin

> 
> 
> -----
> 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
> 
> 
> 
>