[GRASS5] Comment on source code structure
neteler at geog.uni-hannover.de
Sat Oct 30 12:25:23 EDT 1999
here some comments on GRASS 5 source code structure
from Brook Milligan (who included thr "auto-conf" for
> From brook at biology.nmsu.edu Thu Oct 28 16:19:20 1999
> Date: Thu, 28 Oct 1999 08:31:05 -0600 (MDT)
> From: Brook Milligan <brook at biology.nmsu.edu>
> To: neteler at geog.uni-hannover.de
> Subject: Re: Announce: new GRASS 5 beta4 on Tuesday, 26. October
> our plans are to split the GRASS into topic oriented
> packages, say (just an idea)
> The way to distribute shall be via WWW: We want to create a
> I hope you will not limit it to WWW; have an ftp server also, please.
> Or at least make the real URL of the files well known so that one
> doesn't have to go through manual forms and such. Otherwise, you will
> be making it needlessly difficult for people like me who want to
> package GRASS for automated installation.
> Also, please establish a well-known naming convention for your files
> and change the names WHENEVER the file changes. Last I checked I
> found it difficult to tell what was what or whether anything new was
> there; downloading huge files and checksuming them is not my idea of a
> fun way to figure out if the contents of a file has changed. :)
> This can be realized (hopefully) for the next GRASS 5 release,
> when the reorganization of the source code is finished. Reason
> is that all the libraries have to go into the base package
> etc. to avoid dependency problems.
> Has this really been discussed? Do you have a plan of how the result
> should look? Does this mean that you are considering any of my
> earlier ideas about replacing all the arcane build scripts with a
> well-designed makefile set? Do you need help in designing this?
> Just a few suggestions to get the design going (if you need them):
> - identify common implicit make rules and place them in a single
> top-level Makefile.inc (or whatever) included by all others
> - identify common variable-driven make rules and place them in the
> same place; document the variables and what they do
> - identify a standard set of make targets to be supported by all
> makefiles; document the targets and what they do
> - replace directory-specific makefiles with much simplified ones which
> essentially just define the relevant variables
> - rearrange the code so the library dependencies make more sense.
> likely this will mean defining new libraries and mangling the
> contents of old ones.
> - rearrange the application code to use the new libraries
> Note, that the standard BSD make rules (e.g., in /usr/share/mk/* on
> NetBSD) are already set up to do a large fraction of the common rules
> that I expect you will need. To use them in compiling libraries or
> programs is usually a trivial matter of defining a couple of variables
> and including the relevant makefiles. Thus, if you followed that
> model, I think the makefile rearrangements could be quite easy.
> Redoing the code structure is really the difficult part, but it would
> help if there was a sane build system first.
> By the way, I didn't get too far debugging the Red Hat config
> problems. Only one person responded and I couldn't make too much
> sense of the response. Without having ever seen that OS I have
> difficulty understanding why it just doesn't work; there isn't
> anything particularly odd about the config script as far as I can
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev