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